From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 02:50:55 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03284 for ; Fri, 1 Feb 2002 02:50:50 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14817; Thu, 31 Jan 2002 23:49:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28303; Thu, 31 Jan 2002 23:49:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g117mg2Q022464 for ; Thu, 31 Jan 2002 23:48:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g117mgGP022463 for mobile-ip-dist; Thu, 31 Jan 2002 23:48:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g117mc2Q022456 for ; Thu, 31 Jan 2002 23:48:38 -0800 (PST) Received: from lillen (vpn-129-156-96-41.EMEA.Sun.COM [129.156.96.41]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g117mkM27394; Fri, 1 Feb 2002 08:48:46 +0100 (MET) Date: Fri, 1 Feb 2002 08:45:06 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201311825.g0VIPqg46398@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => this is less complex to add 2 to the RH type than to specify > a new DO. The argument was about ADA or RH with IPsec: there is > no difference so IPsec cannot be used in order to decide between them. I think your point is about the difficulty of changing the implementations, where I agree that changing the RH type is really easy. I think that is very different than the resulting total complexity of MIPv6. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 03:11:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00988 for ; Fri, 1 Feb 2002 03:11:41 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17689; Fri, 1 Feb 2002 01:10:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08271; Fri, 1 Feb 2002 00:10:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g118A02Q022545 for ; Fri, 1 Feb 2002 00:10:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1189xaF022544 for mobile-ip-dist; Fri, 1 Feb 2002 00:09:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1189t2Q022537 for ; Fri, 1 Feb 2002 00:09:56 -0800 (PST) Received: from lillen (vpn-129-156-96-41.EMEA.Sun.COM [129.156.96.41]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g118A5M29430; Fri, 1 Feb 2002 09:10:06 +0100 (MET) Date: Fri, 1 Feb 2002 09:06:26 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RH and path MTU discovery To: Brian.Haley@compaq.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201312019.AA09339@dogbert.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik, > > I believe a lot of the questions you raised (and Francis answered) > are design and implementation details which are solved differently > by each vendor (eg Compaq). I think they're outside of the scope > of the draft. I agree in the sense that the spec shouldn't mandate solutions to these issues that are solely internal to a single box. But I'm a bit surprised that the spec doesn't even give a heads up to implementors that they need to think about these path MTU issues (and perhaps even give examples at a conceptual level of how they can be addressed). > > Was there explicit tests where during such a connection a router in the path > > have its MTU lowered? > > I haven't seen it done at a test event, but then most of the conformance > testing done is with you and a test generator on a private network, no > routers. Presumably a test device could send an ICMP packet too big as well without requiring any routers in the test setup. It would sound very useful to get such tests into the test suites for MIPv6. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 04:21:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07314 for ; Fri, 1 Feb 2002 04:21:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19645; Fri, 1 Feb 2002 02:20:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22536; Fri, 1 Feb 2002 01:20:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g119Iw2Q022658 for ; Fri, 1 Feb 2002 01:18:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g119Iwgl022657 for mobile-ip-dist; Fri, 1 Feb 2002 01:18:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g119It2Q022650 for ; Fri, 1 Feb 2002 01:18:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09867; Fri, 1 Feb 2002 01:19:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29535; Fri, 1 Feb 2002 02:19:09 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA27214; Fri, 1 Feb 2002 01:19:09 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g119J8V15728; Fri, 1 Feb 2002 01:19:08 -0800 X-mProtect: Fri, 1 Feb 2002 01:19:08 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2IWK5Y; Fri, 01 Feb 2002 01:19:06 PST Message-ID: <3C5A5D29.161F2AB1@iprg.nokia.com> Date: Fri, 01 Feb 2002 01:17:29 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, Continuing our discussion... Erik Nordmark wrote: > > The first and foremost purpose of including what is in effect two destination > addresses in a packet sent to the mobile is to be able > to identify the mobile node indepedent of its current location. > Thus identical to the purpose of the HAO. The care-of address is the routing destination. The home address is the endpoint identifier -- i.e., the socket destination. They are used differently. The care-of address should be be made invisible to the application. The home address should not be made visible to the routing infrastructure, very broadly speaking. The purposes of the two devices under consideration (the HAO and the routing header) are tailored to accomplish the above. I would not say they are symmetric. If pushed to trying to make some abstraction, I would say they are instead dual. Duality is, however, tricky, and I have never seen a good analysis of the duality between routing and endpoint identification. One thing about dual spaces, however, is that even if they are isomorphic, the correspondence used to make the isomorphism is not natural. That's why I think "symmetry" is a wrong word. > > The Routing Header is used for routing. It provides an address > > (namely, the care-of address) that has to be used for routing, but > > that at the same time should be made invisible to any higher-level > > protocols. > > I don't disagree with that RH could be used to carry the extra destination > address. But the purpose of carrying it is to identify the MN. I can understand this statement under the assumption that you mean, "provide the home address to the mobile node as an identifier". Yes, the routing header does do that. In fact, you "could" make the care-of address as the final segment, and have a new option that says "use this as your destination home address", as has been pointed out elsewhere. Then I think you have to offer a solution about what happens when that home address was an interior address in a list of routers used for some purpose requiring a routing header. Does the node formulating the routing header have to condition its construction based on knowledge about the care-of address of the mobile node? This is the additional complication that will certainly become necessary if you mandate more restrictive behavior now. Or else in the future we will more likely "un-mandate" it. Oh, well! > Whether there are benefits in using RH for this, beyond the fact that it > is easier to change existing MIPv6 implementation to use a different RH type, is > hard to tell. I think we can't possibly tell until we know > something more about the future in the areas of mobile routers/networks > and/or use of RH for explicit routing by actual applications (as opposed > to just traceroute -g). > I base this thinking on not having seen anybody explain the architecture > and conceptual model for such a scheme - the references to RH are that it > mechanistically works. > I don't disagree with the "works" part - but you seem to claim there is a > deeper argument for RH being better and I fail to find one. Then I would suggest that since RH manifestly "works", and since we can not be sure that firewall vendors will be "nice" for any alternative proposal especially when that alternative has to be extended for the mobile router on my belt that communicates with my PDA and laptop and earrings -- that we should go with what works. And, after all, this is FAR more validation and analysis than seems to go into other Proposed Standards! Do I dare mention again that it's implemented and works? I'm not trying to be antagonistic! > > One shouldn't impose symmetry on the handling of addresses that > > are to be used for different purposes entirely. > > We seem to agree that the HoA in a HAO sent *from* a MN serves to > identify the MN. Right, as long as we mean "endpoint identification". > The above statement of "different purpose" seem to say that the HoA in a packet > sent *to* a MN does not identify the MN? I'm confused - either the home > address identifies the MN or it does not - this can't depend on what type of > packet the HoA is contained in. Of course it does identify the endpoint. The IPv6 endpoint has several IP addresses, and having the home address is crucial for picking the right internal sockets and so on. I've gotta go to bed. More later... Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 05:26:54 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13057 for ; Fri, 1 Feb 2002 05:26:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23491; Fri, 1 Feb 2002 03:26:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28983; Fri, 1 Feb 2002 02:26:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11APD2Q022809 for ; Fri, 1 Feb 2002 02:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11APDaF022808 for mobile-ip-dist; Fri, 1 Feb 2002 02:25:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11APA2Q022801 for ; Fri, 1 Feb 2002 02:25:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14736 for ; Fri, 1 Feb 2002 02:25:25 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14365 for ; Fri, 1 Feb 2002 03:25:25 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 34AC8A; Fri, 1 Feb 2002 12:26:35 +0200 (EET) Message-ID: <3C5A6CEC.8080901@nomadiclab.com> Date: Fri, 01 Feb 2002 12:24:44 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E01C4338B@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn, > The namespace stuff intrigues me, but I suppose my present thinking is > that we don't need to send HI's in every packet. Right, we don't need to send HI's on every packet, nor HIP does. Actually, once you step on that road, you'll recognize that you won't need the source address in most IP packets at all. Instead, you could well do with a "Reply-To-Address" DO, and you could use the source address field for something more useful. For some fun reading about that, see our half-jokingly paper at Nordsec, http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf > I.e. the same reasoning > given by others on this issue is used in ZOD to not send the MIP home > address in every packet. So from a fear of hypocrisy point of view, ZOD > should make reasonable sense to those who do not think the HI should be > sent on every packet. If not, perhaps this ID may serve to change > peoples minds and expedite the resolution of the HI/Stack ID question. I sincerely hope so. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 05:55:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14855 for ; Fri, 1 Feb 2002 05:55:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08766; Fri, 1 Feb 2002 03:54:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09324; Fri, 1 Feb 2002 02:54:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Aqb2Q022858 for ; Fri, 1 Feb 2002 02:52:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11AqbYl022857 for mobile-ip-dist; Fri, 1 Feb 2002 02:52:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11AqU2Q022842; Fri, 1 Feb 2002 02:52:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08326; Fri, 1 Feb 2002 02:52:45 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20135; Fri, 1 Feb 2002 03:52:42 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 575C5A; Fri, 1 Feb 2002 12:53:54 +0200 (EET) Message-ID: <3C5A7353.10705@nomadiclab.com> Date: Fri, 01 Feb 2002 12:52:03 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com Cc: "Charles E. Perkins" Subject: [mobile-ip] The semantics of the Routing Header? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, Related to the debate on the mobile-ip list on whether MIPv6 should use Routing Header or some other mechanism to carry the home address to a mobile node that is away from home, I'd like to solicit for well grounded opinions on the intended semantics of the Routing Header. To properly understand what I am really asking about we must first make a distinction between two logical entities, endpoints and locations. In the current Internet architecture, both endpoints and locations are identified with a single mechanism, i.e. with IP addresses. However, they are conceptually different, as very well pointed out by Noel Chiappa in http://users.exis.net/~jnc/tech/endpoints.txt In essense, a communication endpoint is an active entity engadged in the communications, i.e. a party who consumes messages and generates new ones. A location, on the other hand, is a topological "place" within the routing fabric. Now, my question is fairly simple: Is the meaning of the routing header to allow a packet to be sent through a number of communicating hosts (end-points) or via a specific path, identified by a set of locations? Or is it both? One way of pondering the question is to imagine that the endpoints and locations had different name spaces. For example, you could imagine that each host has a flat name tag (HIT in HIP terminology), and the locations are named according to the routing hierarchy as today. Under such an architecture, would the routing header contain addresses or these new name tags, or could it contain a mixture of both? The reason why I am asking this is the scenario, which Charlie Perkins has offered, where a packet is source routed through a Mobile Node that is away from home. According to his argumentation, in such case the routing header should have a route looking like .... - Care-of-Address - Home Address - .... where the Care-of-Address is the current location of the mobile node, and the Home Address is more like the end-point identifier of the mobile node. I am having hard time in clearly crasping the intended semantic meaning of this construction. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 05:56:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14936 for ; Fri, 1 Feb 2002 05:56:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09746; Fri, 1 Feb 2002 03:55:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09686; Fri, 1 Feb 2002 02:55:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Asd2Q022884 for ; Fri, 1 Feb 2002 02:54:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11Asd9J022883 for mobile-ip-dist; Fri, 1 Feb 2002 02:54:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Asa2Q022876 for ; Fri, 1 Feb 2002 02:54:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09549; Fri, 1 Feb 2002 02:54:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20546; Fri, 1 Feb 2002 03:54:50 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g11Asm323354; Fri, 1 Feb 2002 11:54:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA09295; Fri, 1 Feb 2002 11:54:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g11Aslg49745; Fri, 1 Feb 2002 11:54:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Thu, 31 Jan 2002 18:26:39 +0100. Date: Fri, 01 Feb 2002 11:54:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > I have some arguments in favour of the routing basis of this feature: => I keep this statement because this is the key one. The fact that it is a special case of a tunnel clearly argues for IPv6_NO_SRC (but there might be other reasons for that being undesirable). => I agree: both RH and D/Z tunneling are routing devices. The argument is about ADA: ADA is *not* a routing device (the complexity to mix RHs (for another purpose) and ADA is a proof), IMHO ADA is a MIPv6 ad hoc device. But I don't see how this leads to RH as being a good alternative. A destination options header with either a HOA, ADA, or both options looks a lot more like Deering/Zill tunneling than HOA, RH, or both. => symmetric argument... NOTE: The above doesn't work with ingress filtering at all hence it is completely academic. => of course this doesn't work with ingress filtering (uRPF in fact): ADA is not a routing device. But it seems like it would be the conceptually clean way to apply RH in this space. => matter of taste (what is more important: symmetry or routing device?) Do people see strong arguments for/against handling the "source HoA" and the destination "HoA" using the same mechanism? => no, there is no strong argument for/against any of the four alternatives. Does it make any difference e.g. in IPsec related complexity? => this comes back to a previous message: for IPsec RH or ADA are the same, D/Z tunneling has to be investigated, nobody has proposed details about a new not-final header (similar to ADA which is better). We should do a summary of arguments in order to be more efficient, but the first point is to reach a consensus about the #3 approach. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 06:24:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17006 for ; Fri, 1 Feb 2002 06:24:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25009; Fri, 1 Feb 2002 04:24:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24270; Fri, 1 Feb 2002 03:24:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11BND2Q023012 for ; Fri, 1 Feb 2002 03:23:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11BNDms023011 for mobile-ip-dist; Fri, 1 Feb 2002 03:23:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11BN82Q023004 for ; Fri, 1 Feb 2002 03:23:09 -0800 (PST) Received: from lillen (vpn-129-156-96-22.EMEA.Sun.COM [129.156.96.22]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g11BNGM21407; Fri, 1 Feb 2002 12:23:17 +0100 (MET) Date: Fri, 1 Feb 2002 12:19:35 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RH and path MTU discovery To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <009301c1aa7b$55123340$1b6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > How is this different from the case where a router fails on the > original path and the route changes so that the original > path MTU is no longer valid? I don't understand what "this" exactly refers to. Are you referring to the MIPv6 specific part (the fact that in a layered implementation the IP layer adds the RH) or something else? Erik > From: "Erik Nordmark" > To: > Sent: Thursday, January 31, 2002 1:31 AM > Subject: [mobile-ip] RH and path MTU discovery > > > > Question for the list: > > > > I was thinking about "RH works for MIPv6" - have implementors > > tested the interaction of MIPv6/RH with Path MTU discovery > > and figured out how to make sure it works? > > > > The mipv6 draft doesn't say anything about this but it seems like > > there are similar path MTU issues RH insertion by the IP stack > > as there are with IPsec tunnel insertion by the IP stack > > thus this is something that we presumably need to make sure is > > well documented. > > > > The issues are: > > TCP when initiating a connection needs to know which MSS to use. > > The MSS will be different if the IP layer, e.g. based on a binding > cache > > entry, inserts things in the packet. This is independent whether what > is > > added is a RH, a HOA, or an extra IP header. > > It seems like some advise would be useful to point out this issue. > > > > If a TCP connection starts out without using RH and later route > optimization > > has been setup (causing RH to be added by the IP layer) then a packet > > that previously fit in the MTU will no longer fit. Thus the IP layer > needs > > to be able to notify the TCP layer that it is adding N bytes to the > packets > > so that TCP can adjust its understanding of the effective path MTU. > > > > Finally, during the connection there could be changes in the routing > path > > to the MN causing routers to send back ICMP packet too big messages. > > Such packets would need to be recognized by TCP as effecting the MTU > > for the connection even though the destination field in the > > "packet in error" in the ICMP packet is the CoA instead of the HoA. > > An explicit example: > > TCP generates a packet with > > src = CN > > dst = HoA > > (and TCP already knows that IP will add 24 bytes due to the RH so > > it doesn't send packets that are too big) > > > > This causes IP to send > > src = CN > > dst = CoA > > routing header with seg-left = 1, address = HoA > > > > If the packet is too big somewhere along the path an ICMP > > error will be sent back with > > src = some router > > dst = CN > > ICMP packet too big > > mtu = 1300 > > packet in error > > src = CN > > dst = CoA > > routing header with seg-left = 1, address = HoA > > > > The actual processing of this can be split between IP and TCP but > > the effect must be the same as TCP having received a too big > > packet reporting a smaller MTU and where the dst was the HoA i.e. > > src = some router > > dst = CN > > ICMP packet too big > > mtu = 1276 <=== NOTE > > packet in error > > src = CN > > dst = HoA <=== NOTE > > > > One possible way to implement this is to have the IP layer convert > > the ICMP error before passing it to TCP. Another possible way > > would be to have TCP be able to adjust the reported MTU > > and extract the destination address from the RH. > > > > > > Do implementations already solve this? Has it been widely tested? > > > > RFC 2473 describes the solution to this in the more general case of > > IP-in-IPv6 tunneling, thus that might be useful as background reading. > > > > Erik > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 06:33:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17447 for ; Fri, 1 Feb 2002 06:33:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15359; Fri, 1 Feb 2002 01:05:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05786; Fri, 1 Feb 2002 00:05:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1184C2Q022514 for ; Fri, 1 Feb 2002 00:04:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1184CVb022513 for mobile-ip-dist; Fri, 1 Feb 2002 00:04:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g118482Q022506 for ; Fri, 1 Feb 2002 00:04:08 -0800 (PST) Received: from lillen (vpn-129-156-96-41.EMEA.Sun.COM [129.156.96.41]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1184EM28749; Fri, 1 Feb 2002 09:04:14 +0100 (MET) Date: Fri, 1 Feb 2002 09:00:34 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: charliep@iprg.nokia.com Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: "Your message with ID" <3C598F14.5E5E0980@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik Nordmark wrote: > > > Do people see strong arguments for/against handling the "source HoA" and the > > destination "HoA" using the same mechanism? > > Perhaps they are essentially different problems. > > The Home Address Option is not used for routing. It's used > to identify the mobile node, when the default use of the routable > IP address would lead to the "wrong answer". Charlie, The first and foremost purpose of including what is in effect two destination addresses in a packet sent to the mobile is to be able to identify the mobile node indepedent of its current location. Thus identical to the purpose of the HAO. > The Routing Header is used for routing. It provides an address > (namely, the care-of address) that has to be used for routing, but > that at the same time should be made invisible to any higher-level > protocols. I don't disagree with that RH could be used to carry the extra destination address. But the purpose of carrying it is to identify the MN. Whether there are benefits in using RH for this, beyond the fact that it is easier to change existing MIPv6 implementation to use a different RH type, is hard to tell. I think we can't possibly tell until we know something more about the future in the areas of mobile routers/networks and/or use of RH for explicit routing by actual applications (as opposed to just traceroute -g). I base this thinking on not having seen anybody explain the architecture and conceptual model for such a scheme - the references to RH are that it mechanistically works. I don't disagree with the "works" part - but you seem to claim there is a deeper argument for RH being better and I fail to find one. > One shouldn't impose symmetry on the handling of addresses that > are to be used for different purposes entirely. We seem to agree that the HoA in a HAO sent *from* a MN serves to identify the MN. The above statement of "different purpose" seem to say that the HoA in a packet sent *to* a MN does not identify the MN? I'm confused - either the home address identifies the MN or it does not - this can't depend on what type of packet the HoA is contained in. > > Does it make any difference e.g. in IPsec related complexity? > > I think it will be better to entirely remove the authentication > of the Binding Update from the domain of IPsec. I wasn't thinking of that subject - in fact this email thread has nothing to do with how BUs are authenticated and authorized. I was thinking of the case when folks want to use IPsec for the data traffic carried between nodes where some of the nodes use MIPv6. The complexity of handling the HAO is well-known in that case. Thus the question was whether putting the ADA together with the HAO, using the mechanisms we've already worked out in all their complexity, would be any simpler than handling HAO the way we do (with respect to IPsec) and have the RH which may have some other interaction with IPsec. The answer from Francis on this question is that it doesn't matter, but I'd like to explore some more details in that space to better understand. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 07:03:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19440 for ; Fri, 1 Feb 2002 07:03:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13049; Fri, 1 Feb 2002 05:02:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00073; Fri, 1 Feb 2002 04:02:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C152Q023185 for ; Fri, 1 Feb 2002 04:01:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11C15SE023184 for mobile-ip-dist; Fri, 1 Feb 2002 04:01:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11C102Q023177 for ; Fri, 1 Feb 2002 04:01:00 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05849 for ; Fri, 1 Feb 2002 04:01:14 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13304 for ; Fri, 1 Feb 2002 04:01:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19319; Fri, 1 Feb 2002 07:01:09 -0500 (EST) Message-Id: <200202011201.HAA19319@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-nomad-mobileip-filters-01.txt Date: Fri, 01 Feb 2002 07:01:09 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Filters for Mobile IP Bindings (NOMAD) Author(s) : N. Fikouras et al. Filename : draft-nomad-mobileip-filters-01.txt Pages : 15 Date : 31-Jan-02 In Mobile IP, a mobile node that maintains simultaneous bindings will receive at each registered care-of address a duplicate copy of every datagram from every active flow. However, a mobile node with multiple points of attachment may wish to receive different flows at each one. The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishment (registration, binding update). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nomad-mobileip-filters-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nomad-mobileip-filters-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020131125250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nomad-mobileip-filters-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-nomad-mobileip-filters-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020131125250.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 12:07:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03913 for ; Fri, 1 Feb 2002 12:07:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14041; Fri, 1 Feb 2002 10:06:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22866; Fri, 1 Feb 2002 09:06:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11H5G2Q024067 for ; Fri, 1 Feb 2002 09:05:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11H5G0W024066 for mobile-ip-dist; Fri, 1 Feb 2002 09:05:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11H5C2Q024059; Fri, 1 Feb 2002 09:05:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15898; Fri, 1 Feb 2002 09:05:27 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05975; Fri, 1 Feb 2002 09:05:27 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g11H5Pe01320; Fri, 1 Feb 2002 09:05:25 -0800 (PST) Message-ID: <004501c1ab42$6ac485e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , , , Cc: "Charles E. Perkins" References: <3C5A7353.10705@nomadiclab.com> Subject: [mobile-ip] Re: [Monet] The semantics of the Routing Header? Date: Fri, 1 Feb 2002 09:03:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, > Related to the debate on the mobile-ip list on whether > MIPv6 should use Routing Header or some other mechanism > to carry the home address to a mobile node that is > away from home, I'd like to solicit for well grounded > opinions on the intended semantics of the Routing Header. > > To properly understand what I am really asking about we > must first make a distinction between two logical > entities, endpoints and locations. In the current > Internet architecture, both endpoints and locations are > identified with a single mechanism, i.e. with IP addresses. > However, they are conceptually different, as very well > pointed out by Noel Chiappa in > http://users.exis.net/~jnc/tech/endpoints.txt > In essense, a communication endpoint is an active > entity engadged in the communications, i.e. a party > who consumes messages and generates new ones. A location, > on the other hand, is a topological "place" within the > routing fabric. > I think there is something missing in this analysis. A communication endpoint requires more than just the address to identify it, it also requires the port. > Now, my question is fairly simple: Is the meaning of > the routing header to allow a packet to be sent through > a number of communicating hosts (end-points) or via a > specific path, identified by a set of locations? Or > is it both? > To me, it is fairly clear that the routing header is just to route through a determined set of intermediate forwarding nodes, i.e. routers, regardless of their communication status. The header does not nor should it require that a forwarding node be running a specific protocol and thus support traffic to a particular port in order to obtain forwarding service. > One way of pondering the question is to imagine that the > endpoints and locations had different name spaces. For > example, you could imagine that each host has a flat > name tag (HIT in HIP terminology), and the locations > are named according to the routing hierarchy as today. > Under such an architecture, would the routing header > contain addresses or these new name tags, or could > it contain a mixture of both? > > The reason why I am asking this is the scenario, which > Charlie Perkins has offered, where a packet is source > routed through a Mobile Node that is away from home. > According to his argumentation, in such case the > routing header should have a route looking like > > .... - Care-of-Address - Home Address - .... > > where the Care-of-Address is the current location of > the mobile node, and the Home Address is more like > the end-point identifier of the mobile node. I am > having hard time in clearly crasping the intended > semantic meaning of this construction. > I've been loosely following this discussion, and I think Charlie's argument has merit but I think it is orthogonal to what the semantics of the Routing Header should be. Currently, as Charlie has pointed out, the two functions are served by two header options. The MIP case may be unique enough that perhaps a new option is needed combining the CoA and HA. I don't really see this as being a general problem, though. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 12:12:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04345 for ; Fri, 1 Feb 2002 12:12:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18146; Fri, 1 Feb 2002 10:11:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25603; Fri, 1 Feb 2002 09:11:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HAw2Q024116 for ; Fri, 1 Feb 2002 09:10:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11HAwwT024115 for mobile-ip-dist; Fri, 1 Feb 2002 09:10:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HAt2Q024108 for ; Fri, 1 Feb 2002 09:10:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25307; Fri, 1 Feb 2002 09:11:10 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29028; Fri, 1 Feb 2002 10:11:09 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g11HB8e01515; Fri, 1 Feb 2002 09:11:08 -0800 (PST) Message-ID: <005801c1ab43$37618120$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] RH and path MTU discovery Date: Fri, 1 Feb 2002 09:09:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, "This" is the problem you laid out in your original message, namely RH insertion resulting in the known path MTU becoming invalid. But I see that others have made the point that was I think bothering me, namely that having the path MTU become invalid is something that could potentially occur for other reasons, and so a sufficiently robust IPv6 stack would have to be prepared for it. jak ----- Original Message ----- From: "Erik Nordmark" To: Cc: Sent: Friday, February 01, 2002 3:19 AM Subject: Re: [mobile-ip] RH and path MTU discovery > > > How is this different from the case where a router fails on the > > original path and the route changes so that the original > > path MTU is no longer valid? > > I don't understand what "this" exactly refers to. > Are you referring to the MIPv6 specific part (the fact that in a layered > implementation the IP layer adds the RH) or something else? > > Erik > > > From: "Erik Nordmark" > > To: > > Sent: Thursday, January 31, 2002 1:31 AM > > Subject: [mobile-ip] RH and path MTU discovery > > > > > > > Question for the list: > > > > > > I was thinking about "RH works for MIPv6" - have implementors > > > tested the interaction of MIPv6/RH with Path MTU discovery > > > and figured out how to make sure it works? > > > > > > The mipv6 draft doesn't say anything about this but it seems like > > > there are similar path MTU issues RH insertion by the IP stack > > > as there are with IPsec tunnel insertion by the IP stack > > > thus this is something that we presumably need to make sure is > > > well documented. > > > > > > The issues are: > > > TCP when initiating a connection needs to know which MSS to use. > > > The MSS will be different if the IP layer, e.g. based on a binding > > cache > > > entry, inserts things in the packet. This is independent whether what > > is > > > added is a RH, a HOA, or an extra IP header. > > > It seems like some advise would be useful to point out this issue. > > > > > > If a TCP connection starts out without using RH and later route > > optimization > > > has been setup (causing RH to be added by the IP layer) then a packet > > > that previously fit in the MTU will no longer fit. Thus the IP layer > > needs > > > to be able to notify the TCP layer that it is adding N bytes to the > > packets > > > so that TCP can adjust its understanding of the effective path MTU. > > > > > > Finally, during the connection there could be changes in the routing > > path > > > to the MN causing routers to send back ICMP packet too big messages. > > > Such packets would need to be recognized by TCP as effecting the MTU > > > for the connection even though the destination field in the > > > "packet in error" in the ICMP packet is the CoA instead of the HoA. > > > An explicit example: > > > TCP generates a packet with > > > src = CN > > > dst = HoA > > > (and TCP already knows that IP will add 24 bytes due to the RH so > > > it doesn't send packets that are too big) > > > > > > This causes IP to send > > > src = CN > > > dst = CoA > > > routing header with seg-left = 1, address = HoA > > > > > > If the packet is too big somewhere along the path an ICMP > > > error will be sent back with > > > src = some router > > > dst = CN > > > ICMP packet too big > > > mtu = 1300 > > > packet in error > > > src = CN > > > dst = CoA > > > routing header with seg-left = 1, address = HoA > > > > > > The actual processing of this can be split between IP and TCP but > > > the effect must be the same as TCP having received a too big > > > packet reporting a smaller MTU and where the dst was the HoA i.e. > > > src = some router > > > dst = CN > > > ICMP packet too big > > > mtu = 1276 <=== NOTE > > > packet in error > > > src = CN > > > dst = HoA <=== NOTE > > > > > > One possible way to implement this is to have the IP layer convert > > > the ICMP error before passing it to TCP. Another possible way > > > would be to have TCP be able to adjust the reported MTU > > > and extract the destination address from the RH. > > > > > > > > > Do implementations already solve this? Has it been widely tested? > > > > > > RFC 2473 describes the solution to this in the more general case of > > > IP-in-IPv6 tunneling, thus that might be useful as background reading. > > > > > > Erik > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 12:57:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05850 for ; Fri, 1 Feb 2002 12:57:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21040; Fri, 1 Feb 2002 10:55:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13562; Fri, 1 Feb 2002 09:55:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HsX2Q024320 for ; Fri, 1 Feb 2002 09:54:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11HsXmi024319 for mobile-ip-dist; Fri, 1 Feb 2002 09:54:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11HsU2Q024312 for ; Fri, 1 Feb 2002 09:54:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21786 for ; Fri, 1 Feb 2002 09:54:45 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10236 for ; Fri, 1 Feb 2002 10:54:44 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g11HsPS20318; Fri, 1 Feb 2002 11:54:25 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:54:25 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01D0BA1E@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: pekka.nikander@nomadiclab.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Fri, 1 Feb 2002 11:54:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB49.7C4036F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AB49.7C4036F0 Content-Type: text/plain; charset="iso-8859-1" > > For some fun reading about that, see our half-jokingly paper > at Nordsec, > http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf > > > I.e. the same reasoning > Pekka, So the paper is basically saying that the source address should be encrypted for privacy reasons and the only way to do that is by making it something that could be covered by ESP; namely, a DO. ZOD is not trying to propose such radical things and it really shouldn't be put into the same barrel as such concepts. I If ZOD is applied to MIP, the same signaling and same data-structures used in the existing implementations are re-used as is. The only change is you don't include the DO, RH or tunneled address (take your pick) and you don't have to worry about all of this MTU stuff. It actually simplifies the implementation. Depending on the original implementation, developers might find that they can actually remove some code. ZOD is simply using the end to end and fate-sharing principles to get rid of the per-packet overhead and avoid all of this MTU unpleasantness. Thanks again, Glenn ------_=_NextPart_001_01C1AB49.7C4036F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

>
> For some fun reading about that, see our = half-jokingly paper
> at Nordsec,
> http://www.tml.hut.fi/~pnr/publications/nordsec2001.pd= f
>
>  > I.e. the same reasoning
>

Pekka,

So the paper is basically saying that the source = address should be encrypted for privacy reasons and the only way to do = that is by making it something that could be covered by ESP; namely, a = DO.

ZOD is not trying to propose such radical things and = it really shouldn't be put into the same barrel as such concepts. = I

If ZOD is applied to MIP, the same signaling and same = data-structures used in the existing implementations are re-used as is. = The only change is you don't include the DO, RH or tunneled address = (take your pick) and you don't have to worry about all of this MTU = stuff. It actually simplifies the implementation. Depending on the = original implementation, developers might find that they can actually = remove some code.

ZOD is simply using the end to end and fate-sharing = principles to get rid of the per-packet overhead and avoid all of this = MTU unpleasantness.

Thanks again,

Glenn

------_=_NextPart_001_01C1AB49.7C4036F0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 1 13:36:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07054 for ; Fri, 1 Feb 2002 13:36:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05721; Fri, 1 Feb 2002 10:36:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01525; Fri, 1 Feb 2002 10:36:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11IYh2Q027076 for ; Fri, 1 Feb 2002 10:34:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g11IYh9L027075 for mobile-ip-dist; Fri, 1 Feb 2002 10:34:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11IYf2Q027068 for ; Fri, 1 Feb 2002 10:34:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22050 for ; Fri, 1 Feb 2002 13:34:56 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA25850 for mobile-ip@sunroof.eng.sun.com; Fri, 1 Feb 2002 13:35:41 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g11Dtj2Q023478; Fri, 1 Feb 2002 05:55:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16991; Fri, 1 Feb 2002 05:56:00 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08426; Fri, 1 Feb 2002 06:55:59 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA12534; Fri, 1 Feb 2002 14:55:51 +0100 Received: from dhcp23-128.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62760 from ; Fri, 1 Feb 2002 14:55:45 +0100 Message-Id: <3C5A9E61.9CD8272E@hursley.ibm.com> Date: Fri, 01 Feb 2002 14:55:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Nikander Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com, "Charles E. Perkins" Subject: [mobile-ip] Re: The semantics of the Routing Header? References: <3C5A7353.10705@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit It's fairly clear that architecturally, IPv4 and IPv6 are at exactly the same place on this: the notions of identifier and locator are 100% overlaid on each other. So in practical terms - what can we do, and standardize, *today* - we simply can't make the distinction. The IRTF NameSpace research group has been working inconclusively on the architectural issue for a couple of years. See http://www.ietf.org/internet-drafts/draft-irtf-nsrg-report-01.txt for a snapshot. imho it is best to disregard the philosophical side if you want to make progress immediately. What's the practical issue with embedding the home address in such a routing header? Brian Pekka Nikander wrote: > > Hello all, > > Related to the debate on the mobile-ip list on whether > MIPv6 should use Routing Header or some other mechanism > to carry the home address to a mobile node that is > away from home, I'd like to solicit for well grounded > opinions on the intended semantics of the Routing Header. > > To properly understand what I am really asking about we > must first make a distinction between two logical > entities, endpoints and locations. In the current > Internet architecture, both endpoints and locations are > identified with a single mechanism, i.e. with IP addresses. > However, they are conceptually different, as very well > pointed out by Noel Chiappa in > http://users.exis.net/~jnc/tech/endpoints.txt > In essense, a communication endpoint is an active > entity engadged in the communications, i.e. a party > who consumes messages and generates new ones. A location, > on the other hand, is a topological "place" within the > routing fabric. > > Now, my question is fairly simple: Is the meaning of > the routing header to allow a packet to be sent through > a number of communicating hosts (end-points) or via a > specific path, identified by a set of locations? Or > is it both? > > One way of pondering the question is to imagine that the > endpoints and locations had different name spaces. For > example, you could imagine that each host has a flat > name tag (HIT in HIP terminology), and the locations > are named according to the routing hierarchy as today. > Under such an architecture, would the routing header > contain addresses or these new name tags, or could > it contain a mixture of both? > > The reason why I am asking this is the scenario, which > Charlie Perkins has offered, where a packet is source > routed through a Mobile Node that is away from home. > According to his argumentation, in such case the > routing header should have a route looking like > > .... - Care-of-Address - Home Address - .... > > where the Care-of-Address is the current location of > the mobile node, and the Home Address is more like > the end-point identifier of the mobile node. I am > having hard time in clearly crasping the intended > semantic meaning of this construction. > > --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 3 11:10:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27012 for ; Sun, 3 Feb 2002 11:10:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19388; Sun, 3 Feb 2002 08:09:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00805; Sun, 3 Feb 2002 08:09:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13G8i2Q000700 for ; Sun, 3 Feb 2002 08:08:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g13G8i43000699 for mobile-ip-dist; Sun, 3 Feb 2002 08:08:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13G8f2Q000692 for ; Sun, 3 Feb 2002 08:08:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11825 for ; Sun, 3 Feb 2002 08:08:56 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19540 for ; Sun, 3 Feb 2002 08:08:55 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g13G8k316246; Sun, 3 Feb 2002 17:08:47 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA13382; Sun, 3 Feb 2002 17:08:47 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g13G8lg59417; Sun, 3 Feb 2002 17:08:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202031608.g13G8lg59417@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Fri, 01 Feb 2002 08:45:06 +0100. Date: Sun, 03 Feb 2002 17:08:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => this is less complex to add 2 to the RH type than to specify > a new DO. The argument was about ADA or RH with IPsec: there is > no difference so IPsec cannot be used in order to decide between them. I think your point is about the difficulty of changing the implementations, => implementations and specifications (i.e. minimal changes). where I agree that changing the RH type is really easy. => I don't expect someone will disagree. I think that is very different than the resulting total complexity of MIPv6. => the real issue (how to mix routing and MIPv6) is out of the scope (because this is too related to mobile routers) but this is the only point where we can find a real difference between proposals. IMHO the tradeoff is between RH and D/Z tunnels, i.e. what is the best feature for policy routing and co, source routing or tunneling? I believe this is the second because VPNs are not only a fashion, but this implies we really consider interactions between D/Z tunnels and IPsec. I know what to write about this but I have to find the time and the good way to involve IPsec people in the discussion. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 3 16:51:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00391 for ; Sun, 3 Feb 2002 16:51:36 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20223; Sun, 3 Feb 2002 13:51:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01182; Sun, 3 Feb 2002 13:50:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13Lnh2Q001553 for ; Sun, 3 Feb 2002 13:49:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g13Lnhfd001552 for mobile-ip-dist; Sun, 3 Feb 2002 13:49:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13Lne2Q001545 for ; Sun, 3 Feb 2002 13:49:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14636 for ; Sun, 3 Feb 2002 13:49:56 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12804 for ; Sun, 3 Feb 2002 13:49:55 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g13LnqZ22738; Sun, 3 Feb 2002 23:49:52 +0200 Date: Sun, 3 Feb 2002 23:49:51 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-Reply-To: <200202031608.g13G8lg59417@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Sun, 3 Feb 2002, Francis Dupont wrote: > I think that is very different than the resulting total complexity > of MIPv6. > > => the real issue (how to mix routing and MIPv6) is out of the scope > (because this is too related to mobile routers) but this is the only > point where we can find a real difference between proposals. > IMHO the tradeoff is between RH and D/Z tunnels, i.e. what is the best > feature for policy routing and co, source routing or tunneling? > I believe this is the second because VPNs are not only a fashion, > but this implies we really consider interactions between D/Z tunnels > and IPsec. I know what to write about this but I have to find the time > and the good way to involve IPsec people in the discussion. I think one significant issue here is how HAO would be handled: if D/Z tunneling would be the way to go there, in my book that would make D/Z more attractive for RH too.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 07:10:39 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19480 for ; Mon, 4 Feb 2002 07:10:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29993; Mon, 4 Feb 2002 04:10:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27905; Mon, 4 Feb 2002 04:09:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14C8q2Q002263 for ; Mon, 4 Feb 2002 04:08:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14C8qnP002262 for mobile-ip-dist; Mon, 4 Feb 2002 04:08:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14C8m2Q002255 for ; Mon, 4 Feb 2002 04:08:48 -0800 (PST) Received: from lillen (vpn-129-156-96-69.EMEA.Sun.COM [129.156.96.69]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g14C8uM14005; Mon, 4 Feb 2002 13:08:56 +0100 (MET) Date: Mon, 4 Feb 2002 13:05:07 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Charlie Perkins Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C5A5D29.161F2AB1@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The care-of address is the routing destination. The home address > is the endpoint identifier -- i.e., the socket destination. They > are used differently. The care-of address should be be made > invisible to the application. The home address should not be > made visible to the routing infrastructure, very broadly > speaking. I agree that the home address shouldn't be visible to the routing infrastructure. But below you talk about the home address being "interior address in a list of routers" which seems to conflict with your statement above. > The purposes of the two devices under consideration (the > HAO and the routing header) are tailored to accomplish the > above. I would not say they are symmetric. If pushed to > trying to make some abstraction, I would say they are > instead dual. Duality is, however, tricky, and I have never > seen a good analysis of the duality between routing and > endpoint identification. One thing about dual spaces, > however, is that even if they are isomorphic, the correspondence > used to make the isomorphism is not natural. That's why I > think "symmetry" is a wrong word. Well, the source and destination addresses in an IP packet look rather symmetric to me, even though the functions the have as a packet passes through a network are a bit different. It seems to have served IP well to have the source and destination IP addresses in the same IP header. Thus one could make the argument that it makes sense to put the source and destination HoA in the same place in the headers would make sense as well. > > I don't disagree with that RH could be used to carry the extra destination > > address. But the purpose of carrying it is to identify the MN. > > I can understand this statement under the assumption that you > mean, "provide the home address to the mobile node as an > identifier". What I meant was more limited - identifying the MN in the sense that e.g. TCP connections terminated on the MN use that HoA to identify the connection. > Yes, the routing header does do that. In fact, you > "could" make the care-of address as the final segment, and > have a new option that says "use this as your destination > home address", as has been pointed out elsewhere. Then > I think you have to offer a solution about what happens when > that home address was an interior address in a list of routers > used for some purpose requiring a routing header. Does the > node formulating the routing header have to condition its > construction based on knowledge about the care-of address > of the mobile node? This is the additional complication > that will certainly become necessary if you mandate more > restrictive behavior now. Or else in the future we will more > likely "un-mandate" it. Oh, well! We are going around in circles both in the discussion and in your arguments. I've asked you many times on the list why you seen the need to combine explicit routing (using source routing) and mobility the way you describe. Your respons has always been something like its obvious that things should work as RH since this is routing and using that as the motivation for it needing to work as RH. In order to talk more intelligently about this it seems like we need to understand: 1. Mobile routers/networks and how route optimization should work with such 2. Explicit routing using source routing - will applications do this? 3. How #1 and #2 should interact To me saying whether destination options, routing headers, or Deering/Zill tunneling fit better in this completely undefined space seems to be rather unproductive speculation. > Then I would suggest that since RH manifestly "works", and since > we can not be sure that firewall vendors will be "nice" for any > alternative proposal especially when that alternative has to be > extended for the mobile router on my belt that communicates with > my PDA and laptop and earrings -- that we should go with what > works. And, after all, this is FAR more validation and analysis > than seems to go into other Proposed Standards! RH works. Tunneling works. The fact that HAO works for the source HoA means that we know exactly how to make a destination HoA work as a destination option as well. The point is that the attribute "works" doesn't seem to help tell them apart. "Number of lines of code changes in an implementation" can be used to tell them apart, and that is definitely one factor for the WG to consider together with other factors. > > We seem to agree that the HoA in a HAO sent *from* a MN serves to > > identify the MN. > > Right, as long as we mean "endpoint identification". Hmm - but from above it seems like you have a different definition of this term than I have. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 08:39:56 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21856 for ; Mon, 4 Feb 2002 08:39:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07827; Mon, 4 Feb 2002 06:38:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08306; Mon, 4 Feb 2002 05:38:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14DbV2Q002381 for ; Mon, 4 Feb 2002 05:37:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14DbUia002380 for mobile-ip-dist; Mon, 4 Feb 2002 05:37:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14DbQ2Q002373 for ; Mon, 4 Feb 2002 05:37:27 -0800 (PST) Received: from lillen (vpn-129-156-96-69.EMEA.Sun.COM [129.156.96.69]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g14DbaM22294; Mon, 4 Feb 2002 14:37:36 +0100 (MET) Date: Mon, 4 Feb 2002 14:33:47 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => I agree: both RH and D/Z tunneling are routing devices. The argument > is about ADA: ADA is *not* a routing device (the complexity to mix > RHs (for another purpose) and ADA is a proof), IMHO ADA is a MIPv6 > ad hoc device. So same question I've been asking Charlie - what would combining RH and MIPv6 (assuming MIPv6 didn't use RH) actually be useful for? Mobile routers and/or mobile network? I do understand that the "nesting" properties of tunneling and destinations options are different; one could nest multiple deering/zill tunnels with potentially different nodes adding and removing the nested headers. One could also see some form of "destination specific nesting" using RH but one couldn't do source nesting for packets sent in the other direction since the HAO do not nest. Is what I call "nesting" (recursive application) close to what you mean by "routing device"? > => symmetric argument... > > NOTE: The above doesn't work with ingress filtering at all hence > it is completely academic. > > => of course this doesn't work with ingress filtering (uRPF in fact): > ADA is not a routing device. I'm confused - my NOTE was about using a "consumed" routing header to capture the semantics of the HAO - It was not about ADA. > => this comes back to a previous message: for IPsec RH or ADA are the same, > D/Z tunneling has to be investigated, nobody has proposed details about > a new not-final header (similar to ADA which is better). > We should do a summary of arguments in order to be more efficient, but > the first point is to reach a consensus about the #3 approach. The chairs already declared consensus on approach #3 (i.e. to define somehing new for MIPv6). I'm trying to capture a list of pros and cons for New RH type New (ADA) destination option Deering/Zill tunneling New extension header So the purpose of me asking stupid(?) questions is to make sure I understand the pros and cons that people bring up. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 08:53:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22236 for ; Mon, 4 Feb 2002 08:53:29 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14560; Mon, 4 Feb 2002 06:52:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09501; Mon, 4 Feb 2002 05:52:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Dpc2Q002415 for ; Mon, 4 Feb 2002 05:51:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14DpbfL002414 for mobile-ip-dist; Mon, 4 Feb 2002 05:51:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14DpY2Q002407 for ; Mon, 4 Feb 2002 05:51:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22472 for ; Mon, 4 Feb 2002 05:51:50 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09042 for ; Mon, 4 Feb 2002 06:51:49 -0700 (MST) Received: from PATINET (patinet.u-strasbg.fr [130.79.90.172]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id OAA32729 for ; Mon, 4 Feb 2002 14:51:48 +0100 Message-ID: <02e001c1ad83$1ea7f7d0$ac5a4f82@ustrasbg.fr> From: "Christophe Jelger" To: Subject: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources Date: Mon, 4 Feb 2002 14:52:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Two weeks ago we proposed a draft (draft-jelger-mssmsv6-00.txt) called "Supporting Mobile SSM Sources for IPv6 (MSSMSv6)" that proposes a solution to handle mobile (MIPv6) PIM-SSM sources. We hope that some of you have had the time to read it and we would be pleased to hear your comments and suggestions. We would like to start a discussion of the subject and gather people's comments and ideas in order to be able to improve our current proposal. We look forward to receiving your comments. Christophe Jelger and Thomas Noel --------------------------------------------------------------- Christophe Jelger - LSIIT jelger@dpt-info.u-strasbg.fr Université Louis Pasteur Strasbourg - France Tel: +33 (0)3 90 24 45 90 http://www-r2.u-strasbg.fr/~jelger --------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 09:21:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23086 for ; Mon, 4 Feb 2002 09:21:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29677; Mon, 4 Feb 2002 07:20:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12200; Mon, 4 Feb 2002 06:19:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14EIt2Q002458 for ; Mon, 4 Feb 2002 06:18:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14EItho002457 for mobile-ip-dist; Mon, 4 Feb 2002 06:18:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14EIp2Q002450 for ; Mon, 4 Feb 2002 06:18:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21128 for ; Mon, 4 Feb 2002 06:19:07 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19442 for ; Mon, 4 Feb 2002 06:19:07 -0800 (PST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 3C8D0A; Mon, 4 Feb 2002 16:20:19 +0200 (EET) Message-ID: <3C5E9839.9090408@nomadiclab.com> Date: Mon, 04 Feb 2002 16:18:33 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: jelger@clarinet.u-strasbg.fr Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources References: <02e001c1ad83$1ea7f7d0$ac5a4f82@ustrasbg.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Christophe, > Two weeks ago we proposed a draft (draft-jelger-mssmsv6-00.txt) called > "Supporting Mobile SSM > Sources for IPv6 (MSSMSv6)" that proposes a solution to handle mobile > (MIPv6) PIM-SSM sources. ... > We look forward to receiving your comments. Some possible security and other problems that I noticed: 1. Your scheme depends on the assumption that there is a reverse tunnel to the old AR. This may not be always the case. 2. You can't just leave security with the note that you are not aware of any additional security problems than those related to MIPv6 and PIM-SSM. Firstly, even combining two completely secure mechanisms is prone to introducing new security problems. Secondly, the MIPv6 security solution seems to be based on the idea of Return Routability (RR), possibly enhanced with optional Cryptographically Generated Addresses (CGA). At least to me it is not at all clear how to apply these techniques to multicast groups. If you don't address this, your proposal is prone to a large class of different DoS and perhaps other attacks. 3. You include a new feature, the nSA suboption to the Binding Updates. I have the feeling that this may have nasty security problems unless properly authorized. Unfortunately my understanding about the nature of the building up and management of multicast trees is too vague that I could properly analyze this. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 10:53:55 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26511 for ; Mon, 4 Feb 2002 10:53:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24098; Mon, 4 Feb 2002 07:53:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04604; Mon, 4 Feb 2002 07:52:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Fph2Q002604 for ; Mon, 4 Feb 2002 07:51:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14FphDi002603 for mobile-ip-dist; Mon, 4 Feb 2002 07:51:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14Fpd2Q002596 for ; Mon, 4 Feb 2002 07:51:40 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25392 for ; Mon, 4 Feb 2002 07:51:54 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25831 for ; Mon, 4 Feb 2002 07:51:51 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id B6B8B43E5B; Mon, 4 Feb 2002 16:51:48 +0100 (CET) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 0804199E92; Mon, 4 Feb 2002 16:51:48 +0100 (CET) Message-ID: <3C5EAE12.DA5F9400@it.uc3m.es> Date: Mon, 04 Feb 2002 16:51:46 +0100 From: Ignacio Soto Campos X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: [mobile-ip] draft on random interface identifiers available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, We have submitted the draft "Random generation of interface identifiers" that is available from: http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt The abstract is included below. Comments are welcomed. Abstract This document evaluates the use of random numbers to generate the interface identifier part of an IPv6 address on mobile environments, where Duplicate Address Detection (DAD) mechanisms are expensive. We have estimated the probability of having an address duplication using this mechanism and we conclude that the IPv6 addresses created in this way could be used without previously doing DAD to test the uniqueness of the address in a link. Best regards, Ignacio From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 14:36:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03918 for ; Mon, 4 Feb 2002 14:36:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19751; Mon, 4 Feb 2002 11:34:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21506; Mon, 4 Feb 2002 11:34:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14JXH2Q002917 for ; Mon, 4 Feb 2002 11:33:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14JXH3v002916 for mobile-ip-dist; Mon, 4 Feb 2002 11:33:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14JXD2Q002909 for ; Mon, 4 Feb 2002 11:33:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24730 for ; Mon, 4 Feb 2002 11:33:28 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04665 for ; Mon, 4 Feb 2002 12:33:27 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14JXPU15150 for ; Mon, 4 Feb 2002 13:33:25 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 13:33:26 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01D7E735@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Mon, 4 Feb 2002 13:33:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ADB2.CBE59810" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1ADB2.CBE59810 Content-Type: text/plain; charset="iso-8859-1" All, As I recall, #3 was this: "3. Try to simplify things by not using Routing Headers for MIPv6." ZOD and MR. ZOD don't use routing headers either. They can also be used with mobile routers as well - even with nested mobile nodes attached to the mobile routers. They can also be used to do local mobility management. MR. ZOD is just as robust, as well. ZOD eliminates the possibility of interference from firewalls via transparency; making the arguments related to firewalls, routing headers and home address options, mute. None of the other proposals have this transparency property. Both can be completely end to end and hold to the fatesharing principle. They are also more efficient in terms of PDU size than any of the other proposals. The address space of IPv6 is huge. With these points in mind, the variants of the two should be included as options for seriously consideration at this time, as well. > The chairs already declared consensus on approach #3 (i.e. to > define somehing > new for MIPv6). I'm trying to capture a list of pros and cons for > New RH type > New (ADA) destination option > Deering/Zill tunneling > New extension header GM] Zero Overhead Diversion GM] More Robust Zero Overhead Diversion using flow label bit using traffic class bit regards, Glenn ------_=_NextPart_001_01C1ADB2.CBE59810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team = recommendation

All,

As I recall, #3 was this:

"3. Try to simplify things by not using Routing = Headers for MIPv6."

ZOD and MR. ZOD don't use routing headers either. =

They can also be used with mobile routers as well - = even with nested mobile nodes attached to the mobile routers.

They can also be used to do local mobility = management. 

MR. ZOD is just as robust, as well.

ZOD eliminates the possibility of interference from = firewalls via transparency; making the arguments related to firewalls, = routing headers and home address options, mute. None of the other = proposals have this transparency property.

Both can be completely end to end and hold to the = fatesharing principle.

They are also more efficient in terms of PDU size = than any of the other proposals.

The address space of IPv6 is huge.

With these points in mind, the variants of the two = should be included as options for seriously consideration at this time, = as well.

> The chairs already declared consensus on = approach #3 (i.e. to
> define somehing
> new for MIPv6). I'm trying to capture a list of = pros and cons for
>       New RH = type
>       New (ADA) = destination option
>       Deering/Zill = tunneling
>       New extension = header
GM]   Zero Overhead Diversion
GM]   More Robust Zero Overhead = Diversion
        =         using flow = label bit
        =         using traffic = class bit

regards,
 
Glenn

------_=_NextPart_001_01C1ADB2.CBE59810-- From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 14:47:13 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04244 for ; Mon, 4 Feb 2002 14:47:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25083; Mon, 4 Feb 2002 11:46:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25873; Mon, 4 Feb 2002 11:45:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14JiO2Q002954 for ; Mon, 4 Feb 2002 11:44:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14JiOau002953 for mobile-ip-dist; Mon, 4 Feb 2002 11:44:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14JiL2Q002946 for ; Mon, 4 Feb 2002 11:44:21 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23263 for ; Mon, 4 Feb 2002 11:44:36 -0800 (PST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18796 for ; Mon, 4 Feb 2002 11:44:35 -0800 (PST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g14JiYQ14756 for ; Mon, 4 Feb 2002 11:44:34 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 4 Feb 2002 11:44:34 -0800 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g14JiY026372; Mon, 4 Feb 2002 11:44:34 -0800 (PST) Message-Id: <200202041944.g14JiY026372@scv2.apple.com> Subject: [mobile-ip] IPv4 Address Conflict Detection Date: Mon, 4 Feb 2002 11:44:34 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "DHCP discussion list" cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At the DHC WG meeting in Salt Lake City we briefly talked about address conflict detection. The feedback I got was that while it is definitely useful to nail down a clear specification of how do do address conflict detection properly, it doesn't have an obvious natural "home" in any current IETF WG, so I should just solicit feedback and then send it in as an individual submission. The two working groups we felt had expertise in this area are DHC and MOBILEIP, hence this email: ---------------- From time to time people ask how Mac OS, Windows, and other OSs do that thing they do where they give an error message if two hosts are accidentally configured with the same IP address. Detecting address conflicts is not difficult, but to date there has been no IETF Standard specifying how to do it. The only RFC I could find that even mentions IPv4 address conflict detection is RFC 2131, where it says things like: If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server Unfortunately, RFC 2131 doesn't go into much detail about trivia like how many ARP packets to send, how long to wait, etc. This is not a criticism of RFC 2131, because defining IPv4 address conflict detection is rightly outside the scope of RFC 2131. Ideally, there should have been an existing specification for RFC 2131 to reference, like this: If the client detects that the address is already in use [RFC xxxx], the client MUST send a DHCPDECLINE message to the server Sadly, that specification did not exist when RFC 2131 was written. To remedy this, I have written a short draft specifying how to detect address conflicts. I'm sending this email not because I think that DHC or MOBILEIP ought to take on this work, but because I think that if it eventually becomes an RFC then DHC and MOBILEIP may want to reference it in their own standards, so I want to give everyone a chance to take a look and see if they like what it says. DHCP depends on a conflict detection mechanism in order to trigger a DHCP DECLINE packet. My hope is that this draft is a clear specification of how to perform that conflict detection, so that if/when RFC 2131 is updated, it can reference this specification instead of again saying, "e.g., through the use of ARP." I think it makes sense to publish IPv4 Address Conflict Detection as a separate standard, because while address conflict detection is important for a DHCP client, it is useful no matter how a host is configured. If a host is configured manually, then address conflict detection allows the host to display an error message if two hosts are accidentally given the same address. If a host is using a Zeroconf self-assigned link-local address, then address conflict detection is the mechanism that tells the host it needs to select a different address. Right now, as written, draft-00 specifies that a host probe the network for 8-10 seconds before beginning to use an IP address. For a desktop machine using DHCP, this is probably fine. For a small mobile device, it may not be fine. A small mobile device may want to be allowed to access the network much quicker than that. For this reason, feedback from MOBILEIP would be good. One of the problems on today's networks is that Ethernet switches that implement spanning tree often silently discard all packets for many seconds, which makes it hard to say how long a host should probe before using an address. One possibility is that we could revise the draft to say that on networks where successful connectivity can be determined by the hardware with some acceptable degree of certainty, all the timeouts can be ten times shorter than currently specified: i.e. 0-200ms initial delay, four packets 200ms apart, for a total probing time of 800-1000ms. Thoughts? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 16:06:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05987 for ; Mon, 4 Feb 2002 16:06:06 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA29331; Mon, 4 Feb 2002 13:05:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22023; Mon, 4 Feb 2002 13:04:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14L052Q003309 for ; Mon, 4 Feb 2002 13:00:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14L05kL003308 for mobile-ip-dist; Mon, 4 Feb 2002 13:00:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14L012Q003301 for ; Mon, 4 Feb 2002 13:00:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12825 for ; Mon, 4 Feb 2002 13:00:06 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02029 for ; Mon, 4 Feb 2002 13:00:05 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id B01C76A904 for ; Mon, 4 Feb 2002 23:00:02 +0200 (EET) Message-ID: <3C5EF68B.4060606@piuha.net> Date: Mon, 04 Feb 2002 23:00:59 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] BU Authorization method: design team recommendation References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The MIPv6 security design team is trying to resolve the issues around the method to use for authorizing binding updates. This note specifies the design team's motivation and current position. In order to move forward in an efficient manner it would be beneficial if responses could make it clear they are - a clarification (by putting CLARIFICATION: in the Subject field) - an issue with a particular point (by ISSUE:) - disagreement with the conclusion (by CONCLUSION:) We would also like folks to state for each of our six separate recommendations whether they AGREE, CAN TOLERATE, or DISAGREE with them. In case of DISAGREE, please explain why. 1. INTRODUCTION =============== To date, various BU authorization methods have been proposed. Of the proposals that don't assume a separate infrastructure the properties they rely on are either RR and/or CGA properties. An analysis of the security properties of those general categories of CGA and RR can be found at: http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt 2. ALTERNATIVES =============== The main alternatives for the actual address ownership authorization problem are: (a) Return Routability, RR (b) RR enhanced with Cryptographically Generated Addresses, CGA The security properties of these methods have been described in the URL referenced from section 1. In addition, there are a few additional properties we would like to bring to the attention: - CGA requires additional computational power. It is not clear though if this is big enough requirement to be an issue, particularly when very constrained nodes could refuse RO, and given that it has been demonstrated that protocols can be designed where MNs and CNs can offload their expensive computations to their HAs. - Several IPR claims have been made regarding CGA. In addition to the basic mechanism there are a few additional issues that we need to decide: (i) Whether or not Binding Security Associations (BSAs) are used (ii) What addresses need RR tests (HoA, CoA, or both), and what is the correct time to perform the tests, always at the time the binding is requested? 3. RECOMMENDATIONS ================== 1. The design team recommends a mandatory RR mechanism for IPv6 nodes, but with limitations on how long bindings can stay alive before they need to be refreshed. This recommendation is based on the findings of the security analysis, which point to some deficiences in the RR method below the "do no harm" principle, to which the limitations provide a reasonable answer. The RR mechanism should be placed in the MIPv6 RFC. Given that RR may not be sufficient in all situations or may need to be replaced later with something else, we recommend that a secure mechanism for selecting different BU authorization methods, using the "bit method" described in the URL referenced from section 1, is included in this RFC as well. 2. The design team additionally recommends an optional CGA mechanism to be standardized in a separate RFC in the MIPv6 WG, using the above "bit method". This recommendation is based on the findings of the security analysis, which point to lesser signaling requirements and improved security properties of CGA, as well as potential for solving additional, IPv6 problems. Due to IPR and CPU consumption concerns it seems problematic to make CGA a mandatory requirement, however. 3. Regarding issue (i), the design team recommends that the RR method should not use a BSA since we already recommend both HoA and CoA RR tests to be performed every time a binding is refreshed or updated with RR. For CGA, the design team recommends that a (simplified) BSA can be used to store the Diffie-Hellman value generated as a part of the initial binding, since with CGA, only the CoA test needs to be performed on every binding refresh. 4. Regarding issue (ii), the design team recommends both CoA and HoA tests to be performed every time binding is refreshed or updated with RR. We also recommend additionally that these tests are made using separate requests in order to avoid reflection problems with the authorization protocol itself (a BU authorization request sent from the CoA should not be answered to the HoA). This essentially leads to a five message exchange that lasts 1.5 RTTs since because two pairs of the messages can occur in parallel: 1a. MN(HoA)--->HA--->CN 1b. MN(CoA)--------->CN 2a. CN-------->HA--->MN(HoA) 2b. CN-------------->MN(CoA) 3. MN(CoA)--------->CN 5. In order to guarantee security of the above exchange, the HA-MN tunnel should be encrypted for the RR messages (but not necessarily for other messages on this tunnel). Note that there aren't similar scalability problems with this as there are with MN-CN security, since the home agents and mobile nodes must have an existing relationship anyway. This could be done e.g. using IPsec ESP with pre-shared keys. 6. For CGA, the design team recommends that 1a/2a can be omitted for all but the initial exchange and periodic tests every few hours or perhaps once a day. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 17:40:52 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07367 for ; Mon, 4 Feb 2002 17:40:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10365; Mon, 4 Feb 2002 14:40:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22458; Mon, 4 Feb 2002 14:36:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14MZY2Q003400 for ; Mon, 4 Feb 2002 14:35:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g14MZYVo003399 for mobile-ip-dist; Mon, 4 Feb 2002 14:35:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g14MZW2Q003392 for ; Mon, 4 Feb 2002 14:35:33 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20334 for ; Mon, 4 Feb 2002 17:35:49 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA12010 for mobile-ip@sunroof.eng.sun.com; Mon, 4 Feb 2002 17:36:34 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g13IxE2Q001232 for ; Sun, 3 Feb 2002 10:59:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21659 for ; Sun, 3 Feb 2002 10:59:28 -0800 (PST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15549 for ; Sun, 3 Feb 2002 10:59:28 -0800 (PST) Received: from yasmine.ece.arizona.edu (yasmine [128.196.28.123]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g13IxO3S025489 for ; Sun, 3 Feb 2002 11:59:24 -0700 (MST) Received: (from krunz@localhost) by yasmine.ece.arizona.edu (8.10.2+Sun/8.10.2) id g13J2hv08898 for mobile-ip@sunroof.eng.sun.com; Sun, 3 Feb 2002 12:02:43 -0700 (MST) Date: Sun, 3 Feb 2002 12:02:43 -0700 (MST) Message-Id: <200202031902.g13J2hv08898@yasmine.ece.arizona.edu> From: krunz@ece.arizona.edu To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobicom 2002 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Sorry if you receive duplicates of this message] Colleagues, Note that the deadline for Mobicom 2002 is less than one month away. Please find enclosed an updated CFP. M. Krunz ********************************************************************* Call for Papers *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Submission Deadline: March 1, 2002 ********************************************************************* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: - No longer than 12 pages (double column); in font no smaller than 10 points - Fit properly on US Letter-sized paper (8.5 ' 11 inches) with reasonable margins - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier,Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: * Paper submissions due: March 1, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu EXECUTIVE COMMITTEE: -------------------- * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Mercury Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Co-Chairs: - Suresh Singh, Portland State University - Robin Kravets, University of Illinois, Urbana-Champaign * Student Poster Co-Chairs: - Elizabeth M. Belding-Royer, University of California, Santa Barbara - Sung-Ju Lee, HP Laboratories * Student Travel Award Co-Chairs: - Yuguang Fang, University of Florida - Violet R. Syrotiuk, University of Texas at Dallas * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Webmaster: Michael E. Kounavis, Columbia University PROGRAM COMMITTEE: -------------------- Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University Program Committee: - Arup Acharya, IBM Research - Prathima Agrawal, Telcordia - B. R. Badrinath, Rutgers University - Victor Bahl, Microsoft Research - Stefano Basagni, Northeastern University - Roberto Battiti, University of Trento - Pravin Bhagwat, ReefEdge - Scott Corson, Flarion - Sajal Das, University Texas at Arlington - Nigel Davies, Lancaster University - Dan Duchamp, Stevens Institute of Technology - Maria Ebling, IBM Research - Magda El-Zarki, University of California, Irvine - Anthony Ephremides, University of Maryland - Deborah Estrin, University of California, Los Angeles - J.J. Garcia-Luna-Aceves, University of California at Santa Cruz - Kang G. Shin, University of Michigan - Mario Gerla, University of California, Los Angeles - Ramesh Govindan, USC/ISI - Nitin H. Vaidya, University of Illinois at Urbana-Champaign - Ravi Jain, Telcordia - David B. Johnson, Rice University - Anthony Joseph, University of California, Berkeley - Edward Knightly, Rice University - Tom LaPorta, Lucent Technologies - Songwu Lu, University of California, Los Angeles - Robert Morris, MIT - S. Muthukrishnan, AT&T Research - Venkat Padmanabhan, Microsoft Research - Charles Perkins, Nokia - Chiara Petrioli, Universit "La Sapienza" - George Polyzos, Athens University of Economics and Business - Parmesh Ramanathan, University of Wisconsin - Madison - Ram Ramanathan, BBN Technologies - Ramachandran Ramjee, Lucent Technologies - Daniela Rus, Dartmouth College - Srinivasan Seshan, Carnegie Mellon University - Suresh Singh, Portland State University - Leandros Tassiulas, University of Maryland - Mani Srivastava, University of California, Los Angeles - Frank Stajano, AT&T Laboratories Cambridge - Martha Steenstrup, Stow Research - Violet R. Syrotiuk, University of Texas at Dallas - Andras Valko, Ericsson Research - Adam Wolisz, Technical University of Berlin - Michele Zorzi, Universita di Ferrara From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 4 23:26:22 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13715 for ; Mon, 4 Feb 2002 23:26:21 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20257; Mon, 4 Feb 2002 20:25:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA28237; Mon, 4 Feb 2002 20:25:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g154Oi2Q004053 for ; Mon, 4 Feb 2002 20:24:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g154OiAN004052 for mobile-ip-dist; Mon, 4 Feb 2002 20:24:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g154Of2Q004045 for ; Mon, 4 Feb 2002 20:24:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05481 for ; Mon, 4 Feb 2002 20:24:57 -0800 (PST) Received: from disys.korea.ac.kr (disys.korea.ac.kr [163.152.39.181]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12536 for ; Mon, 4 Feb 2002 21:24:56 -0700 (MST) Received: from rickhan ([163.152.45.70]) by disys.korea.ac.kr (8.12.1/8.12.1) with SMTP id g154Kqlr004207 for ; Tue, 5 Feb 2002 13:20:52 +0900 (KST) Message-ID: <002701c1adfd$1b5ee6e0$462d98a3@disys42.korea.ac.kr> From: =?ks_c_5601-1987?B?x9G/rMjx?= To: Subject: [mobile-ip] Valid Period of Home Address Date: Tue, 5 Feb 2002 13:25:03 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C1AE48.84D71110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C1AE48.84D71110 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 QmVmb3JlIEkgcmVhZCB0aGUgTUlQdjYgZHJhZnQsIEkgYmVsaWV2ZWQgdGhlIGZvbGxvd2luZ3Mg DQoiQWZ0ZXIgdGhlIE1OIGFjcXVpcmVzIGEgaG9tZSBhZGRyZXNzLCB0aGUgaG9tZSBhZGRyZXNz IGlzIGZpeGVkIGF0IHRoZSBNTiBhbmQgaXMgcGVybWFuZW50LiINClRoYXQgaXMsIEkgaGF2ZSBh c3N1cmVkIHRoYXQgdGhlIGhvbWUgYWRkcmVzcyBvZiBhIE1OIGJlY29tZXMgdGhlIGlkZW50aWZp ZXIgb2YgdGhlIE1OLg0KDQpJbiBtYW55IHBsYWNlcyBpbiB0aGUgTUlQdjYgZHJhZnQsIGhvd2V2 ZXIsIHdlIGNhbiBmaW5kIHRoYXQgdGhlIGV0ZXJuaXR5IG9mIGhvbWUgYWRkcmVzcyBpcyBub3Qg dHJ1ZS4NCk9mIGNvdXJzZSwgdGhlIGhvbWUgbmV0d29yayByZW51bWJlcmluZyBhbmQgdGhlIGlu aXRpYWwgYWRkcmVzcyBjb25maWd1cmF0aW9uIGNhdXNlIHRoZSBob21lIGFkZHJlc3MgdG8gYmUg Y29uZmlndXJlZCBieSB1c2luZyAnSUNNUCBNb2JpbGUgUHJlZml4IFNvbGljaXRhdGlvbicuIA0K DQpCdXQsIHRoZSBJQ01QIG1lc3NhZ2UgaXMgYWxzbyB1c2VkIGluIG9yZGVyIHRvIHJlZnJlc2gg aG9tZSBhZGRyZXNzZXMgYmVmb3JlIHRoZSBleHBpcmF0aW9uIG9mIHRoZWlyIHZhbGlkaXR5Lg0K QWxzbywgSSB0aGluayB0aGF0IHRoZSBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24gaXMgYWxz byBhbm90aGVyIGV2aWRlbmNlIG9mIHRoZSBzaG9ydC1saXZlZCBvZiBob21lIGFkZHJlc3MuDQoN CklmIHRoZSBob21lIGFkZHJlc3MgaXMgbm90IHBlcm1hbmVudC4gSSBhbSB3b3JyaWVkIGFib3V0 IHRoZSBmb2xsb3dpbmdzLg0KDQoxLiBXZSBjYW5ub3QgZmluZCBhbnkgdGVybXMgYWJvdXQgdGhl IHZhbGlkIHBlcmlvZCBvZiBob21lIGFkZHJlc3MuIElzIHRoZSBwZXJpb2QgZGVwZW5kZWQgb2Yg YW4gaW1wbGVtZW50YXRpb24/DQoNCjIuIElmIHRoZSBob21lIGFkZHJlc3MgY2hhbmdlcywgaG93 IGRvZXMgYSBjb3JyZXNwb25kZW50IG5vZGUgb3BlbiBhbnkgVENQIGNvbm5lY3Rpb24gd2l0aCB0 aGUgTU4gYWZ0ZXIgdGhlIGNoYW5nZXM/DQoNCkkgYWRtaXQgdGhhdCBhbnkgdGVtcG9yYXJ5IGhv bWUgYWRkcmVzcyBzaG91bGQgYmUgdXNlZCBpbiBzb21lIGNhc2VzLiANCkhvd2V2ZXIsIHRoZSB0 ZW1wb3JhcnkgaG9tZSBhZGRyZXNzIGlzIGNvbmZsaWN0IHdpdGggdGhlIGZvbGxvd2luZyBnb2Fs IG9mIE1vYmlsZSBJUC4NCg0KIkVhY2ggbW9iaWxlIG5vZGUgaXMgYWx3YXlzIGlkZW50aWZpZWQg YnkgaXRzIGhvbWUgYWRkcmVzcywgcmVnYXJkbGVzcyBvZiBpdHMgY3VycmVudCBwb2ludCBvZiBh dHRhY2htZW50IHRvIHRoZSBJbnRlcm5ldCINCg0KVGhhbmtzIGluIGFkdmFuY2UuDQpCZXN0IHJl Z2FyZHMsDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCllvdW4tSGVlIEhhbg0KUGguRC4gU3R1ZGVudA0KRGlzdHJpYnV0 ZWQgU3lzdGVtcyBMYWIuDQpEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2UgJiBFbmdpbmVl cmluZy4gS29yZWEgVW5pdi4NCjEsIDUtR2EsIEFuYW0tRG9uZywgU3VuZ2J1ay1HdSwgU2VvdWwg MTM2LTcwMSwgS09SRUENClRlbCA6ICs4Mi0yLTkyNC0wNTQ3DQpGYXggOiArODItMi05NTMtMDc3 MQ0KTW9iaWxlIDogKzgyLTE2LTI2OC04NDYxDQpFbWFpbCA6IG1haWx0bzp5aGhhbkBkaXN5cy5r b3JlYS5hYy5rcg0KV1dXIDogaHR0cDovL2Rpc3lzLmtvcmVhLmFjLmtyL355aGhhbg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ------=_NextPart_000_0024_01C1AE48.84D71110 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI0NjIuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48Rk9O VCBzaXplPTI+QmVmb3JlIEkgcmVhZCB0aGUgTUlQdjYgZHJhZnQsIEkgYmVsaWV2ZWQgdGhlIGZv bGxvd2luZ3MgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4iQWZ0ZXIgdGhlIE1O IGFjcXVpcmVzJm5ic3A7YSBob21lIGFkZHJlc3MsIHRoZSBob21lIA0KYWRkcmVzcyZuYnNwO2lz IGZpeGVkIGF0IHRoZSBNTiBhbmQgaXMgcGVybWFuZW50LiI8L0ZPTlQ+PC9ESVY+DQo8RElWPlRo YXQgaXMsIEkgaGF2ZSBhc3N1cmVkIHRoYXQgdGhlIGhvbWUgYWRkcmVzcyBvZiBhIE1OIGJlY29t ZXMgdGhlIA0KaWRlbnRpZmllciBvZiB0aGUgTU4uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkluIG1hbnkgcGxhY2VzIGluIHRoZSBNSVB2 NiBkcmFmdCwgaG93ZXZlciwgd2UgY2FuIGZpbmQgdGhhdCANCnRoZSBldGVybml0eSBvZiBob21l IGFkZHJlc3MgaXMgbm90IHRydWUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+T2Yg Y291cnNlLCB0aGUgaG9tZSBuZXR3b3JrIHJlbnVtYmVyaW5nIGFuZCB0aGUgaW5pdGlhbCANCmFk ZHJlc3MgY29uZmlndXJhdGlvbiBjYXVzZSB0aGUgaG9tZSBhZGRyZXNzIHRvIGJlIGNvbmZpZ3Vy ZWQgYnkgdXNpbmcgJ0lDTVAgDQpNb2JpbGUgUHJlZml4IFNvbGljaXRhdGlvbicuIDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPkJ1dCwgdGhlIElDTVAgbWVzc2FnZSBpcyBhbHNvIHVzZWQgaW4gb3JkZXIgdG8gPC9G T05UPjxGT05UIA0Kc2l6ZT0zPnJlZnJlc2ggaG9tZSBhZGRyZXNzZXMgYmVmb3JlIHRoZSBleHBp cmF0aW9uIG9mIHRoZWlyIA0KdmFsaWRpdHkuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+QWxzbywgSSB0aGluayB0aGF0IHRoZSBEdXBsaWNhdGUgQWRkcmVzcyBEZXRlY3Rpb24gaXMg YWxzbyANCmFub3RoZXIgZXZpZGVuY2Ugb2YgdGhlIHNob3J0LWxpdmVkIG9mIGhvbWUgYWRkcmVz cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj5JZiB0aGUgaG9tZSBhZGRyZXNzIGlzIG5vdCBwZXJtYW5lbnQuIEkg YW0gd29ycmllZCBhYm91dCB0aGUgDQpmb2xsb3dpbmdzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjEuJm5ic3A7 V2UgY2Fubm90IGZpbmQgYW55IHRlcm1zIGFib3V0IHRoZSB2YWxpZCBwZXJpb2Qgb2YgDQpob21l IGFkZHJlc3MuIElzIHRoZSBwZXJpb2QmbmJzcDtkZXBlbmRlZCBvZiBhbiBpbXBsZW1lbnRhdGlv bj88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4yLiBJZiB0aGUgaG9tZSBhZGRyZXNzIGNoYW5nZXMsJm5ic3A7aG93 IGRvZXMgYSBjb3JyZXNwb25kZW50IA0Kbm9kZSZuYnNwO29wZW4gYW55IFRDUCBjb25uZWN0aW9u IHdpdGggdGhlIE1OIGFmdGVyIHRoZSBjaGFuZ2VzPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgYWRtaXQgdGhh dCZuYnNwO2FueSB0ZW1wb3JhcnkgaG9tZSBhZGRyZXNzIHNob3VsZCBiZSB1c2VkIGluIA0Kc29t ZSBjYXNlcy4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SG93ZXZlciwgdGhlIHRl bXBvcmFyeSBob21lIGFkZHJlc3MgaXMgY29uZmxpY3Qgd2l0aCANCnRoZSZuYnNwO2ZvbGxvd2lu ZyBnb2FsIG9mIE1vYmlsZSBJUC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4iRWFjaCBtb2JpbGUgbm9kZSBpcyBh bHdheXMgaWRlbnRpZmllZCBieSBpdHMgaG9tZSBhZGRyZXNzLCANCnJlZ2FyZGxlc3Mgb2YgaXRz IGN1cnJlbnQgcG9pbnQgb2YgYXR0YWNobWVudCB0byB0aGUgSW50ZXJuZXQiPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5UaGFua3MgaW4g YWR2YW5jZS48L0RJVj4NCjxESVY+QmVzdCByZWdhcmRzLDwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCANCnNpemU9Mj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPllvdW4t SGVlIA0KSGFuPEJSPlBoLkQuIFN0dWRlbnQ8QlI+RGlzdHJpYnV0ZWQgU3lzdGVtcyBMYWIuPEJS PkRlcGFydG1lbnQgb2YgQ29tcHV0ZXIgDQpTY2llbmNlICZhbXA7IEVuZ2luZWVyaW5nLiBLb3Jl YSBVbml2LjxCUj4xLCA1LUdhLCBBbmFtLURvbmcsIFN1bmdidWstR3UsIFNlb3VsIA0KMTM2LTcw MSwgS09SRUE8QlI+VGVsIDogKzgyLTItOTI0LTA1NDc8QlI+RmF4IDogKzgyLTItOTUzLTA3NzE8 QlI+TW9iaWxlIDogDQorODItMTYtMjY4LTg0NjE8QlI+RW1haWwgOiA8QSANCmhyZWY9Im1haWx0 bzp5aGhhbkBkaXN5cy5rb3JlYS5hYy5rciI+bWFpbHRvOnloaGFuQGRpc3lzLmtvcmVhLmFjLmty PC9BPjxCUj5XV1cgDQo6IDxBIA0KaHJlZj0iaHR0cDovL2Rpc3lzLmtvcmVhLmFjLmtyL355aGhh biI+aHR0cDovL2Rpc3lzLmtvcmVhLmFjLmtyL355aGhhbjwvQT48QlI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0024_01C1AE48.84D71110-- From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 00:33:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14966 for ; Tue, 5 Feb 2002 00:33:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00079; Mon, 4 Feb 2002 22:33:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13492; Mon, 4 Feb 2002 21:33:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g155W42Q004165 for ; Mon, 4 Feb 2002 21:32:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g155W4n6004164 for mobile-ip-dist; Mon, 4 Feb 2002 21:32:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g155W12Q004157 for ; Mon, 4 Feb 2002 21:32:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06001 for ; Mon, 4 Feb 2002 21:32:17 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14222 for ; Mon, 4 Feb 2002 21:32:16 -0800 (PST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id GAA08761; Tue, 5 Feb 2002 06:32:14 +0100 (MET) Date: Tue, 5 Feb 2002 06:32:14 +0100 (MET) Message-Id: <200202050532.GAA08761@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: dhcwg@ietf.org, mobile-ip@sunroof.eng.sun.com In-reply-to: <200202041944.g14JiY026372@scv2.apple.com> (message from Stuart Cheshire on Mon, 4 Feb 2002 11:44:34 -0800) Subject: Re: [mobile-ip] IPv4 Address Conflict Detection References: <200202041944.g14JiY026372@scv2.apple.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think the idea of probing and waiting _before_ using an address is completely wrong. Since it involves waiting for something _not_ to happen. The better approach is to detect the conflict -- if there is one. See: @misc{ vatn-effect, author = "Jon-Olov Vatn and Gerald Q. Maguire Jr.", title = "The effect of using co-located care-of addresses on macro handover latency", url = "http://citeseer.nj.nec.com/264743.html" } ftp://ftp.it.kth.se/Reports/ts/1998/nts14-coloc.pdf This paper shows that the DHCP server can be doing testing of addresses in advance and this significantly reduce the time required to assign and address. This is critical if you are going to give a mobile device an IP address on a new segment when it arrive and avoid having to drop packets for it (for example from an audio stream). See also: Jon-Olov Vatn, "Long Random Wait Times for Getting a Care-of Address are a Danger to Mobile Multimedia", 1999 IEEE International Workshop on Mobile Multimedia Communications (MoMuC'99), 15-17 November 1999, San Diego, CA USA. http://www.it.kth.se/~vatn/research/momuc-copyright.pdf For his licentiate thesis which includes the above and more see: http://www.it.kth.se/~vatn/mac/lic_prop.fm5.ps Chip From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 02:31:47 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24704 for ; Tue, 5 Feb 2002 02:31:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23446; Mon, 4 Feb 2002 23:31:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01405; Mon, 4 Feb 2002 23:30:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g157Tg2Q004250 for ; Mon, 4 Feb 2002 23:29:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g157TgQ1004249 for mobile-ip-dist; Mon, 4 Feb 2002 23:29:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g157Td2Q004242 for ; Mon, 4 Feb 2002 23:29:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00973 for ; Mon, 4 Feb 2002 23:29:54 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19948 for ; Tue, 5 Feb 2002 00:29:54 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA22434; Mon, 4 Feb 2002 23:29:53 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g157Tr527032; Mon, 4 Feb 2002 23:29:53 -0800 X-mProtect: Mon, 4 Feb 2002 23:29:53 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdREbli0; Mon, 04 Feb 2002 23:29:51 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id XAA65580; Mon, 4 Feb 2002 23:29:51 -0800 (PST) Message-ID: <3C5F89EF.9C6ADC01@iprg.nokia.com> Date: Mon, 04 Feb 2002 23:29:51 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Charlie Perkins , Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > In order to talk more intelligently about this it seems like we need > to understand: > 1. Mobile routers/networks and how route optimization should > work with such > 2. Explicit routing using source routing - will applications > do this? > 3. How #1 and #2 should interact > > To me saying whether destination options, routing headers, or Deering/Zill > tunneling fit better in this completely undefined space seems > to be rather unproductive speculation. Cannot agree more with this argument. It would therefore be logical to concentrate on asking what is known, to limit the analysis needed, and on host mobility requirements. Hence, to go beyond saying just new RH, below, as a longer technical answer, is a treatment of the issue reflecting it against the keyword "undefined" you mention. Comparison of new RH replacements based on their "undefinedness", for - New Routing Header - New Destination Option - ZOD/MR ZOD Tunneling - Deering-Zill Tunneling - New Header Type 1. New Routing Header A Routing Header is a routing semantics entity with the property that even though a node receives the packet, the header causes further forwarding of the packet, through re-submission to the network layer, towards the same or another L3 endpoint, internal or external to the node. The security requirements call for the specific property of the endpoint being internal to the node (a known property required for all 5 alternatives, to enforce the stateless filtering of packets not staying in the destination node, based on packet content only). Known properties: - Header Type: Routing Header - Header structure: same as RH T0, with the limitation of 1 address; we always have this entity alone in a header. - Processing Rules (as with RH T0), exactly, except for limiting forwarding out of the node. - Other behavior: Path MTU: as in IPv6. Very simplified note: A "beautiful" implementation may provide a way such as described by Francis, a more common way is to keep packet less or equal than the minimum IPv6 MTU of 1280 octets or that fragmentation is possible otherwise (a less robust but still "acceptable" IPv6 stack?). - Problems resulting from use for other purposes: None, since this is meant (currently) for the sole purpose of host mobility. When the condition in the future may be relaxed, e.g. for the above unknowns you mention, the general requirement may get broken, possibly in an uncontrolled way. - Final properties since this uses a standardized header. - Interaction with IPsec (as RH T0) Derivable properties - Header ordering rules (e.g., as described by Pekka Savola) Unknown properties: - None (?). Requirement for change - 1 bit in format, enforcement of ordering rules against RH T0, enforcement of node-internal only forwarding. 2. New DO This is an entity with endpoint semantics, that is, by reception this destination option is meant to be consumed by the final L3 communication endpoint in the host which directly delivers the upper layer part of the packet to the transport layer. Known properties: - Header Type: Destination Header - Problems resulting from use for other purposes: None, since this is meant (currently) for the sole purpose of host mobility. Derivable properties - Header structure: Possibly the option alone, possibly with other DOs. In the latter case may need more rules. Option format: Possibly like HAO. - Header ordering rules. Probably immediately after HAO. - Processing Rules: As with HAO but for IP hdr dst. addr. - Final properties since this uses a standardized header with MIPv6 draft version 15 DO HAO as a model for the DO. - Interaction with IPsec (as HAO) Unknown properties: - None (??). Requirement for change - Addition of a new Dst Opt processing. Format, enforcement of ordering rules, option-internal rules. Since no forwarding is assumed, no need for enforcing node-internal forwarding. 3. ZOD/MR.ZOD Tunneling This is an entity with unselected semantics, both endpoint and routing semantics are described, but no restriction has been made. That is, by reception, the Shim either switches endpoint addresses from authorized state for internal delivery to upper layer or in case of generalization, packet is forwarded based on state. Non-generalized mode (NGM) fulfills the generic requirement of not forwarding out of the node. Alternatively this could have been treated as the applicable component of the proposal but since this is a whole draft, NGM cannot realistically be just extracted to MIPv6 draft? Known properties: - Header Type: Nothing needed (except a flag both ways) Derivable properties - Position of the flag, this was not specified for all cases, but rough alternatives were given. Unknown properties: - Problems resulting from use for other purposes: Not known, since this proposal does not restrict itself to host mobility. The choice for delivery vs. forwarding was not made nor strict restriction to use with host mobility in delivery, nor the use of RO signaling as establishing the state were mandated. This many open options leave room for too many unknowns given the level of security required for the choice at hand. - Interaction/security with other protocols (given the amount of security and other analysis in MIPv6, any generic new method deserves this note) - All possible signaling methods for setting up the authorized state (a downside of the proposal is its reliance on state, which gets the critique all non-routing-state-based forwarding usually does, esp. in its generalized format) - Final stabilized properties, since there may be changes due to problems found with other uses. - Interaction with IPsec Requirement for change - Entry and processing of the bits (Shims) - Possible robustness features (several, some due to statefulness) Summary: if it had restricted itself to host IPv6 mobility only, it would have been a stronger candidate. Then, I do not give the proper credit to this otherwise well thought draft, it should be a contender with the Deering-Zill tunneling, though the requirement for state in forwarding is a liability. 4. Deering-Zill Tunneling This has a clear routing semantics, its compressed tunneling headers call for a unambiguous forwarding close to that in plain tunneling. However, for route-optimized traffic to work between all nodes, unrestricted DZ-tunneling through filters should be allowed so I have a doubt the generic requirement for stateless filter-based reflection protection can in all the cases be fullfilled (I obviously missed something). Known properties: - Header Types, ordering, header formats, processing (much is known) Derivable properties - operation with host mobility - Some security behavior that is not repeated in the draft Unknown properties: - Problems resulting from use for other purposes: Not known, since this proposal does not restrict itself to host mobility. - Interaction/security with other protocols (given the amount of security and other analysis in MIPv6, any generic new method deserves this note) - Final stabilized properties, since there may be changes due to problems found with other uses. - Interaction with IPsec (a part of it) Requirement for change - Generation and processing of new header types Summary: This proposal has a cleaner semantics and would have been a stronger candidate should its security implications for all its potential uses (IPsec etc) have been better understood today. 5. New Extension Header This is the most unknown in its semantics, all is open here. We can construct another routing header -like extension header or a new destination header -like entity, just to begin to enumerate the open choices. Known properties - None, except the general requirement Derivable properties - Format contains an address Unknown properties - Everything else Requirement for change - Unknown Summary: not a serious alternative given the level of missing detail that would be needed by now. Based on this dimension of analysis, I would prefer routing header, the DO being the other realistic alternative but with significantly more towards unknowns while all the others having too many unknowns to be realistic to adopt today for the very specific use of host mobility that RH here has had (both tunneling methods, esp. Deering-Zill, have much potential for later use but with some questions of their applicability now). > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 04:55:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26123 for ; Tue, 5 Feb 2002 04:55:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11788; Tue, 5 Feb 2002 02:46:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15580; Tue, 5 Feb 2002 01:45:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159i92Q004683 for ; Tue, 5 Feb 2002 01:44:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g159i9cb004682 for mobile-ip-dist; Tue, 5 Feb 2002 01:44:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g159hv2Q004647 for ; Tue, 5 Feb 2002 01:43:57 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g159i9M11071; Tue, 5 Feb 2002 10:44:09 +0100 (MET) Date: Tue, 5 Feb 2002 09:43:06 +0100 (CET) From: Erik Nordmark Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E01D7E735@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > As I recall, #3 was this: > > "3. Try to simplify things by not using Routing Headers for MIPv6." Glenn, No, #3 was "define something new instead of using RH type 0". One of the possible new things would be a new RH type. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 05:18:47 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26444 for ; Tue, 5 Feb 2002 05:18:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11545; Tue, 5 Feb 2002 02:18:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05933; Tue, 5 Feb 2002 02:17:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFM2Q004940 for ; Tue, 5 Feb 2002 02:15:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15AFLMs004939 for mobile-ip-dist; Tue, 5 Feb 2002 02:15:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFC2Q004919 for ; Tue, 5 Feb 2002 02:15:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05368 for ; Tue, 5 Feb 2002 02:15:27 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28179 for ; Tue, 5 Feb 2002 03:15:26 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g15AFPX4028589 for ; Tue, 5 Feb 2002 11:15:25 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Feb 05 11:15:24 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:06:04 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D559@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: RE: [mobile-ip] draft on random interface identifiers available Date: Tue, 5 Feb 2002 11:14:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I really think you should announce this draft on the ipv6 list and try to discuss it there. This is clearly an ipv6 WG issue. Whether it is motivated by mobility or not is a different discussion. Hesham > -----Original Message----- > From: Ignacio Soto Campos [mailto:isoto@it.uc3m.es] > Sent: Monday, February 04, 2002 4:52 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: marcelo@it.uc3m.es; alberto@it.uc3m.es > Subject: [mobile-ip] draft on random interface identifiers available > > > Hi all, > > We have submitted the draft "Random generation of interface > identifiers" that is available from: > > http://www.ietf.org/internet-drafts/draft-soto-mobileip-rand > om-iids-00.txt > > The abstract is included below. Comments are welcomed. > > Abstract > > This document evaluates the use of random numbers to generate the > interface identifier part of an IPv6 address on mobile > environments, > where Duplicate Address Detection (DAD) mechanisms are expensive. > We have estimated the probability of having an address > duplication > using this mechanism and we conclude that the IPv6 > addresses created > in this way could be used without previously doing DAD > to test the > uniqueness of the address in a link. > > > Best regards, > > Ignacio > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 05:19:14 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26458 for ; Tue, 5 Feb 2002 05:19:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11442; Tue, 5 Feb 2002 02:17:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05827; Tue, 5 Feb 2002 02:16:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFB2Q004917 for ; Tue, 5 Feb 2002 02:15:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15AFBq2004916 for mobile-ip-dist; Tue, 5 Feb 2002 02:15:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AF52Q004895 for ; Tue, 5 Feb 2002 02:15:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02652 for ; Tue, 5 Feb 2002 02:15:21 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02228 for ; Tue, 5 Feb 2002 02:15:20 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g15AFJX4028507 for ; Tue, 5 Feb 2002 11:15:19 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Feb 05 11:15:18 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:14:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D552@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Tue, 5 Feb 2002 11:14:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Erik Sorry, I'm a bit behind on email. > > I understand that this is a bit speculative but > I'm trying to understand the details of the tradeoffs ... > > Do you think the other two possible encodings (destination option > or a different extension header altogether) would not allow > this behavior in the receiver? => I can say that the destination option would not allow this behaviour because by definition it will only be processed by the ultimate receiver of the packet. As for another header altogether, I think it depends on whether it can be processed by the Mobile router or not (i.e. before it gets to the end host). I think it's important to explain my assumptions here. The solution I'm referring to assumes that the network behind the MR does not get renumbered. Only the MR's interface (facing the default (fixed) router) is renumbered. Essentially the MR acts as an FA by letting MNs use its address as a CoA. The reason I'm making this assumption is that I wanted to achieve fast mobility and assumed that renumbering the entire network would be too slow (*). > It seems to me that at least a different extension header would have > close to identical properties to IPv6_NO_SRC. => Sure, but only if the can be processed by the MR. IP in IP would work provided that the outer dst address is the MR's address (MN's CoA). Hesham PS: FWIW I think IP in IP is the cleanest way to solve this, it's been used and well understood. But I understand that people want to finish the spec and this might sound too revolutionary. (*) This is the approach we took in HMIPv6. I do not claim that this is the best way to do it. I was just explaining why it was done. If MONET becomes a WG we might have hbetter approaches. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 05:21:50 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26520 for ; Tue, 5 Feb 2002 05:21:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA12392; Tue, 5 Feb 2002 02:19:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06064; Tue, 5 Feb 2002 02:17:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFJ2Q004937 for ; Tue, 5 Feb 2002 02:15:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15AFJZK004936 for mobile-ip-dist; Tue, 5 Feb 2002 02:15:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AF92Q004909 for ; Tue, 5 Feb 2002 02:15:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19047 for ; Tue, 5 Feb 2002 02:15:24 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02252 for ; Tue, 5 Feb 2002 02:15:23 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g15AFMC21611 for ; Tue, 5 Feb 2002 11:15:22 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 05 11:14:54 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:06:01 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D555@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RH some consensus Date: Tue, 5 Feb 2002 11:14:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Phil, > There has been some interest stated towards not precluding > the use of > mechanisms > in MIPv6 to enable future support of mobile > routers/networks. Given that > the mobile router > space is not well understood in the community, it seems > unwise to spend a > lot of time making > sure the mechanisms we are defining now in order to get > MIPv6 to PS, support > mobile routers. > => I don't think anyone wants to spend a lot of time to decide on the right option for MRs. If the choice is between 3 equal options then it won't hurt to choose something that may be useful for MRs. It might actually be very useful to do so. Incidently what some of us think is good for MRs is IPv6_NO_SRC or new RH type. New RH type will cost no time at all. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 05:22:39 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26542 for ; Tue, 5 Feb 2002 05:22:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11375; Tue, 5 Feb 2002 02:17:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05818; Tue, 5 Feb 2002 02:16:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AFF2Q004927 for ; Tue, 5 Feb 2002 02:15:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15AFFU6004926 for mobile-ip-dist; Tue, 5 Feb 2002 02:15:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15AF72Q004902 for ; Tue, 5 Feb 2002 02:15:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05339 for ; Tue, 5 Feb 2002 02:15:22 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10039 for ; Tue, 5 Feb 2002 03:15:21 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g15AFKC21579 for ; Tue, 5 Feb 2002 11:15:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Feb 05 11:15:18 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 11:14:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D557@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: RE: [mobile-ip] RH and path MTU discovery Date: Tue, 5 Feb 2002 11:14:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, Don't kow if this was already answered, but I'll answer it anyway. Erik is making a very valid point about whether the draft addresses how a CN receiving an ICMP error (packet too large) for a packet containing the routing header. The draft is silent on this issue. I've been to only one interop test when I was working on our MIPv6 implementation and we never had a test case for this. Furthermore, I never saw a test case for this in the current test suites. I think the draft must explain the behaviour of the implementation when this happens. Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, February 01, 2002 6:10 PM > To: Erik Nordmark > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] RH and path MTU discovery > > > Erik, > > "This" is the problem you laid out in your original message, namely > RH insertion resulting in the known path MTU becoming invalid. > > But I see that others have made the point that was I think bothering > me, namely that having the path MTU become invalid is something > that could potentially occur for other reasons, and so a > sufficiently > robust IPv6 stack would have to be prepared for it. > > jak > > ----- Original Message ----- > From: "Erik Nordmark" > To: > Cc: > Sent: Friday, February 01, 2002 3:19 AM > Subject: Re: [mobile-ip] RH and path MTU discovery > > > > > > > How is this different from the case where a router fails on the > > > original path and the route changes so that the original > > > path MTU is no longer valid? > > > > I don't understand what "this" exactly refers to. > > Are you referring to the MIPv6 specific part (the fact that in a > layered > > implementation the IP layer adds the RH) or something else? > > > > Erik > > > > > From: "Erik Nordmark" > > > To: > > > Sent: Thursday, January 31, 2002 1:31 AM > > > Subject: [mobile-ip] RH and path MTU discovery > > > > > > > > > > Question for the list: > > > > > > > > I was thinking about "RH works for MIPv6" - have implementors > > > > tested the interaction of MIPv6/RH with Path MTU discovery > > > > and figured out how to make sure it works? > > > > > > > > The mipv6 draft doesn't say anything about this but > it seems like > > > > there are similar path MTU issues RH insertion by the IP stack > > > > as there are with IPsec tunnel insertion by the IP stack > > > > thus this is something that we presumably need to make sure is > > > > well documented. > > > > > > > > The issues are: > > > > TCP when initiating a connection needs to know which > MSS to use. > > > > The MSS will be different if the IP layer, e.g. based > on a binding > > > cache > > > > entry, inserts things in the packet. This is > independent whether > what > > > is > > > > added is a RH, a HOA, or an extra IP header. > > > > It seems like some advise would be useful to point > out this issue. > > > > > > > > If a TCP connection starts out without using RH and > later route > > > optimization > > > > has been setup (causing RH to be added by the IP layer) then a > packet > > > > that previously fit in the MTU will no longer fit. Thus the IP > layer > > > needs > > > > to be able to notify the TCP layer that it is adding > N bytes to > the > > > packets > > > > so that TCP can adjust its understanding of the effective path > MTU. > > > > > > > > Finally, during the connection there could be changes in the > routing > > > path > > > > to the MN causing routers to send back ICMP packet too big > messages. > > > > Such packets would need to be recognized by TCP as > effecting the > MTU > > > > for the connection even though the destination field in the > > > > "packet in error" in the ICMP packet is the CoA instead of the > HoA. > > > > An explicit example: > > > > TCP generates a packet with > > > > src = CN > > > > dst = HoA > > > > (and TCP already knows that IP will add 24 bytes due > to the RH so > > > > it doesn't send packets that are too big) > > > > > > > > This causes IP to send > > > > src = CN > > > > dst = CoA > > > > routing header with seg-left = 1, address = HoA > > > > > > > > If the packet is too big somewhere along the path an ICMP > > > > error will be sent back with > > > > src = some router > > > > dst = CN > > > > ICMP packet too big > > > > mtu = 1300 > > > > packet in error > > > > src = CN > > > > dst = CoA > > > > routing header with seg-left = 1, address = HoA > > > > > > > > The actual processing of this can be split between IP > and TCP but > > > > the effect must be the same as TCP having received a too big > > > > packet reporting a smaller MTU and where the dst was > the HoA i.e. > > > > src = some router > > > > dst = CN > > > > ICMP packet too big > > > > mtu = 1276 <=== NOTE > > > > packet in error > > > > src = CN > > > > dst = HoA <=== NOTE > > > > > > > > One possible way to implement this is to have the IP > layer convert > > > > the ICMP error before passing it to TCP. Another possible way > > > > would be to have TCP be able to adjust the reported MTU > > > > and extract the destination address from the RH. > > > > > > > > > > > > Do implementations already solve this? Has it been > widely tested? > > > > > > > > RFC 2473 describes the solution to this in the more > general case > of > > > > IP-in-IPv6 tunneling, thus that might be useful as background > reading. > > > > > > > > Erik > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 06:06:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26978 for ; Tue, 5 Feb 2002 06:06:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25758; Tue, 5 Feb 2002 03:06:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21008; Tue, 5 Feb 2002 03:05:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15B4f2Q005452 for ; Tue, 5 Feb 2002 03:04:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15B4f3B005451 for mobile-ip-dist; Tue, 5 Feb 2002 03:04:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15B4b2Q005444 for ; Tue, 5 Feb 2002 03:04:37 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15B4lM21242; Tue, 5 Feb 2002 12:04:47 +0100 (MET) Date: Tue, 5 Feb 2002 12:00:54 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: "Jari T. Malinen" Cc: mobile-ip@sunroof.eng.sun.com, Charlie Perkins , Erik Nordmark In-Reply-To: "Your message with ID" <3C5F89EF.9C6ADC01@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, Thanks for putting together this list - it is quite useful. I might steal parts of it in order to complete the comparison writeup that Phil is pushing to get completed. > - Processing Rules (as with RH T0), exactly, except for limiting > forwarding out of the node. It might also make sense to restrict so that the address in the RH is in fact a Home Address of the MN. > - Other behavior: Path MTU: as in IPv6. Very simplified note: > A "beautiful" implementation may provide a way such > as described by Francis, a more common way is to keep packet > less or equal than the minimum IPv6 MTU of 1280 octets or that > fragmentation is possible otherwise (a less robust but still > "acceptable" IPv6 stack?). I think you have to require that the applications limit the messages they send so that the resulting packets (with a 40 byte IP header and UDP header etc) does not exceed 1280-24=1256 bytes in order to allow the IP layer to insert the RH. Of course, for MN to MN communication both a HOA and RH are inserted so the applications need to send even smaller packets. Assuming the applications will do this might be problematic since there might be applications which actually think that 1280 is the limit. So I think reasonable PMTU handling is necessary - indepedent of whether this is a new RH type, destination option, or Deering/Zill tunneling. My only point was that for tunneling the problem is well understood and written down in RFCs. > - Problems resulting from use for other purposes: None, since > this is meant (currently) for the sole purpose of host mobility. > When the condition in the future may be relaxed, e.g. for the > above unknowns you mention, the general requirement may get > broken, possibly in an uncontrolled way. There is a slight risk, deriving from the fact that this RH type 1 isn't used for source routing but has a name which makes it sound like source routing, that firewalls will just drop all source routed packets. If something other than RH is used I think it will help communicate to the firewall implementors that its a MIPv6 "header" hence firewalls should only block it if they want to block MIPv6. > - Final properties since this uses a standardized header. > - Interaction with IPsec (as RH T0) > > Derivable properties > - Header ordering rules (e.g., as described by Pekka Savola) Did he describe what should happen when RH type NEW is followed by RH type 0 in the packet? > 2. New DO > > This is an entity with endpoint semantics, that is, by reception > this destination option is meant to be consumed by the final L3 > communication endpoint in the host which directly delivers the > upper layer part of the packet to the transport layer. > > Known properties: > - Header Type: Destination Header > - Problems resulting from use for other purposes: None, since > this is meant (currently) for the sole purpose of host mobility. > > Derivable properties > - Header structure: Possibly the option alone, possibly with > other DOs. In the latter case may need more rules. I imagine we want the rule that when both HAO and ADA options are sent they MUST be included in the same destination options header. It makes no sense to allow two destination option headers in the packet for the purpose of having one carry the HAO and the other carry the ADA and I suspect it's easier for an implementation to be able to extract both addresses in the same context in the code. > Option format: Possibly like HAO. > - Header ordering rules. Probably immediately after HAO. > - Processing Rules: As with HAO but for IP hdr dst. addr. > - Final properties since this uses a standardized header with > MIPv6 draft version 15 DO HAO as a model for the DO. > - Interaction with IPsec (as HAO) > > Unknown properties: > - None (??). > > Requirement for change > - Addition of a new Dst Opt processing. > Format, enforcement of ordering rules, option-internal rules. > Since no forwarding is assumed, no need for enforcing > node-internal forwarding. Hmm - I think we actually need wording that says that the address in the ADA must be at least an IP address assigned to the node (and perhaps we want to constrain this to be a Home Address assigned to the node) to prevent implementations that replacing the IP destination field with the ADA (so that transport protocols can easily find the destination HoA) in the case when the ADA is not assigned to the node. > 4. Deering-Zill Tunneling > > [...] > Requirement for change > - Generation and processing of new header types I think there are also implementation considerations for implementations which have IP-in-IP as a pseudo-device driver since with DZ-tunneling the MN-to-MN traffic would presumably use full IP-in-IP tunnel headers. In that case the pseudo-device driver for tunnel decapsulation would need to have a way to check with the MIP part of the code whether decapsulation of a particular packet should be allowed. > Summary: This proposal has a cleaner semantics and would have > been a stronger candidate should its security implications for > all its potential uses (IPsec etc) have been better understood > today. > > 5. New Extension Header > > This is the most unknown in its semantics, all is open here. > We can construct another routing header -like extension header > or a new destination header -like entity, just to begin to > enumerate the open choices. It seems like having a new extension header to just carry the destination HoA doesn't make much sense - the source HoA would still be a destination option. If both source HoA and destination HoA (when both are needed) are carried in such a new header the proposal seems to become either (depending on processing rules and header order rules I think) like DZ tunneling *or* like a new destination option for the destination HoA. > Known properties > - None, except the general requirement > > Derivable properties > - Format contains an address > > Unknown properties > - Everything else > > Requirement for change > - Unknown > > Summary: not a serious alternative given the level of missing > detail that would be needed by now. > Based on this dimension of analysis, I would prefer routing > header, the DO being the other realistic alternative but with > significantly more towards unknowns while all the others having > too many unknowns to be realistic to adopt today for the very > specific use of host mobility that RH here has had (both tunneling > methods, esp. Deering-Zill, have much potential for later use > but with some questions of their applicability now). Your list didn't include any unknowns for the DO case, but above you refer to such unknows (if I parse the sentence correctly). I agree there are a lot more unknowns for the other alternatives. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 06:47:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27687 for ; Tue, 5 Feb 2002 06:47:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07542; Tue, 5 Feb 2002 03:46:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17159; Tue, 5 Feb 2002 03:46:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15BjM2Q005522 for ; Tue, 5 Feb 2002 03:45:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15BjMkg005521 for mobile-ip-dist; Tue, 5 Feb 2002 03:45:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15BjJ2Q005514 for ; Tue, 5 Feb 2002 03:45:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27598; Tue, 5 Feb 2002 03:45:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06222; Tue, 5 Feb 2002 04:45:31 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g15BjQ613232; Tue, 5 Feb 2002 12:45:29 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA04972; Tue, 5 Feb 2002 12:45:26 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g15BjPg68339; Tue, 5 Feb 2002 12:45:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202051145.g15BjPg68339@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 04 Feb 2002 14:33:47 +0100. Date: Tue, 05 Feb 2002 12:45:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: So same question I've been asking Charlie - what would combining RH and MIPv6 (assuming MIPv6 didn't use RH) actually be useful for? => each time an advanced routing feature is used with MIPv6. Mobile routers and/or mobile network? => this is the main example but there are others like policy routing, VPNs, multicast routing, etc. But I agree the main issue of the home address as an identifier is mobile routers and/or networks. Is what I call "nesting" (recursive application) close to what you mean by "routing device"? => this is an important example of "routing device" but there are others, for instance multicast routing, which can use very different mechanisms (i.e. Reverse Path Forwarding check has nothing to do with "nesting"). The chairs already declared consensus on approach #3 (i.e. to define somehing new for MIPv6). I'm trying to capture a list of pros and cons for New RH type New (ADA) destination option Deering/Zill tunneling New extension header => I believe we can remove the last one (new extension header) and we should wait for HAO if we'd like to really discuss about D/Z tunneling. So the purpose of me asking stupid(?) questions is to make sure I understand the pros and cons that people bring up. => I believe we already got all arguments about RH and ADA. What we need is more organization and feed back from other issues (if we'll give up HAO the situation will be very different). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 07:31:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28376 for ; Tue, 5 Feb 2002 07:31:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24069; Tue, 5 Feb 2002 05:30:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24613; Tue, 5 Feb 2002 04:30:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15CTH2Q005655 for ; Tue, 5 Feb 2002 04:29:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15CTHmx005654 for mobile-ip-dist; Tue, 5 Feb 2002 04:29:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15CTE2Q005647 for ; Tue, 5 Feb 2002 04:29:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05420 for ; Tue, 5 Feb 2002 04:29:28 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA23193 for ; Tue, 5 Feb 2002 05:29:22 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 6E41743140; Tue, 5 Feb 2002 13:29:19 +0100 (CET) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 4EA3099E7A; Tue, 5 Feb 2002 13:29:18 +0100 (CET) Message-ID: <3C5FD01B.AD58421A@it.uc3m.es> Date: Tue, 05 Feb 2002 13:29:15 +0100 From: Ignacio Soto Campos X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available References: <4DA6EA82906FD511BE2F00508BCF053802D4D559@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, We do agree that this draft involves IPv6 issues, however we think that previous discussion in the mobileip WG is interesting. The reason is that the motivation for the draft is a mobileip matter, so we'd like to know if the described approach are seen as relevant for mobile environments. Eventually, if relevance is stated, the presented approach could be introduced to the ipv6 WG, or could be proposed as a modification for IPv6 in mobile nodes, which would be suitable for this WG. Regards, Ignacio "Hesham Soliman (ERA)" wrote: > I really think you should announce this draft > on the ipv6 list and try to discuss it there. > This is clearly an ipv6 WG issue. Whether it is > motivated by mobility or not is a different > discussion. > > Hesham > > > -----Original Message----- > > From: Ignacio Soto Campos [mailto:isoto@it.uc3m.es] > > Sent: Monday, February 04, 2002 4:52 PM > > To: mobile-ip@sunroof.eng.sun.com > > Cc: marcelo@it.uc3m.es; alberto@it.uc3m.es > > Subject: [mobile-ip] draft on random interface identifiers available > > > > > > Hi all, > > > > We have submitted the draft "Random generation of interface > > identifiers" that is available from: > > > > http://www.ietf.org/internet-drafts/draft-soto-mobileip-rand > > om-iids-00.txt > > > > The abstract is included below. Comments are welcomed. > > > > Abstract > > > > This document evaluates the use of random numbers to generate the > > interface identifier part of an IPv6 address on mobile > > environments, > > where Duplicate Address Detection (DAD) mechanisms are expensive. > > We have estimated the probability of having an address > > duplication > > using this mechanism and we conclude that the IPv6 > > addresses created > > in this way could be used without previously doing DAD > > to test the > > uniqueness of the address in a link. > > > > > > Best regards, > > > > Ignacio > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 07:55:22 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28777 for ; Tue, 5 Feb 2002 07:55:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24451; Tue, 5 Feb 2002 04:54:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10165; Tue, 5 Feb 2002 04:54:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Crk2Q005718 for ; Tue, 5 Feb 2002 04:53:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15CrkvV005717 for mobile-ip-dist; Tue, 5 Feb 2002 04:53:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Crh2Q005710 for ; Tue, 5 Feb 2002 04:53:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03443 for ; Tue, 5 Feb 2002 04:53:57 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13648 for ; Tue, 5 Feb 2002 05:53:57 -0700 (MST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1JD624NP>; Tue, 5 Feb 2002 07:53:55 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> From: George Tsirtsis To: "Mobile-Ip (E-mail)" Subject: [mobile-ip] RFC2002bis interpretation question Date: Tue, 5 Feb 2002 07:53:55 -0500 X-MS-TNEF-Correlator: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AE44.2BBB9F50" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1AE44.2BBB9F50 Content-Type: text/plain; charset="iso-8859-1" Hi all I am trying to figure out how implementers have interpreted the Rbit part of rfc2002. I have asked a few people privately and I do not get identical feedback so some discussion here maybe helpful. I remind you that if the Rbit is set in a Foreign Agent Advertisement the MIP client is required to register through the Foreign Agent even if it has access to a collocated address... But what does that mean exactly? 1. Should the client register its Collocated care-of-address (and thus ignore the advertized CoA) but send the registration request to the FA and the FA forwards it to the HA? 2. Should the client register with the care-of-address advertised in the advertisement? If this is the case, can the mobile now also use a collocated care of address as source address for some traffic?? Is one of the above the "correct" behavior? How does your MIP client implementation behave and what does your Foreign Agent implementation expect? Are you aware of any interoperability tests in this area? Thanks for your help George P.S: I am interested about what the intention of the spec is but also about how current Mobile Node and Foreign Agent implementations behave and what they expect so let me know privately if you do not want to do that on the mailing list. ------_=_NextPart_000_01C1AE44.2BBB9F50 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjgMAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcCAAUABwA1ADcAAgBVAQEggAMADgAAANIHAgAF AAcANQA3AAIAVQEBCYABACEAAABFMkE0NjQwMDA2QTBDQjRBODkwMTg5REJFNzExRTc4MgAUBwEE gAEAIwAAAFJGQzIwMDJiaXMgaW50ZXJwcmV0YXRpb24gcXVlc3Rpb24AjQwBDYAEAAIAAAACAAIA AQOQBgBUCQAAMQAAAAMACVkBAAAAHgA4gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAA AAAAAAIBcQABAAAAFgAAAAHBrkP6+k3KzzMCK0uMnWwkzbZngbQAAAMA3j+vbwAAAwAvgAggBgAA AAAAwAAAAAAAAEYAAAAAUoUAACdqAQAeADCACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQA AAA5LjAACwAxgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADABOACCAGAAAAAADAAAAAAAAA RgAAAAABhQAAAAAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwA0gAggBgAAAAAA wAAAAAAAAEYAAAAADoUAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMANYAI IAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwA2gAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAA AAACAQkQAQAAAOkDAADlAwAATgYAAExaRnXRnDpbAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqA AqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3 tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBIfGkgB0AYAAqxCoQKgElBHRBtIHRyeQuAZ0EeUG8g ZmlnCHBl5iAIYAVAaG8H4AdwC1C+ZQeAAjAEkAQgE+B2H1BbC4AgcXAYIA6wZB5QaHEfUFJiaQVA CrEFQG8YZiByE8AB0DAyLkYgHhAgw2FzayGhYeMe8AfRcGVvIBEiUAUQpHZhDrBseR0QbiGwpR4Q ZB7gbm8FQGcUIH8f4AEAAjAN4AdAJFEJgGLxANBrIHMe4CfwB4AmAOkEAGN1BBBpAiAfoASQMx9Q AMB5Yh9QIeBscLhmdWwjUB1cGCBtC4D9IbB5CGAhwSVQH+AiwCHXXwQAJ+AmkgOgJEBGBbBlux8Q A6BBJoACMBDAZCDgDwAgBAAgMyHDTUlQIDxjbAiQLnEtARggcXXuaRghHsIYIGcEACBxIcGxA2B1 Z2ghwy3MZSDgvwOgLEEiMRPgBCAA0GMHkH8EIB7RJEAXkRewJyAhkmFsZGQYIAQQLjZgHVRC/R+B dywCJhAHkSvzB4ADkasOwADQdCWAPx1UMSNQ/lMfsCogIbQwBTFnIjAEIK8IUDVnJyAYIC0isC01 9fwgKCWyIdAosB/gLhAt0TchwzXwLsN6IaEIUEEpfCBiH4EUED1DH1AxZHJ/JVAo4jCiB5AvYR7g MnNB5yWjQcUCEHJ3CxE9oUF3/EhBOOUjQTmPMVgD8CHQ/0U0PD0+dRQQIbAtcT45LxR+PyNgLFIt AS0BRtQUECz/RwFI1ARgIiAk4SZAB+AHQP8n8SiwI8E1OjwiIqJHly0R/whhNKBOd0LhKBRAkQEg DeD+PzjlHbUEIAIgTjM+MwbguyDhIdIiBaEYIDigIj9g1mUgwSjgckoASB/BN4P/K7EFwS/ZIAZA tFQjI8Elwf83OFVTLcxWXQ7AJKA4oFE7twcQH1ArsmFDEU40biWQ/yETJMAEkAGgAxAiMCWQDrBf MaA9oUjSLQE8MWFRO1R5E+Bua1AEVVMp0h1URw0ksHImgB1UUC5TOv8jYR4xIRNBUSQSBuA3BiHS 7yESJvEo8VJ1c1rRLPI/cr9Mo2PkH7IooFOxLnFNTAT+TgRxJaNY71aJZkFXXSHRnyWQWrQn4iAg OAIga0xi/yUYLEErsiYVQxAvUh7gJhH/K/Mo8UuzC3AwEB6hMBAxoAU2hX1x0AAAAB4AcAABAAAA IwAAAFJGQzIwMDJiaXMgaW50ZXJwcmV0YXRpb24gcXVlc3Rpb24AAAsAAgABAAAAAwD9P+QEAAAe ADeACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgA5gAggBgAAAAAAwAAAAAAA AEYAAAAAOIUAAAEAAAABAAAAAAAAAEAAOQBQn7srRK7BAQMA8T8JBAAAHgAxQAEAAAAIAAAAR0VP UkdFVAADABpAAAAAAB4AMEABAAAACAAAAEdFT1JHRVQAAwAZQAAAAAADACYAAAAAAAMANgAAAAAA AwCAEP////8LAPIQAQAAAAIBRwABAAAAOAAAAGM9VVM7YT0gO3A9UmFkaW9Sb3V0ZXIsIEluYzts PUZUTUFJTC0wMjAyMDUxMjUzNTVaLTg4NDkAAgH5PwEAAABUAAAAAAAAANynQMjAQhAatLkIACsv 4YIBAAAAAAAAAC9PPVJBRElPUk9VVEVSLCBJTkMuL09VPVJSTUFJTC9DTj1SRUNJUElFTlRTL0NO PUdFT1JHRVQAHgD4PwEAAAAQAAAAR2VvcmdlIFRzaXJ0c2lzAB4AOEABAAAACAAAAEdFT1JHRVQA AgH7PwEAAABUAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVJBRElPUk9VVEVSLCBJ TkMuL09VPVJSTUFJTC9DTj1SRUNJUElFTlRTL0NOPUdFT1JHRVQAHgD6PwEAAAAQAAAAR2Vvcmdl IFRzaXJ0c2lzAB4AOUABAAAACAAAAEdFT1JHRVQAQAAHMPpk1CpErsEBQAAIMLAMaStErsEBHgA9 AAEAAAABAAAAAAAAAB4AHQ4BAAAAIwAAAFJGQzIwMDJiaXMgaW50ZXJwcmV0YXRpb24gcXVlc3Rp b24AAB4ANRABAAAAMAAAADw4QzkyRTIzQTNFODdGQjQ3OTk4ODI4NUY5RTIyQkU0NjVBQkE5MEBm dG1haWw+AAsAKQAAAAAACwAjAAAAAAADAAYQ+HSmtwMABxAOBAAAAwAQEAAAAAADABEQAQAAAB4A CBABAAAAZQAAAEhJQUxMSUFNVFJZSU5HVE9GSUdVUkVPVVRIT1dJTVBMRU1FTlRFUlNIQVZFSU5U RVJQUkVURURUSEVSQklUUEFSVE9GUkZDMjAwMklIQVZFQVNLRURBRkVXUEVPUExFUFJJVkEAAAAA AgF/AAEAAAAwAAAAPDhDOTJFMjNBM0U4N0ZCNDc5OTg4Mjg1RjlFMjJCRTQ2NUFCQTkwQGZ0bWFp bD4A2Tc= ------_=_NextPart_000_01C1AE44.2BBB9F50-- From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 08:21:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29167 for ; Tue, 5 Feb 2002 08:21:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16321; Tue, 5 Feb 2002 06:20:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08198; Tue, 5 Feb 2002 05:20:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15DJf2Q005873 for ; Tue, 5 Feb 2002 05:19:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15DJetu005872 for mobile-ip-dist; Tue, 5 Feb 2002 05:19:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15DJa2Q005865 for ; Tue, 5 Feb 2002 05:19:37 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15DJkM29089; Tue, 5 Feb 2002 14:19:46 +0100 (MET) Date: Tue, 5 Feb 2002 14:15:54 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202051145.g15BjPg68339@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > is more organization and feed back from other issues (if we'll give up HAO > the situation will be very different). Has anybody talked about giving up HAO? Are you referring to the possibility of replacing it with D/Z tunneling? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 08:40:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29409 for ; Tue, 5 Feb 2002 08:40:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25792; Tue, 5 Feb 2002 06:40:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12645; Tue, 5 Feb 2002 05:39:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Dcp2Q005971 for ; Tue, 5 Feb 2002 05:38:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15Dcont005970 for mobile-ip-dist; Tue, 5 Feb 2002 05:38:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Dcl2Q005963 for ; Tue, 5 Feb 2002 05:38:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07602 for ; Tue, 5 Feb 2002 05:39:02 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23763 for ; Tue, 5 Feb 2002 06:38:56 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15DcsZ27076 for ; Tue, 5 Feb 2002 15:38:55 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 5 Feb 2002 15:38:48 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 15:38:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 5 Feb 2002 15:38:47 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC99@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGtv71rdobUeC+hSgy6IpndLb0Q0gAiOkhg To: X-OriginalArrivalTime: 05 Feb 2002 13:38:48.0048 (UTC) FILETIME=[7072F700:01C1AE4A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g15Dcm2Q005964 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Jari, I've been following the emails for some time, but haven't felt that could add much to aid in the discussion. However, I'd at least like to register my feelings about the design team recommendations. > 1. The design team recommends a mandatory RR mechanism for > IPv6 nodes, but with limitations on how long bindings can stay > alive before they need to be refreshed. This recommendation is > based on the findings of the security analysis, which point to > some deficiences in the RR method below the "do no harm" > principle, to which the limitations provide a reasonable > answer. The RR mechanism should be placed in the MIPv6 > RFC. Given that RR may not be sufficient in all situations or > may need to be replaced later with something else, we > recommend that a secure mechanism for selecting different BU > authorization methods, using the "bit method" described in the > URL referenced from section 1, is included in this RFC as > well. Could you clarify this? By the 'bit method', are you essentially taking about Section 8 in: http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ? Does (1) boil down to Mandatory RR and Optional CGA? I ask because I still have some concerns about CGA. CGA may not protect well for IPv4 mapped address, etc. Additionally, I think Erik suggested that CGA may not be well known enough and that perhaps a CGA BOF be held, so we can sort out all of the details. I would tend to agree. Or, is (1) suggesting Mandatory RR + Optional Strong/Stronger method, to be determined later? > 2. The design team additionally recommends an optional CGA > mechanism to be standardized in a separate RFC in the MIPv6 > WG, using the above "bit method". This recommendation is based > on the findings of the security analysis, which point to > lesser signaling requirements and improved security properties > of CGA, as well as potential for solving additional, IPv6 > problems. Due to IPR and CPU consumption concerns it seems > problematic to make CGA a mandatory requirement, however. I would disagree on this point, CGA is still a relatively new & novel technique (at least to me) and I'd feel more comfortable with some more work [translate this to: draft-roe-mobileip-updateauth-01.txt is not close to being ready for last call]. Additionally, note my concerns above. > 3. Regarding issue (i), the design team recommends that the RR > method should not use a BSA since we already recommend both > HoA and CoA RR tests to be performed every time a binding is > refreshed or updated with RR. For CGA, the design team > recommends that a (simplified) BSA can be used to store the > Diffie-Hellman value generated as a part of the initial > binding, since with CGA, only the CoA test needs to be > performed on every binding refresh. Can live with this. > 4. Regarding issue (ii), the design team recommends both CoA > and HoA tests to be performed every time binding is refreshed > or updated with RR. We also recommend additionally that these > tests are made using separate requests in order to avoid > reflection problems with the authorization protocol itself (a > BU authorization request sent from the CoA should not be > answered to the HoA). This essentially leads to a five message > exchange that lasts 1.5 RTTs since because two pairs of the > messages can occur in parallel: > > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN Can live with this. > 5. In order to guarantee security of the above exchange, the > HA-MN tunnel should be encrypted for the RR messages (but not > necessarily for other messages on this tunnel). Note that > there aren't similar scalability problems with this as there > are with MN-CN security, since the home agents and mobile > nodes must have an existing relationship anyway. This could be > done e.g. using IPsec ESP with pre-shared keys. Can live with this. > 6. For CGA, the design team recommends that 1a/2a can be > omitted for all but the initial exchange and periodic tests > every few hours or perhaps once a day. Decision on this should be held off, note my concerns above. John From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 08:57:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29883 for ; Tue, 5 Feb 2002 08:57:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04337; Tue, 5 Feb 2002 06:57:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15894; Tue, 5 Feb 2002 05:56:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Dtn2Q006093 for ; Tue, 5 Feb 2002 05:55:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15DtniG006092 for mobile-ip-dist; Tue, 5 Feb 2002 05:55:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Dtj2Q006085 for ; Tue, 5 Feb 2002 05:55:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07463 for ; Tue, 5 Feb 2002 05:56:00 -0800 (PST) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA27314 for ; Tue, 5 Feb 2002 06:55:59 -0700 (MST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id g15DtukB002588 ; Tue, 5 Feb 2002 14:55:56 +0100 X-pt: isis.lip6.fr Received: from otos (otos.lip6.fr [132.227.61.47]) by tibre.lip6.fr (8.11.3nb1/8.11.3) with SMTP id g15Dtux18385; Tue, 5 Feb 2002 14:55:56 +0100 (MET) From: "Rolland Vida" To: Cc: , Subject: RE: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources Date: Tue, 5 Feb 2002 14:55:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <02e001c1ad83$1ea7f7d0$ac5a4f82@ustrasbg.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Dave Thaler presented a similar solution to this problem in the Magma WG at the last IETF meeting in SLC. See his slides at : http://www.ietf.org/proceedings/01dec/slides/magma-2.pdf The basic difference between the two approaches, as I see it, is that Dave proposes to send the BUs on the original tree, rooted at the HA, while you want to send them on the tree rooted at the old CoA. The problem is how to treat a rapidly moving source. I explain: 1. Imagine that the source moves to foreign domain 1, and acquires CoA1. 2. It sends a BU to the HA, which forwards it on the original tree (HA,G). Receivers will start to send their joins to CoA1. 3. BEFORE the tree gets totally reconstructed, the source moves again, in domain 2, and acquires CoA2. 4. You say that the source should send then a BU to the CoA1, which will forward the new address CoA2 down on the (CoA1,G) tree. But as the tree reconstruction was not finished, there will be some receivers who will not receive this BU. Should CoA2 send a BU to the HA too (as there are still receivers on the old tree)? Or should CoA1 send this BU to the HA, on behalf of CoA2? This would generate a possible security problem. If, on the other hand, you apply Dave's solution, the fact that receivers will stay on the original tree (HA,G) assures you that they will always receive the BUs. Rolland > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Christophe > Jelger > Envoyé : lundi 4 février 2002 14:52 > À : mobile-ip@sunroof.eng.sun.com > Objet : [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources > > > Hi, > > Two weeks ago we proposed a draft (draft-jelger-mssmsv6-00.txt) called > "Supporting Mobile SSM > Sources for IPv6 (MSSMSv6)" that proposes a solution to handle mobile > (MIPv6) PIM-SSM sources. > > We hope that some of you have had the time to read it and we would be > pleased to hear your comments and suggestions. We would like to start a > discussion of the subject and gather people's comments and ideas > in order to > be able to improve our current proposal. > > We look forward to receiving your comments. > > Christophe Jelger and Thomas Noel > > --------------------------------------------------------------- > Christophe Jelger - LSIIT jelger@dpt-info.u-strasbg.fr > Université Louis Pasteur > Strasbourg - France Tel: +33 (0)3 90 24 45 90 > > http://www-r2.u-strasbg.fr/~jelger > --------------------------------------------------------------- > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 09:08:26 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00124 for ; Tue, 5 Feb 2002 09:08:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18592; Tue, 5 Feb 2002 06:07:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17319; Tue, 5 Feb 2002 06:07:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15E6D2Q006175 for ; Tue, 5 Feb 2002 06:06:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15E6Dfu006174 for mobile-ip-dist; Tue, 5 Feb 2002 06:06:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15E692Q006167 for ; Tue, 5 Feb 2002 06:06:09 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17224 for ; Tue, 5 Feb 2002 06:06:24 -0800 (PST) Received: from muminmamman.lifix.fi ([195.238.204.197]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09333 for ; Tue, 5 Feb 2002 06:06:20 -0800 (PST) Received: from ban by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian)) id 16Y6Ee-0001Dm-00 for ; Tue, 05 Feb 2002 16:06:12 +0200 Date: Tue, 5 Feb 2002 16:06:12 +0200 From: Bjorn Andersson To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis interpretation question Message-ID: <20020205140612.GA3758@lifix.fi> Mail-Followup-To: Bjorn Andersson , mobile-ip@sunroof.eng.sun.com References: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> User-Agent: Mutt/1.3.25i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote: > I am trying to figure out how implementers have interpreted the Rbit part of > rfc2002. I have asked a few people privately and I do not get identical > feedback so some discussion here maybe helpful. > > I remind you that if the Rbit is set in a Foreign Agent Advertisement the > MIP client is required to register through the Foreign Agent even if it has > access to a collocated address... > But what does that mean exactly? > 1. Should the client register its Collocated care-of-address (and thus > ignore the advertized CoA) but send the registration request to the FA and > the FA forwards it to the HA? > 2. Should the client register with the care-of-address advertised in the > advertisement? If this is the case, can the mobile now also use a collocated > care of address as source address for some traffic?? I think it is pretty clear that it is alternative 1. The purpose, as said in draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites to enforce visiting policies (such as accounting) which require exchanges of authorization." What would the use of the collocated CoA be if the MN did not register it with anyone? It would be able to use the address as any node, but it would not be a care-of address. Bjorn -- Bjorn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 09:13:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00345 for ; Tue, 5 Feb 2002 09:13:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20680; Tue, 5 Feb 2002 06:12:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18097; Tue, 5 Feb 2002 06:12:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EBt2Q006218 for ; Tue, 5 Feb 2002 06:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15EBtuW006217 for mobile-ip-dist; Tue, 5 Feb 2002 06:11:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EBq2Q006210 for ; Tue, 5 Feb 2002 06:11:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02481 for ; Tue, 5 Feb 2002 06:12:07 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13363 for ; Tue, 5 Feb 2002 07:12:06 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g15EBoC15210; Tue, 5 Feb 2002 15:11:50 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g15EBor6006569; Tue, 5 Feb 2002 16:11:50 +0200 (EET) Message-ID: <3C5FE826.30ADDD0E@lmf.ericsson.se> Date: Tue, 05 Feb 2002 16:11:50 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC99@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi John, >However, >I'd at least like to register my feelings about the >design team recommendations. Excellent, that's what we need! > Could you clarify this? By the 'bit method', are you essentially > taking about Section 8 in: > http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ? Yes. First bullet item in section 8. > Does (1) boil down to Mandatory RR and Optional CGA? Not exactly. (1) suggests mandatory RR plus optional/later method X, for which we already should design the selection mechanism. But for (1), we don't need to decide that X=CGA. > CGA may not > protect well for IPv4 mapped address, etc. Additionally, > I think Erik suggested that CGA may not be well known enough > and that perhaps a CGA BOF be held, so we can sort out all > of the details. I would tend to agree. My personal opinion on this is that we should keep work specific to a problem in the WG handling that problem. I don't believe we have full understanding of what CGA could do for IPv6 control signaling, for instance, nor do we fully understand other possible solutions. Therefore, I'd rather recommend a IPv6 control signaling BOF than a CGA BOF. As to the use of RR or CGA in MIPv6, I believe that should be dealt in this WG. > I would disagree on this point, CGA is still a relatively > new & novel technique (at least to me) and I'd feel more > comfortable with some more work [translate this to: > draft-roe-mobileip-updateauth-01.txt is not close to being > ready for last call]. I'm in full agreement that we don't have last call -quality text. [However, that unfortunately applies in part also to RR techniques, see e.g. draft-roe-mobileip-updateauth-01.txt.] In conclusion I'm in agreement with you that some further work is needed. Maybe even more work for CGA than for RR. In any case, we are suggesting separate RFCs for base MIPv6 + RR and for CGA. Would this address your concern on the additional work needed? The work for RR would have to be done to the last details very soon, while CGA RFC would not necessarily need to be last called at the same time. > > 3. Regarding issue (i), the design team recommends that the RR > > Can live with this. Ok. Hmm... when you say "can live with this", can you give some indication of why its only "live with" and not "agree"? > > 4. Regarding issue (ii), the design team recommends both CoA > > Can live with this. Ok. > > 5. In order to guarantee security of the above exchange, the > > Can live with this. Ok. > > 6. For CGA, the design team recommends that 1a/2a can be > > Decision on this should be held off, note my concerns above. What we tried to do on this one is to evaluate the security differences between various cases, and basically the same results that in our opinion indicate the repetition of 1a/2a, also point to leaving out 1a/2a from CGA in the mentioned case. Do you have a specific comment on the analysis and do you disagree with the relevant part regarding HoA test? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 09:21:24 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00600 for ; Tue, 5 Feb 2002 09:21:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23484; Tue, 5 Feb 2002 06:20:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10545; Tue, 5 Feb 2002 06:20:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EJ12Q006259 for ; Tue, 5 Feb 2002 06:19:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15EJ1nc006258 for mobile-ip-dist; Tue, 5 Feb 2002 06:19:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EIw2Q006251 for ; Tue, 5 Feb 2002 06:18:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16270 for ; Tue, 5 Feb 2002 06:19:13 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23694 for ; Tue, 5 Feb 2002 07:19:10 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15EIqZ25011 for ; Tue, 5 Feb 2002 16:18:52 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Feb 2002 16:18:45 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Feb 2002 16:18:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 5 Feb 2002 16:18:45 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D959B@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGuTxTX4dkktQFIQI+z6qhMlJ7LeQAAIaLQ To: Cc: X-OriginalArrivalTime: 05 Feb 2002 14:18:45.0362 (UTC) FILETIME=[055C0D20:01C1AE50] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g15EIw2Q006252 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jari, > > Could you clarify this? By the 'bit method', are you essentially > > taking about Section 8 in: > > > http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ? > > Yes. First bullet item in section 8. > > > Does (1) boil down to Mandatory RR and Optional CGA? > > Not exactly. (1) suggests mandatory RR plus optional/later > method X, for which we already should design the selection > mechanism. But for (1), we don't need to decide that X=CGA. Then I fully support (1). > > CGA may not > > protect well for IPv4 mapped address, etc. Additionally, > > I think Erik suggested that CGA may not be well known enough > > and that perhaps a CGA BOF be held, so we can sort out all > > of the details. I would tend to agree. > > My personal opinion on this is that we should keep > work specific to a problem in the WG handling > that problem. I don't believe we have full understanding > of what CGA could do for IPv6 control signaling, > for instance, nor do we fully understand other possible > solutions. Therefore, I'd rather recommend a IPv6 > control signaling BOF than a CGA BOF. I think that would be quite valuable, actually. > I'm in full agreement that we don't have last call -quality > text. [However, that unfortunately applies in part also to > RR techniques, see e.g. draft-roe-mobileip-updateauth-01.txt.] Agreed, so perhaps we should get busy ;) > In conclusion I'm in agreement with you that some > further work is needed. Maybe even more work for CGA > than for RR. In any case, we are suggesting separate > RFCs for base MIPv6 + RR and for CGA. Would this address > your concern on the additional work needed? The work > for RR would have to be done to the last details very > soon, while CGA RFC would not necessarily need to be > last called at the same time. I think this is a good way to procede. > > > 3. Regarding issue (i), the design team recommends that the RR > > > > Can live with this. > > Ok. Hmm... when you say "can live with this", can you > give some indication of why its only "live with" and > not "agree"? My brain has used its quota for the day (my daughter woke up at 4 AM) I'll send more detailed follow-ups tomorrow. John From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 09:29:47 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00858 for ; Tue, 5 Feb 2002 09:29:46 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26573; Tue, 5 Feb 2002 06:28:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11669; Tue, 5 Feb 2002 06:28:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15ERf2Q006402 for ; Tue, 5 Feb 2002 06:27:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15ERfdc006401 for mobile-ip-dist; Tue, 5 Feb 2002 06:27:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15ERc2Q006394 for ; Tue, 5 Feb 2002 06:27:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18279 for ; Tue, 5 Feb 2002 06:27:53 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08258 for ; Tue, 5 Feb 2002 07:27:51 -0700 (MST) Received: from clarinet.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id PAA20265 for ; Tue, 5 Feb 2002 15:27:50 +0100 Message-ID: <3C5FEBF9.50409@clarinet.u-strasbg.fr> Date: Tue, 05 Feb 2002 15:28:09 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20020129 X-Accept-Language: en-us MIME-Version: 1.0 CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello and thanks very much for your very good comments. First I want to insist on the fact that Dave's solution is quite different in the sense that after the source handoff, there is no multicast delivery until receivers join the new tree. Also, we do not keep a tree rooted at the HA, I hope that the draft is clear enough about that. In our solution, multicast datagrams are still received on the old tree while receivers join the new one. Second, in Dave's solution there is a need to keep two trees, and the one rooted at the HA is almost never used (unless to send BU), and this means that extra router states are created for very little use. Moreover, I haven't seen anything about session and channel identifiers in Dave's proposal. Also, I want to stress the fact that even after the source handoff, only one branch per receiver is active, since when the new branch is active (packets received on the new tree) the old branch is prunned. Answering your point about a fast moving source (CoA1, CoA2, CoA3) : the source moves from CoA1 to CoA2, it sends an encapsulated BU on the tree rooted at CoA1, receivers start to join towards CoA2. The source moves to CoA3 before all receivers have joined CoA2. It sends a BU on the tree rooted at CoA1, and another BU on the tree rooted at CoA2. Receivers start to join CoA3. Data is sent on the three trees, so that receivers joining CoA3 still receive data on old trees. When the source is being notified by NSNIP (not covered in the draft) that there are no receivers on old trees (CoA1 and/or CoA2), it stops sending BU and data on the appropriate old tree. Also note that even if data is sent on the three trees, only one branch is active per receiver and therefore data is not sent three times more than with just one tree. Of course, the best point in Dave's solution is, as you say, that receivers will always get the BU but it is also the case in our proposal. Our solution is slightly more complicated but we believe that it is the price to minimise the disruption time after a source handoff. Please feel free to send me more comments, they are greatly appreciated. Christophe Rolland Vida wrote: >Hi, > >Dave Thaler presented a similar solution to this problem in the Magma WG at >the last IETF meeting in SLC. See his slides at : >http://www.ietf.org/proceedings/01dec/slides/magma-2.pdf >The basic difference between the two approaches, as I see it, is that Dave >proposes to send the BUs on the original tree, rooted at the HA, while you >want to send them on the tree rooted at the old CoA. >The problem is how to treat a rapidly moving source. I explain: > >1. Imagine that the source moves to foreign domain 1, and acquires CoA1. >2. It sends a BU to the HA, which forwards it on the original tree (HA,G). >Receivers will start to send their joins to CoA1. >3. BEFORE the tree gets totally reconstructed, the source moves again, in >domain 2, and acquires CoA2. >4. You say that the source should send then a BU to the CoA1, which will >forward the new address CoA2 down on the (CoA1,G) tree. But as the tree >reconstruction was not finished, there will be some receivers who will not >receive this BU. Should CoA2 send a BU to the HA too (as there are still >receivers on the old tree)? Or should CoA1 send this BU to the HA, on behalf >of CoA2? This would generate a possible security problem. > >If, on the other hand, you apply Dave's solution, the fact that receivers >will stay on the original tree (HA,G) assures you that they will always >receive the BUs. > >Rolland > >>-----Message d'origine----- >>De : owner-mobile-ip@sunroof.eng.sun.com >>[mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Christophe >>Jelger >>Envoyé : lundi 4 février 2002 14:52 >>À : mobile-ip@sunroof.eng.sun.com >>Objet : [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources >> >> >>Hi, >> >>Two weeks ago we proposed a draft (draft-jelger-mssmsv6-00.txt) called >>"Supporting Mobile SSM >>Sources for IPv6 (MSSMSv6)" that proposes a solution to handle mobile >>(MIPv6) PIM-SSM sources. >> >>We hope that some of you have had the time to read it and we would be >>pleased to hear your comments and suggestions. We would like to start a >>discussion of the subject and gather people's comments and ideas >>in order to >>be able to improve our current proposal. >> >>We look forward to receiving your comments. >> >>Christophe Jelger and Thomas Noel >> >>--------------------------------------------------------------- >>Christophe Jelger - LSIIT jelger@dpt-info.u-strasbg.fr >>Université Louis Pasteur >>Strasbourg - France Tel: +33 (0)3 90 24 45 90 >> >>http://www-r2.u-strasbg.fr/~jelger >>--------------------------------------------------------------- >> >> >> From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 09:46:45 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01416 for ; Tue, 5 Feb 2002 09:46:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03094; Tue, 5 Feb 2002 06:46:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14776; Tue, 5 Feb 2002 06:45:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EiV2Q008150 for ; Tue, 5 Feb 2002 06:44:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15EiVVE008149 for mobile-ip-dist; Tue, 5 Feb 2002 06:44:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EiR2Q008139 for ; Tue, 5 Feb 2002 06:44:27 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15EidM05506; Tue, 5 Feb 2002 15:44:39 +0100 (MET) Date: Tue, 5 Feb 2002 15:40:47 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] BU Authorization method: design team recommendation To: john.loughney@nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <0C1353ABB1DEB74DB067ADFF749C4EEF09BC99@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Could you clarify this? By the 'bit method', are you essentially > taking about Section 8 in: > http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt ? Does > (1) boil down to Mandatory RR and Optional CGA? I ask because I still have > some concerns about CGA. CGA may not protect well for IPv4 mapped address, > etc. Additionally, I think Erik suggested that CGA may not be well known > enough and that perhaps a CGA BOF be held, so we can sort out all > of the details. I would tend to agree. Or, is (1) suggesting > Mandatory RR + Optional Strong/Stronger method, to be determined > later? Agreeing with what Jari Arkko said but adding an example of how this could play out in detail. We get a bit reserved in the low-order 64 bits of an IPv6 address. A reasonable bit might be the 'group/individual' bit. This probably means that RFC 3041 and perhaps other specs need to be tweaked to make it clear that the 'reserved' bit must not be used when forming IPv6 addresses per those specifications. The MIPv6 specification says that if theabove reserved bit is set in a home address then route optimization using RR MUST NOT be used (and also says something about CGA being further studied to be possibly used to route optimize for home addresses that has this bit set). The above two should be done in parallel. After this folks can work out details about CGA for MIPv6 (as well as exploring CGA for other IP-level authorization issues). Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 10:23:41 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03442 for ; Tue, 5 Feb 2002 10:23:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18620; Tue, 5 Feb 2002 07:22:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29578; Tue, 5 Feb 2002 07:22:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15FLI2Q008545 for ; Tue, 5 Feb 2002 07:21:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15FLHZY008544 for mobile-ip-dist; Tue, 5 Feb 2002 07:21:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15FLE2Q008537 for ; Tue, 5 Feb 2002 07:21:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29261 for ; Tue, 5 Feb 2002 07:21:28 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01178 for ; Tue, 5 Feb 2002 07:21:28 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g15FLQC16010 for ; Tue, 5 Feb 2002 16:21:26 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Feb 05 16:21:22 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 16:20:58 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A98C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] BU Authorization method: design team recommendati on Date: Tue, 5 Feb 2002 16:20:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: John, First, I'd like to say that I fully agree with the DT's recommendation. Also wasn't RFC3041 being update recently ? I didn't think it went through last call, so we might be able to change it to accomodate this recommendation. > because I still have some concerns about CGA. CGA may not > protect well for IPv4 mapped address, etc. => This is not a good example IMHO. mapped addresses are only used (on the wire) for SIIT. In this case you wouldn't need to cryptographically generate the mapped address. The BU is sent to the SIIT router, so a global unicast Home address and global unicast CoA should be used. For more info check: http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-siit-dstm-01.txt I think we should standardise CGA based solutions for MIPv6 at the same time. Of course there is no need to hold off the spec for them but I don't see why they should be intentionally delayed either. The issues have been analysed for a long time now by many people. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 10:59:53 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05739 for ; Tue, 5 Feb 2002 10:59:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04994; Tue, 5 Feb 2002 07:58:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09602; Tue, 5 Feb 2002 07:56:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Ftt2Q008683 for ; Tue, 5 Feb 2002 07:55:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15FttEG008682 for mobile-ip-dist; Tue, 5 Feb 2002 07:55:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Ftq2Q008675 for ; Tue, 5 Feb 2002 07:55:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09439 for ; Tue, 5 Feb 2002 07:56:06 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05502 for ; Tue, 5 Feb 2002 08:56:06 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15Fu4U24464 for ; Tue, 5 Feb 2002 09:56:04 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 09:56:03 -0600 Message-ID: From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: RFC2002bis interpretation question Date: Tue, 5 Feb 2002 09:55:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE5D.994D0E00" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AE5D.994D0E00 Content-Type: text/plain; charset="iso-8859-1" Hi George, The way we have implemented that is that when the mobile node sees this bit in the advertisement it must use the foreign agent care-of address in its registration. The mobile node will use the home address as a source address, except in case of ingress filter will use the reverse tunnel with FA care-of address as a source address. Mohamed Khalil Nortel Networks -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: Tuesday, February 05, 2002 6:54 AM To: Mobile-Ip (E-mail) Subject: RFC2002bis interpretation question Hi all I am trying to figure out how implementers have interpreted the Rbit part of rfc2002. I have asked a few people privately and I do not get identical feedback so some discussion here maybe helpful. I remind you that if the Rbit is set in a Foreign Agent Advertisement the MIP client is required to register through the Foreign Agent even if it has access to a collocated address... But what does that mean exactly? 1. Should the client register its Collocated care-of-address (and thus ignore the advertized CoA) but send the registration request to the FA and the FA forwards it to the HA? 2. Should the client register with the care-of-address advertised in the advertisement? If this is the case, can the mobile now also use a collocated care of address as source address for some traffic?? Is one of the above the "correct" behavior? How does your MIP client implementation behave and what does your Foreign Agent implementation expect? Are you aware of any interoperability tests in this area? Thanks for your help George P.S: I am interested about what the intention of the spec is but also about how current Mobile Node and Foreign Agent implementations behave and what they expect so let me know privately if you do not want to do that on the mailing list. ------_=_NextPart_001_01C1AE5D.994D0E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: RFC2002bis interpretation question

Hi George,

The way we have implemented that is that when the = mobile node sees this bit in the advertisement it must use the foreign = agent care-of address in its registration. The mobile node will use the = home address as a source address, except in case of ingress filter will = use the reverse tunnel with FA care-of address as a source = address.

Mohamed Khalil
Nortel Networks

-----Original Message-----
From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com= ]
Sent: Tuesday, February 05, 2002 6:54 AM
To: Mobile-Ip (E-mail)
Subject: RFC2002bis interpretation question


Hi all

I am trying to figure out how implementers have = interpreted the Rbit part of rfc2002. I have asked a few people = privately and I do not get identical feedback so some discussion here = maybe helpful.

I remind you that if the Rbit is set in a Foreign = Agent Advertisement the MIP client is required to register through the = Foreign Agent even if it has access to a collocated = address...

But what does that mean exactly?
1. Should the client register its Collocated = care-of-address (and thus ignore the advertized CoA) but send the = registration request to the FA and the FA forwards it to the = HA?

2. Should the client register with the = care-of-address advertised in the advertisement? If this is the case, = can the mobile now also use a collocated care of address as source = address for some traffic??

Is one of the above the "correct" behavior? = How does your MIP client implementation behave and what does your = Foreign Agent implementation expect?

Are you aware of any interoperability tests in this = area?

Thanks for your help
George
P.S: I am interested about what the intention of the = spec is but also about how current Mobile Node and Foreign Agent = implementations behave and what they expect so let me know privately if = you do not want to do that on the mailing list.

------_=_NextPart_001_01C1AE5D.994D0E00-- From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 11:00:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05775 for ; Tue, 5 Feb 2002 11:00:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26356; Tue, 5 Feb 2002 08:59:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10319; Tue, 5 Feb 2002 07:59:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15FwX2Q008724 for ; Tue, 5 Feb 2002 07:58:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15FwXMi008723 for mobile-ip-dist; Tue, 5 Feb 2002 07:58:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15FwU2Q008716 for ; Tue, 5 Feb 2002 07:58:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10187 for ; Tue, 5 Feb 2002 07:58:44 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16715 for ; Tue, 5 Feb 2002 07:58:44 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g15Fwhg17761 for ; Tue, 5 Feb 2002 07:58:43 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV03868; Tue, 5 Feb 2002 07:58:12 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA24150; Tue, 5 Feb 2002 07:58:41 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.305.449864.148463@thomasm-u1.cisco.com> Date: Tue, 5 Feb 2002 07:58:41 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: <3C5EF68B.4060606@piuha.net> References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> <3C5EF68B.4060606@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit So, what I don't see here is any specific recommendation about HA/MN security. I guess that what the following is recommending is that it use strong authentication (and not CGA), but it's still not entirely what the specific proposal is. Mike Jari Arkko writes: > The MIPv6 security design team is trying to resolve the issues > around the method to use for authorizing binding updates. > > This note specifies the design team's motivation and current > position. In order to move forward in an efficient manner it > would be beneficial if responses could make it clear they are > - a clarification (by putting CLARIFICATION: in the Subject > field) > - an issue with a particular point (by ISSUE:) > - disagreement with the conclusion (by CONCLUSION:) > > We would also like folks to state for each of our six separate > recommendations whether they AGREE, CAN TOLERATE, or DISAGREE > with them. In case of DISAGREE, please explain why. > > 1. INTRODUCTION > =============== > > To date, various BU authorization methods have been proposed. > Of the proposals that don't assume a separate infrastructure > the properties they rely on are either RR and/or CGA > properties. An analysis of the security properties of those > general categories of CGA and RR can be found at: > > http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt > > 2. ALTERNATIVES > =============== > > The main alternatives for the actual address ownership authorization > problem are: > > (a) Return Routability, RR > (b) RR enhanced with Cryptographically Generated Addresses, CGA > > The security properties of these methods have been described > in the URL referenced from section 1. In addition, there are a > few additional properties we would like to bring to the > attention: > > - CGA requires additional computational power. It is not > clear though if this is big enough requirement to be an > issue, particularly when very constrained nodes could > refuse RO, and given that it has been demonstrated that > protocols can be designed where MNs and CNs can offload > their expensive computations to their HAs. > > - Several IPR claims have been made regarding CGA. > > In addition to the basic mechanism there are a few additional > issues that we need to decide: > > (i) Whether or not Binding Security Associations (BSAs) are > used > > (ii) What addresses need RR tests (HoA, CoA, or both), and > what is the correct time to perform the tests, always > at the time the binding is requested? > > 3. RECOMMENDATIONS > ================== > > 1. The design team recommends a mandatory RR mechanism for > IPv6 nodes, but with limitations on how long bindings can stay > alive before they need to be refreshed. This recommendation is > based on the findings of the security analysis, which point to > some deficiences in the RR method below the "do no harm" > principle, to which the limitations provide a reasonable > answer. The RR mechanism should be placed in the MIPv6 > RFC. Given that RR may not be sufficient in all situations or > may need to be replaced later with something else, we > recommend that a secure mechanism for selecting different BU > authorization methods, using the "bit method" described in the > URL referenced from section 1, is included in this RFC as > well. > > 2. The design team additionally recommends an optional CGA > mechanism to be standardized in a separate RFC in the MIPv6 > WG, using the above "bit method". This recommendation is based > on the findings of the security analysis, which point to > lesser signaling requirements and improved security properties > of CGA, as well as potential for solving additional, IPv6 > problems. Due to IPR and CPU consumption concerns it seems > problematic to make CGA a mandatory requirement, however. > > 3. Regarding issue (i), the design team recommends that the RR > method should not use a BSA since we already recommend both > HoA and CoA RR tests to be performed every time a binding is > refreshed or updated with RR. For CGA, the design team > recommends that a (simplified) BSA can be used to store the > Diffie-Hellman value generated as a part of the initial > binding, since with CGA, only the CoA test needs to be > performed on every binding refresh. > > 4. Regarding issue (ii), the design team recommends both CoA > and HoA tests to be performed every time binding is refreshed > or updated with RR. We also recommend additionally that these > tests are made using separate requests in order to avoid > reflection problems with the authorization protocol itself (a > BU authorization request sent from the CoA should not be > answered to the HoA). This essentially leads to a five message > exchange that lasts 1.5 RTTs since because two pairs of the > messages can occur in parallel: > > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN > > 5. In order to guarantee security of the above exchange, the > HA-MN tunnel should be encrypted for the RR messages (but not > necessarily for other messages on this tunnel). Note that > there aren't similar scalability problems with this as there > are with MN-CN security, since the home agents and mobile > nodes must have an existing relationship anyway. This could be > done e.g. using IPsec ESP with pre-shared keys. > > 6. For CGA, the design team recommends that 1a/2a can be > omitted for all but the initial exchange and periodic tests > every few hours or perhaps once a day. > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 11:30:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06877 for ; Tue, 5 Feb 2002 11:30:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19219; Tue, 5 Feb 2002 08:29:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18379; Tue, 5 Feb 2002 08:29:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15GRu2Q008809 for ; Tue, 5 Feb 2002 08:27:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15GRuI5008808 for mobile-ip-dist; Tue, 5 Feb 2002 08:27:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15GRq2Q008801 for ; Tue, 5 Feb 2002 08:27:52 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15GS5M16858 for ; Tue, 5 Feb 2002 17:28:05 +0100 (MET) Date: Tue, 5 Feb 2002 17:24:12 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15456.305.449864.148463@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > So, what I don't see here is any specific > recommendation about HA/MN security. I guess that > what the following is recommending is that it use > strong authentication (and not CGA), but it's > still not entirely what the specific proposal is. Where you looking for something more specific in recommendation #5? > > 5. In order to guarantee security of the above exchange, the > > HA-MN tunnel should be encrypted for the RR messages (but not > > necessarily for other messages on this tunnel). Note that > > there aren't similar scalability problems with this as there > > are with MN-CN security, since the home agents and mobile > > nodes must have an existing relationship anyway. This could be > > done e.g. using IPsec ESP with pre-shared keys. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 11:44:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07538 for ; Tue, 5 Feb 2002 11:44:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29882; Tue, 5 Feb 2002 09:43:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09699; Tue, 5 Feb 2002 08:43:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15GgW2Q008861 for ; Tue, 5 Feb 2002 08:42:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15GgW6c008860 for mobile-ip-dist; Tue, 5 Feb 2002 08:42:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15GgT2Q008853 for ; Tue, 5 Feb 2002 08:42:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22603 for ; Tue, 5 Feb 2002 08:42:44 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20981 for ; Tue, 5 Feb 2002 09:42:43 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g15Ggeb29313 for ; Tue, 5 Feb 2002 08:42:41 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV04659; Tue, 5 Feb 2002 08:42:09 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA24157; Tue, 5 Feb 2002 08:42:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15456.2942.530001.275674@thomasm-u1.cisco.com> Date: Tue, 5 Feb 2002 08:42:38 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: References: <15456.305.449864.148463@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > So, what I don't see here is any specific > > recommendation about HA/MN security. I guess that > > what the following is recommending is that it use > > strong authentication (and not CGA), but it's > > still not entirely what the specific proposal is. > > Where you looking for something more specific in recommendation #5? There wasn't consensus on the "eg" part below. To be useful, I think the DT needs to actually recommend something here. This is the single security thing that an operating network mipv6 MUST implement and use. Mind you, I'm happy with the example. Mike > > > > 5. In order to guarantee security of the above exchange, the > > > HA-MN tunnel should be encrypted for the RR messages (but not > > > necessarily for other messages on this tunnel). Note that > > > there aren't similar scalability problems with this as there > > > are with MN-CN security, since the home agents and mobile > > > nodes must have an existing relationship anyway. This could be > > > done e.g. using IPsec ESP with pre-shared keys. > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 12:07:27 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08684 for ; Tue, 5 Feb 2002 12:07:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05285; Tue, 5 Feb 2002 09:06:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16586; Tue, 5 Feb 2002 09:05:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15H412Q008947 for ; Tue, 5 Feb 2002 09:04:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15H40a2008946 for mobile-ip-dist; Tue, 5 Feb 2002 09:04:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15H3v2Q008939 for ; Tue, 5 Feb 2002 09:03:58 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10251 for ; Tue, 5 Feb 2002 09:04:12 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06454 for ; Tue, 5 Feb 2002 09:04:09 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA29337 for ; Tue, 5 Feb 2002 10:04:08 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA26759 for ; Tue, 5 Feb 2002 10:04:07 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 5 Feb 2002 11:04:06 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2622F2EC83 for ; Tue, 5 Feb 2002 17:59:28 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] ISSUE: BU Authorization method: design team recommendation References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> <3C5EF68B.4060606@piuha.net> From: Alexandru Petrescu Date: 05 Feb 2002 18:04:04 +0100 In-Reply-To: <3C5EF68B.4060606@piuha.net> Message-Id: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jari and thanks for the update! I generally agree with its orientation, I have remarks, below. Where I didn't put remarks it's that either I agree or I don't know. Jari Arkko writes: > 1. The design team recommends a mandatory RR mechanism for > IPv6 nodes, but with limitations on how long bindings can stay > alive before they need to be refreshed. This recommendation is > based on the findings of the security analysis, which point to > some deficiences in the RR method below the "do no harm" > principle, to which the limitations provide a reasonable > answer. AGREE. > The RR mechanism should be placed in the MIPv6 RFC. AGREE, but as stated looks to me like it would lengthen the draft and the standardization procedure. Maybe it should say "RR _hooks_ should be placed in the MIPv6 rfc", that's shorter than putting whole new RR message exchanges. > authorization methods, using the "bit method" described in the URL > referenced from section 1, is included in this RFC as well. CAN TOLERATE, but bit method should be presented to ipng and get some input from them. Erik already proposed u/g but I guess that is too much related to Ethernet? > 4. Regarding issue (ii), the design team recommends both CoA > and HoA tests to be performed every time binding is refreshed > or updated with RR. We also recommend additionally that these > tests are made using separate requests in order to avoid > reflection problems with the authorization protocol itself (a > BU authorization request sent from the CoA should not be > answered to the HoA). This essentially leads to a five message > exchange that lasts 1.5 RTTs since because two pairs of the > messages can occur in parallel: > > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN CAN TOLERATE, this sequence is obviously subject to discussion, as it's debatable whether there's need to go twice through the HA (even when RRing both HoA and CoA). But that can be discussed separately. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 13:05:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11249 for ; Tue, 5 Feb 2002 13:05:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14245; Tue, 5 Feb 2002 11:03:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04671; Tue, 5 Feb 2002 10:03:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15I1C2Q009534 for ; Tue, 5 Feb 2002 10:01:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15I1BJQ009533 for mobile-ip-dist; Tue, 5 Feb 2002 10:01:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15I172Q009522 for ; Tue, 5 Feb 2002 10:01:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08388 for ; Tue, 5 Feb 2002 10:01:22 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07319 for ; Tue, 5 Feb 2002 11:01:21 -0700 (MST) Received: from jariws1 ([62.248.152.85]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020205180120.MFPF24910.fep01-app.kolumbus.fi@jariws1>; Tue, 5 Feb 2002 20:01:20 +0200 Message-ID: <011e01c1ae6f$212a2ea0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Alexandru Petrescu" Cc: References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr><3C5EF68B.4060606@piuha.net> Subject: Re: [mobile-ip] ISSUE: BU Authorization method: design team recommendation Date: Tue, 5 Feb 2002 20:01:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for your input Alex! There's a few remarks below: > > The RR mechanism should be placed in the MIPv6 RFC. > > AGREE, but as stated looks to me like it would lengthen the draft and > the standardization procedure. Maybe it should say "RR _hooks_ should > be placed in the MIPv6 rfc", that's shorter than putting whole new RR > message exchanges. Fair enough. I think the important part is to realize that MIPv6 functionality and RR BU Authorization are inseparable logically, and one could not e.g. advance to RFC status before the other. > > authorization methods, using the "bit method" described in the URL > > referenced from section 1, is included in this RFC as well. > > CAN TOLERATE, but bit method should be presented to ipng and get some > input from them. I agree. > > 1a. MN(HoA)--->HA--->CN > > 1b. MN(CoA)--------->CN > > 2a. CN-------->HA--->MN(HoA) > > 2b. CN-------------->MN(CoA) > > 3. MN(CoA)--------->CN > > CAN TOLERATE, this sequence is obviously subject to discussion, as > it's debatable whether there's need to go twice through the HA (even > when RRing both HoA and CoA). But that can be discussed separately. Yes, the details we can propably take outside this thread. Just as a quick comment here I would note that the above procedure can be made stateless in the CN, and has no reflection issues (sending responses to somewhere else than they came from). That seems to imply an even number of messages through the HA, or? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 14:24:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15005 for ; Tue, 5 Feb 2002 14:24:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20186; Tue, 5 Feb 2002 12:23:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24187; Tue, 5 Feb 2002 09:23:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15HMV2Q009171 for ; Tue, 5 Feb 2002 09:22:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15HMV6x009170 for mobile-ip-dist; Tue, 5 Feb 2002 09:22:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15HMS2Q009163 for ; Tue, 5 Feb 2002 09:22:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20761 for ; Tue, 5 Feb 2002 09:22:43 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05145 for ; Tue, 5 Feb 2002 10:22:42 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA03949 for ; Tue, 5 Feb 2002 10:22:42 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA20375 for ; Tue, 5 Feb 2002 10:22:41 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Tue, 5 Feb 2002 11:22:36 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id EAC8D2EC83 for ; Tue, 5 Feb 2002 18:18:01 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0::/3 addresses and 64 bit interface ids (Was: BU Authorization method: design team recommendation) References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC99@esebe004.NOE.Nokia.com> From: Alexandru Petrescu Date: 05 Feb 2002 18:22:38 +0100 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC99@esebe004.NOE.Nokia.com> Message-Id: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: john.loughney@nokia.com writes: > CGA may not protect well for IPv4 mapped address, etc. Just a note on the "et caetera". It's a whole class of addresses that are reserved and that start with 3 bits zero of which I don't know much, just that they are not required to use 64 as the length of the interface ID. So putting 64 bits limits on these addresses is finding him/herself somehow "in the dark". Just a note. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 14:32:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15534 for ; Tue, 5 Feb 2002 14:32:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26146; Tue, 5 Feb 2002 12:32:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27097; Tue, 5 Feb 2002 11:31:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JUC2Q009945 for ; Tue, 5 Feb 2002 11:30:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15JUCZe009944 for mobile-ip-dist; Tue, 5 Feb 2002 11:30:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JU92Q009937 for ; Tue, 5 Feb 2002 11:30:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26632 for ; Tue, 5 Feb 2002 11:30:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16987 for ; Tue, 5 Feb 2002 12:30:22 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24757; Tue, 5 Feb 2002 11:30:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g15JUJL26521; Tue, 5 Feb 2002 11:30:19 -0800 X-mProtect:  Tue, 5 Feb 2002 11:30:19 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdd7Ox1i; Tue, 05 Feb 2002 11:30:17 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA66505; Tue, 5 Feb 2002 11:30:17 -0800 (PST) Message-ID: <3C6032C9.7055C025@iprg.nokia.com> Date: Tue, 05 Feb 2002 11:30:17 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, Charlie Perkins Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > Thanks for putting together this list - it is quite useful. > I might steal parts of it in order to complete the comparison > writeup that Phil is pushing to get completed. Please go ahead. > > - Processing Rules (as with RH T0), exactly, except for limiting > > forwarding out of the node. > > It might also make sense to restrict so that the address in the RH > is in fact a Home Address of the MN. Ok. > > - Other behavior: Path MTU: as in IPv6. Very simplified note: > > A "beautiful" implementation may provide a way such > > as described by Francis, a more common way is to keep packet > > less or equal than the minimum IPv6 MTU of 1280 octets or that > > fragmentation is possible otherwise (a less robust but still > > "acceptable" IPv6 stack?). > > I think you have to require that the applications limit the > messages they send so that the resulting packets (with a 40 byte IP > header and UDP header etc) does not exceed 1280-24=1256 bytes > in order to allow the IP layer to insert the RH. > Of course, for MN to MN communication both a HOA and RH are inserted > so the applications need to send even smaller packets. > Assuming the applications will do this might be problematic since > there might be applications which actually think that 1280 is the limit. > So I think reasonable PMTU handling is necessary - indepedent of > whether this is a new RH type, destination option, or Deering/Zill tunneling. > My only point was that for tunneling the problem is well understood and > written down in RFCs. It's basically a non-MIPv6 (IPv6-generic) issue and there are practical reasons why it is not advisable to make application too aware of this. First, fragmentation is bad, e.g., firewalls need to reassemble fragmented packets e.g. when smart proxying, and fragmentation causes complications for IPsec. Fragmentation seems work but it's complicated and inefficient, you do not want to make that but when necessary. E.g., if you have multiple links via which you can forward, you do not want even your bigger packets to fragment unnecessarily if you have a chance they can go over fatter pipes unfragmented (e.g. ATM). Hence, allowing packets beyond minimum MTU is something practical boxes want to do. But, when you do send over narrow paths, a stack can do automatic fragmenting after adding extensions transparent to application, unless fragmentation is forbidden. In that case, you can either make it visible to the app giving it a low value guessing the maximum the stack may add, or do it blindly and indicate packet too big to the application. This was of behavior in a sending box. Don't know if all this needs to be in a spec. Maybe, since otherwise there might be the misconception an IP stack cannot add anything besides IPv6 header to a packet by current IPv6 rules.. > > - Problems resulting from use for other purposes: None, since > > this is meant (currently) for the sole purpose of host mobility. > > When the condition in the future may be relaxed, e.g. for the > > above unknowns you mention, the general requirement may get > > broken, possibly in an uncontrolled way. > > There is a slight risk, deriving from the fact that this RH type 1 > isn't used for source routing but has a name which makes it sound like > source routing, that firewalls will just drop all source routed packets. > If something other than RH is used I think it will help communicate to > the firewall implementors that its a MIPv6 "header" hence firewalls should > only block it if they want to block MIPv6. This is more of a user interface question. Nowadays both implementors and sysadmins need to cope with so much more complicated filtering issues when application level stuff gets into firewalls. I personally have doubts of relevance in this argument. > > - Final properties since this uses a standardized header. > > - Interaction with IPsec (as RH T0) > > > > Derivable properties > > - Header ordering rules (e.g., as described by Pekka Savola) > > Did he describe what should happen when RH type NEW is followed > by RH type 0 in the packet? Yes, in a followup mail Tue Jan 29. > > 2. New DO > > > > This is an entity with endpoint semantics, that is, by reception > > this destination option is meant to be consumed by the final L3 > > communication endpoint in the host which directly delivers the > > upper layer part of the packet to the transport layer. > > > > Known properties: > > - Header Type: Destination Header > > - Problems resulting from use for other purposes: None, since > > this is meant (currently) for the sole purpose of host mobility. > > > > Derivable properties > > - Header structure: Possibly the option alone, possibly with > > other DOs. In the latter case may need more rules. > > I imagine we want the rule that when both HAO and ADA options are sent > they MUST be included in the same destination options header. > It makes no sense to allow two destination option headers in the packet > for the purpose of having one carry the HAO and the other carry the ADA > and I suspect it's easier for an implementation to be able to > extract both addresses in the same context in the code. Makes sense. > > Option format: Possibly like HAO. > > - Header ordering rules. Probably immediately after HAO. > > - Processing Rules: As with HAO but for IP hdr dst. addr. > > - Final properties since this uses a standardized header with > > MIPv6 draft version 15 DO HAO as a model for the DO. > > - Interaction with IPsec (as HAO) > > > > Unknown properties: > > - None (??). > > > > Requirement for change > > - Addition of a new Dst Opt processing. > > Format, enforcement of ordering rules, option-internal rules. > > Since no forwarding is assumed, no need for enforcing > > node-internal forwarding. > > Hmm - I think we actually need wording that says that the address in the ADA > must be at least an IP address assigned to the node (and perhaps we want to > constrain this to be a Home Address assigned to the node) to prevent > implementations that replacing the IP destination field with the ADA (so > that transport protocols can easily find the destination HoA) > in the case when the ADA is not assigned to the node. Wording is ok, here I just refered to the inherent properties of a DO, where no forwarding occurs naturally (though you _could_ with complicated rules bring routing semantics even to a DO). > > 4. Deering-Zill Tunneling > > > > [...] > > Requirement for change > > - Generation and processing of new header types > > I think there are also implementation considerations for implementations > which have IP-in-IP as a pseudo-device driver since with DZ-tunneling > the MN-to-MN traffic would presumably use full IP-in-IP tunnel headers. > In that case the pseudo-device driver for tunnel decapsulation would need > to have a way to check with the MIP part of the code whether decapsulation > of a particular packet should be allowed. That amounts to adding the don't forward to wrong addresses -precondition. When doing this, it immediately brings a question on the combinatorics of having MIPv6 and non-MIPv6 uses of DZ and how does a FW know if a node has non-MIPv6 uses which do not have the above restriction to enforce the reflection prevention and whether this encourages FWs eventually to block DZ. But to me these things seem underdefined hence my reservations to DZ. > > Summary: This proposal has a cleaner semantics and would have > > been a stronger candidate should its security implications for > > all its potential uses (IPsec etc) have been better understood > > today. > > > > 5. New Extension Header > > > > This is the most unknown in its semantics, all is open here. > > We can construct another routing header -like extension header > > or a new destination header -like entity, just to begin to > > enumerate the open choices. > > It seems like having a new extension header to just carry the > destination HoA doesn't make much sense - the source HoA would > still be a destination option. > If both source HoA and destination HoA (when both are needed) are > carried in such a new header the proposal seems to become either > (depending on processing rules and header order rules I think) like DZ > tunneling *or* like a new destination option for the destination HoA. Yes, so here is more pain with no gain. Unless you contemplate nuances on how IPsec recognizes these. I see not much point here since even for DO you can most likely have the desired behavior by specifying processing rules before submitting packet to the AH/ESP, e.g. whether to change the address to the IPhdr dst address or not (something RH does by default).. > > Known properties > > - None, except the general requirement > > > > Derivable properties > > - Format contains an address > > > > Unknown properties > > - Everything else > > > > Requirement for change > > - Unknown > > > > Summary: not a serious alternative given the level of missing > > detail that would be needed by now. > > > Based on this dimension of analysis, I would prefer routing > > header, the DO being the other realistic alternative but with > > significantly more towards unknowns while all the others having > > too many unknowns to be realistic to adopt today for the very > > specific use of host mobility that RH here has had (both tunneling > > methods, esp. Deering-Zill, have much potential for later use > > but with some questions of their applicability now). > > Your list didn't include any unknowns for the DO case, but above you > refer to such unknows (if I parse the sentence correctly). I used a more fine-grained scale where DO issues tended to be more open (more derivable than known) though not unknown or unsolvable. > I agree there are a lot more unknowns for the other alternatives. > > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 15:21:10 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17747 for ; Tue, 5 Feb 2002 15:21:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29800; Tue, 5 Feb 2002 12:20:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05898; Tue, 5 Feb 2002 11:54:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JrF2Q010243 for ; Tue, 5 Feb 2002 11:53:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15JrF2p010242 for mobile-ip-dist; Tue, 5 Feb 2002 11:53:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15JrB2Q010235 for ; Tue, 5 Feb 2002 11:53:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23483 for ; Tue, 5 Feb 2002 11:53:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13480 for ; Tue, 5 Feb 2002 12:53:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA26042; Tue, 5 Feb 2002 11:53:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g15JrOo24484; Tue, 5 Feb 2002 11:53:24 -0800 X-mProtect:  Tue, 5 Feb 2002 11:53:24 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdvHULQS; Tue, 05 Feb 2002 11:53:21 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA66527; Tue, 5 Feb 2002 11:53:21 -0800 (PST) Message-ID: <3C603831.801787D7@iprg.nokia.com> Date: Tue, 05 Feb 2002 11:53:21 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Erik Nordmark Subject: Re: [mobile-ip] RH and path MTU discovery References: <4DA6EA82906FD511BE2F00508BCF053802D4D557@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit As Francis has pointed out this is a IPv6 generic issue. This calls more for text to a rev of 2463 than to be put into the already large MIPv6. As of testing, it has not been in MIPv6 conformance test cases to my understanding for the above reasons, its place is rather in the PMTU discovery tests, not usually considered part of MIPv6 tests. There could be an implementation note on how to pass (or rather compensate for) transparently added stuff when passing the packet too big to the application layer. This is implementation internal behavior that shouldn't affect protocol behavior. A robust IPv6 stack should internally do this correctly. BR, -Jari > James, > > Don't kow if this was already answered, but > I'll answer it anyway. > Erik is making a very valid point about whether > the draft addresses how a CN receiving an > ICMP error (packet too large) for a packet > containing the routing header. The draft is > silent on this issue. > I've been to only one interop test when > I was working on our MIPv6 implementation > and we never had a test case for this. > Furthermore, I never saw a test case for > this in the current test suites. > > I think the draft must explain the behaviour > of the implementation when this happens. > > Hesham > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, February 01, 2002 6:10 PM > > To: Erik Nordmark > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] RH and path MTU discovery > > > > > > Erik, > > > > "This" is the problem you laid out in your original message, namely > > RH insertion resulting in the known path MTU becoming invalid. > > > > But I see that others have made the point that was I think bothering > > me, namely that having the path MTU become invalid is something > > that could potentially occur for other reasons, and so a > > sufficiently > > robust IPv6 stack would have to be prepared for it. > > > > jak > > > > ----- Original Message ----- > > From: "Erik Nordmark" > > To: > > Cc: > > Sent: Friday, February 01, 2002 3:19 AM > > Subject: Re: [mobile-ip] RH and path MTU discovery > > > > > > > > > > > How is this different from the case where a router fails on the > > > > original path and the route changes so that the original > > > > path MTU is no longer valid? > > > > > > I don't understand what "this" exactly refers to. > > > Are you referring to the MIPv6 specific part (the fact that in a > > layered > > > implementation the IP layer adds the RH) or something else? > > > > > > Erik > > > > > > > From: "Erik Nordmark" > > > > To: > > > > Sent: Thursday, January 31, 2002 1:31 AM > > > > Subject: [mobile-ip] RH and path MTU discovery > > > > > > > > > > > > > Question for the list: > > > > > > > > > > I was thinking about "RH works for MIPv6" - have implementors > > > > > tested the interaction of MIPv6/RH with Path MTU discovery > > > > > and figured out how to make sure it works? > > > > > > > > > > The mipv6 draft doesn't say anything about this but > > it seems like > > > > > there are similar path MTU issues RH insertion by the IP stack > > > > > as there are with IPsec tunnel insertion by the IP stack > > > > > thus this is something that we presumably need to make sure is > > > > > well documented. > > > > > > > > > > The issues are: > > > > > TCP when initiating a connection needs to know which > > MSS to use. > > > > > The MSS will be different if the IP layer, e.g. based > > on a binding > > > > cache > > > > > entry, inserts things in the packet. This is > > independent whether > > what > > > > is > > > > > added is a RH, a HOA, or an extra IP header. > > > > > It seems like some advise would be useful to point > > out this issue. > > > > > > > > > > If a TCP connection starts out without using RH and > > later route > > > > optimization > > > > > has been setup (causing RH to be added by the IP layer) then a > > packet > > > > > that previously fit in the MTU will no longer fit. Thus the IP > > layer > > > > needs > > > > > to be able to notify the TCP layer that it is adding > > N bytes to > > the > > > > packets > > > > > so that TCP can adjust its understanding of the effective path > > MTU. > > > > > > > > > > Finally, during the connection there could be changes in the > > routing > > > > path > > > > > to the MN causing routers to send back ICMP packet too big > > messages. > > > > > Such packets would need to be recognized by TCP as > > effecting the > > MTU > > > > > for the connection even though the destination field in the > > > > > "packet in error" in the ICMP packet is the CoA instead of the > > HoA. > > > > > An explicit example: > > > > > TCP generates a packet with > > > > > src = CN > > > > > dst = HoA > > > > > (and TCP already knows that IP will add 24 bytes due > > to the RH so > > > > > it doesn't send packets that are too big) > > > > > > > > > > This causes IP to send > > > > > src = CN > > > > > dst = CoA > > > > > routing header with seg-left = 1, address = HoA > > > > > > > > > > If the packet is too big somewhere along the path an ICMP > > > > > error will be sent back with > > > > > src = some router > > > > > dst = CN > > > > > ICMP packet too big > > > > > mtu = 1300 > > > > > packet in error > > > > > src = CN > > > > > dst = CoA > > > > > routing header with seg-left = 1, address = HoA > > > > > > > > > > The actual processing of this can be split between IP > > and TCP but > > > > > the effect must be the same as TCP having received a too big > > > > > packet reporting a smaller MTU and where the dst was > > the HoA i.e. > > > > > src = some router > > > > > dst = CN > > > > > ICMP packet too big > > > > > mtu = 1276 <=== NOTE > > > > > packet in error > > > > > src = CN > > > > > dst = HoA <=== NOTE > > > > > > > > > > One possible way to implement this is to have the IP > > layer convert > > > > > the ICMP error before passing it to TCP. Another possible way > > > > > would be to have TCP be able to adjust the reported MTU > > > > > and extract the destination address from the RH. > > > > > > > > > > > > > > > Do implementations already solve this? Has it been > > widely tested? > > > > > > > > > > RFC 2473 describes the solution to this in the more > > general case > > of > > > > > IP-in-IPv6 tunneling, thus that might be useful as background > > reading. > > > > > > > > > > Erik > > > > > > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 15:38:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18433 for ; Tue, 5 Feb 2002 15:38:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14329; Tue, 5 Feb 2002 13:38:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21857; Tue, 5 Feb 2002 12:38:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Kao2Q010707 for ; Tue, 5 Feb 2002 12:36:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15KaooK010706 for mobile-ip-dist; Tue, 5 Feb 2002 12:36:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Kaj2Q010699 for ; Tue, 5 Feb 2002 12:36:46 -0800 (PST) Received: from lillen (vpn-129-156-96-42.EMEA.Sun.COM [129.156.96.42]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15KapM12218; Tue, 5 Feb 2002 21:36:51 +0100 (MET) Date: Tue, 5 Feb 2002 21:32:57 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: "Jari T. Malinen" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Charlie Perkins In-Reply-To: "Your message with ID" <3C6032C9.7055C025@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > It's basically a non-MIPv6 (IPv6-generic) issue and there are > practical reasons why it is not advisable to make application > too aware of this. First, fragmentation is bad, e.g., firewalls > need to reassemble fragmented packets e.g. when smart proxying, > and fragmentation causes complications for IPsec. Fragmentation > seems work but it's complicated and inefficient, you do not want > to make that but when necessary. E.g., if you have multiple links > via which you can forward, you do not want even your bigger > packets to fragment unnecessarily if you have a chance they > can go over fatter pipes unfragmented (e.g. ATM). Hence, allowing > packets beyond minimum MTU is something practical boxes want to > do. But, when you do send over narrow paths, a stack can do > automatic fragmenting after adding extensions transparent to > application, unless fragmentation is forbidden. In that case, > you can either make it visible to the app giving it a low > value guessing the maximum the stack may add, or do it blindly > and indicate packet too big to the application. This was of > behavior in a sending box. Don't know if all this needs > to be in a spec. Maybe, since otherwise there might be the > misconception an IP stack cannot add anything besides IPv6 > header to a packet by current IPv6 rules.. It is probably useful to add a "heads-up" to the mipv6 specification to increase the likelyhood that new implementors are aware that they need to think about PMTU issues in this area. But I don't think the spec needs to go into more detail than that. > This is more of a user interface question. Nowadays both implementors > and sysadmins need to cope with so much more complicated filtering > issues when application level stuff gets into firewalls. I personally > have doubts of relevance in this argument. Predicting the behavior of products and configuration intended to prevent communication (also known as firewalls) is quite dicy. But we do have an existence proof in IPv4 with ICMP destination unreachable code "fragmentation needed and DF set". There are various gross hacks e.g. in PPPoE equipment to deal with the fact that a large number of firewalls fronting large web sites block these packets - presumably as part of either blocking all ICMP packets or as part of blocking ICMP error packets. I don't know of the root cause - but accidentally disabling path MTU discovery from working through lots of deployed firewalls seem to be the net effect. Sure, my concerns in this area could be viewed as FUD, but to me it sure seems safer to be able to say "this is a MIPv6 option which is safe" than "this type of the routing header shouldn't be treated as a routing header from the perspective of a firewall". The probability of a firewall implementor and/or adminstrator understanding the former seems higher. > That amounts to adding the don't forward to wrong addresses > -precondition. When doing this, it immediately brings a question > on the combinatorics of having MIPv6 and non-MIPv6 uses of DZ > and how does a FW know if a node has non-MIPv6 uses which > do not have the above restriction to enforce the reflection > prevention and whether this encourages FWs eventually to block DZ. > But to me these things seem underdefined hence my reservations to DZ. Agreed. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 15:54:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18986 for ; Tue, 5 Feb 2002 15:54:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13737; Tue, 5 Feb 2002 12:54:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22157; Tue, 5 Feb 2002 12:38:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Kac2Q010697 for ; Tue, 5 Feb 2002 12:36:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15KacFj010696 for mobile-ip-dist; Tue, 5 Feb 2002 12:36:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15KaZ2Q010686 for ; Tue, 5 Feb 2002 12:36:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09493 for ; Tue, 5 Feb 2002 12:36:50 -0800 (PST) From: stefano.faccin@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28780 for ; Tue, 5 Feb 2002 13:36:49 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g15KcZQ21221 for ; Tue, 5 Feb 2002 14:38:35 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 5 Feb 2002 14:36:48 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 5 Feb 2002 14:35:45 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] draft on random interface identifiers available Date: Tue, 5 Feb 2002 14:35:44 -0600 Message-ID: <82ECD4351A4A9547957C606034A3CB8DBF940B@daebe005.NOE.Nokia.com> Thread-Topic: [mobile-ip] draft on random interface identifiers available Thread-Index: AcGtlaoAyetQx8IdQJeQI5hxh//kagA7h5mA To: X-OriginalArrivalTime: 05 Feb 2002 20:35:45.0084 (UTC) FILETIME=[AFC3B7C0:01C1AE84] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g15KaZ2Q010687 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I have a question regarding section 3 on generation of random numbers. In the ID you state: "... it should be noted that because of the randomness of the identifier, it is not necessary to create the identifier in real time, i.e. when the node joins the network, but the identifier can be already created ... What is more, this random number can be pre-configured in the interface driver and the node can use always the same number without changing the probabilities calculations made above. This reduces the needed complexity in the nodes." My question is: how is this then any different from having a 62 bit interface identifier allocated to the mobile node? You just need to make sure that the identifier is unique. The identifier can be assigned to physical nodes such as mobile phones by e.g. the manufacturer, and for laptops either by the manufacturer or e.g. by the ISP when a subscription is activated. Thanks for any clarifications, Stefano -----Original Message----- From: ext Ignacio Soto Campos [mailto:isoto@it.uc3m.es] Sent: Monday, February 04, 2002 9:52 AM To: mobile-ip@sunroof.eng.sun.com Cc: marcelo@it.uc3m.es; alberto@it.uc3m.es Subject: [mobile-ip] draft on random interface identifiers available Hi all, We have submitted the draft "Random generation of interface identifiers" that is available from: http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt The abstract is included below. Comments are welcomed. Abstract This document evaluates the use of random numbers to generate the interface identifier part of an IPv6 address on mobile environments, where Duplicate Address Detection (DAD) mechanisms are expensive. We have estimated the probability of having an address duplication using this mechanism and we conclude that the IPv6 addresses created in this way could be used without previously doing DAD to test the uniqueness of the address in a link. Best regards, Ignacio From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 16:23:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19822 for ; Tue, 5 Feb 2002 16:23:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12688; Tue, 5 Feb 2002 14:23:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23880; Tue, 5 Feb 2002 13:23:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15LLW2Q010965 for ; Tue, 5 Feb 2002 13:21:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15LLWcS010964 for mobile-ip-dist; Tue, 5 Feb 2002 13:21:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15LLT2Q010957 for ; Tue, 5 Feb 2002 13:21:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20478; Tue, 5 Feb 2002 13:21:43 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16467; Tue, 5 Feb 2002 14:21:43 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15LLeU29867; Tue, 5 Feb 2002 15:21:40 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Feb 2002 15:21:40 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01DD359D@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, "Jari T. Malinen" Cc: Charlie Perkins , Erik Nordmark Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Tue, 5 Feb 2002 15:21:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE8B.174B69F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AE8B.174B69F0 Content-Type: text/plain; charset="iso-8859-1" Jari, Thanks for doing this analysis. Below are my comments on the zero-overhead variants. > 3. ZOD/MR.ZOD Tunneling > > This is an entity with unselected semantics, both endpoint and > routing semantics are described, but no restriction has been made. The reason there are unselected semantics is because there are options that I felt the Internet community as a whole may wish to consider. The main thing that the draft is trying get accross is that: "We don't need no stinking overhead. Here are some ways it works. Which way, with its accompanying restrictions do you think is appropriate? Pick one, but please get rid of the overhead - we don't need it now that we have to protect against the reflector spoofing. It is a waste." > That is, by reception, the Shim either switches endpoint > addresses from authorized state for internal delivery to > upper layer or in case of generalization, packet is > forwarded based on state. Non-generalized mode (NGM) fulfills > the generic requirement of not forwarding out of the node. I think it is quite evident that we would be doing NGM if one of the options is applied to MIPv6. The intent of the document was to convey the general concepts and requirements for signaling. The application of the concept to MIPv6 is pretty straight forward given the examples and it would use the NGM - E2E approach if you wish to call it that. > Alternatively this could have been treated as the applicable > component of the proposal but since this is a whole draft, > NGM cannot realistically be just extracted to MIPv6 draft? > We already have a MIPv6 draft. I don't want to come up with a new MIPv6 draft. The ZOD draft's purpose was to convey the idea in sufficient detail such that the rightful authors of the draft can understand the changes and the developers could understand what the reasoning behind the changes were. The mail list and the draft should be sufficient to work out choices. The generalized detail was given in order to let people understand what other uses MIP signaling could be used for to achieve functions other than just node mobility. I think it is very realistic to incorporate the change into MIPv6 in a timely fashion once a choice is made between the alternatives. > Known properties: > - Header Type: Nothing needed (except a flag both ways) > > Derivable properties > - Position of the flag, this was not specified for all cases, but > rough alternatives were given. > > Unknown properties: > - Problems resulting from use for other purposes: Not known, > since this proposal does not restrict itself to host mobility. As for the other purposes argument, the problems with the other overhead-based proposals is due to the fact that the overhead exists and a firewall might be inspecting and blocking these other purposes. With ZOD the firewalls have nothing to block; therefore, the issue with "other purposes" is mute. Again, the idea is to convey the options, bearer semantics and associated requirements for the signaling. The signaling of MIP can be used, as is, with the restrictions detailed in the draft related to host mobility. The same restrictions have pretty much already been agreed to on the mail list. This is hardly the same issue in terms of unknowns as exists with the RH or other overhead-based solutions. With this "other purposes" reasoning I guess we shouldn't use overhead based tunneling mechanisms at all because all of the uses of it are unknown as well. I guess we should throw the routing header into this bucket, as well, with this reasoning. I don't just mean throw them out for MIP only, either. I think this was Charlie's earlier point on the RH. If you want to limit MIPv6 signaling to only be used for mobility - go for it. I don't think this would stop people from using it for other purposes, though. The choice of overhead vs no overhead is orthogonal to this argument. With these points in mind, I see the ability of ZOD and MIPv6 signaling to be used for other functions than just mobility as a positive - not an issue or problem. > The choice for delivery vs. forwarding was not made nor strict > restriction to use with host mobility in delivery, nor the use > of RO signaling as establishing the state were mandated. This > many open options leave room for too many unknowns given the > level of security required for the choice at hand. The example of ZOD applied to MIPv6 was given that did detail delivery and forwarding. The draft also gives restrictions and requirements on the signaling related to security in a way that is irrespective of the signaling employed. It just so happens that MIPv6 RO signaling meets these restrictions and requirements. It would be the job of the MIPv6 draft to do the mandating with its specific signaling. What unknowns are you refering to - one will do? > - Interaction/security with other protocols (given the amount of > security and other analysis in MIPv6, any generic new method > deserves this note) The draft shows that the security requirements and state necessary to implement route optimized MIPv6, without the reflector spoofing hole, are the same as that which would be needed to remove the extra overhead. In short, if the security for MIPv6 with overhead based tunneling has no issues; neither does ZOD/MR. ZOD. If you could give me an example of where it might be different I can respond to the concerns? > - All possible signaling methods for setting up the > authorized state (a downside of the proposal is its reliance > on state, which gets the critique all non-routing-state-based > forwarding usually does, esp. in its generalized format) I'd really like to see someone attempt an efficient implementation of secure route optimized mobile IPv6 (i.e. without the reflector spoofing hole) that doesn't keep the same state. If you see a problem with this state end to end, then you must see the same problem with all of the overhead-based methods that also require this state. This was the entire message of the draft: "Because you have to keep this state to do RO in a secure manner, you don't need the overhead". I guess MIPv6 with any of the overhead based methods has the same downside to it. > - Final stabilized properties, since there may be changes due to > problems found with other uses. Again, the "other uses/other purposes" duplicate argument doesn't hold water because as there is nothing in the packet for the firewalls to block or worry about. The issue with "others" is not there. ZOD is transparent to firewalls. > - Interaction with IPsec > I did, indeed, detail the interactions and processing rules in relation to IPSEC. This detail includes the of order of operations of each component. If you see an specific issue, please detail it? > Requirement for change > - Entry and processing of the bits (Shims) > - Possible robustness features (several, some due to statefulness) > Again RO'd MIPv6 will have to be just as stateful unless you want to keep the reflector hole. If we keep the hole, it will eventually end up being blocked by firewalls anyway. I.e. a few days after a worm starts to take advantage of it. Actually it may be blocked from day one if the hole exists. > Summary: if it had restricted itself to host IPv6 mobility only, > it would have been a stronger candidate. Then, I do not give > the proper credit to this otherwise well thought draft, it > should be a contender with the Deering-Zill tunneling, though > the requirement for state in forwarding is a liability. > Again all of the alternatives (D/Z, RH, HAO, ZOT, MR. ZOT) will all have to keep the same state in order to protect against the reflector spoofing. The fact that the draft introduced other modes of operation should not have a bearing on MIPv6's application of a specific mode. This thinking is a logical fallacy. The overhead of the extra address on the paths between the MN and CN is a waste for MIPv6. Thanks again for capturing your thoughts on each of the proposals. Glenn ------_=_NextPart_001_01C1AE8B.174B69F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team = recommendation

Jari,

Thanks for doing this analysis.

Below are my comments on the zero-overhead = variants.


> 3. ZOD/MR.ZOD Tunneling
>
> This is an entity with unselected semantics, = both endpoint and
> routing semantics are described, but no = restriction has been made.

The reason there are unselected semantics is because = there are options that I felt the Internet community as a whole may = wish to consider. The main thing that the draft is trying get accross = is that:

"We don't need no stinking overhead. Here are = some ways it works. Which way, with its accompanying restrictions do = you think is appropriate? Pick one, but please get rid of the overhead = - we don't need it now that we have to protect against the reflector = spoofing. It is a waste."

> That is, by reception, the Shim either switches = endpoint
> addresses from authorized state for internal = delivery to
> upper layer or in case of generalization, = packet is
> forwarded based on state. Non-generalized mode = (NGM) fulfills
> the generic requirement of not forwarding out = of the node.

I think it is quite evident that we would be doing = NGM if one of the options is applied to MIPv6. The intent of the = document was to convey the general concepts and requirements for = signaling. The application of the concept to MIPv6 is pretty straight = forward given the examples and it would use the NGM - E2E approach if = you wish to call it that.

> Alternatively this could have been treated as = the applicable
> component of the proposal but since this is a = whole draft,
> NGM cannot realistically be just extracted to = MIPv6 draft?
>

We already have a MIPv6 draft. I don't want to come = up with a new MIPv6 draft. The ZOD draft's purpose was to convey the = idea in sufficient detail such that the rightful authors of the draft = can understand the changes and the developers could understand what the = reasoning behind the changes were. The mail list and the draft should = be sufficient to work out choices. The generalized detail was given in = order to let people understand what other uses MIP signaling could be = used for to achieve functions other than just node mobility. I think it = is very realistic to incorporate the change into MIPv6 in a timely = fashion once a choice is made between the alternatives.

> Known properties:
> - Header Type: Nothing needed (except a flag = both ways)
>
> Derivable properties
> - Position of the flag, this was not specified = for all cases, but
>   rough alternatives were = given.
>
> Unknown properties:
> - Problems resulting from use for other = purposes: Not known,
>   since this proposal does not = restrict itself to host mobility.

As for the other purposes argument, the problems with = the other overhead-based proposals is due to the fact that the overhead = exists and a firewall might be inspecting and blocking these other = purposes. With ZOD the firewalls have nothing to block; therefore, the = issue with "other purposes" is mute.

Again, the idea is to convey the options, bearer = semantics and associated requirements for the signaling. The signaling = of MIP can be used, as is, with the restrictions detailed in the draft = related to host mobility.  The same restrictions  have pretty = much already been agreed to on the mail list.  This is hardly the = same issue in terms of unknowns as exists with the RH or other = overhead-based solutions. With this "other purposes" = reasoning I guess we shouldn't use overhead based tunneling mechanisms = at all because all of the uses of it are unknown as well. I guess we = should throw the routing header into this bucket, as well, with this = reasoning. I don't just mean throw them out for MIP only, either. I = think this was Charlie's earlier point on the RH.

If you want to limit MIPv6 signaling to only be used = for mobility - go for it. I don't think this would stop people from = using it for other purposes, though. The choice of overhead vs no = overhead is orthogonal to this argument.

With these points in mind, I see the ability of ZOD = and MIPv6 signaling to be used for other functions than just mobility = as a positive - not an issue or problem.

 

>   The choice for delivery vs. = forwarding was not made nor strict
>   restriction to use with host = mobility in delivery, nor the use
>   of RO signaling as establishing the = state were mandated. This
>   many open options leave room for = too many unknowns given the
>   level of security required for the = choice at hand.

The example of ZOD applied to MIPv6 was given that = did detail delivery and forwarding. The draft also gives restrictions = and requirements on the signaling related to security in a way that is = irrespective of the signaling employed. It just so happens that MIPv6 = RO signaling meets these restrictions and requirements. It would be the = job of the MIPv6 draft to do the mandating with its specific signaling. = What unknowns are you refering to - one will do?


> - Interaction/security with other protocols = (given the amount of
>   security and other analysis in = MIPv6, any generic new method
>   deserves this note)

The draft shows that the security requirements and = state necessary to implement route optimized MIPv6, without the = reflector spoofing hole, are the same as that which would be needed to = remove the extra overhead. In short, if the security for MIPv6 with = overhead based tunneling has no issues; neither does ZOD/MR. ZOD. If = you could give me an example of where it might be different I can = respond to the concerns?

> - All possible signaling methods for setting up = the
>   authorized state (a downside of the = proposal is its reliance
>   on state, which gets the critique = all non-routing-state-based
>   forwarding usually does, esp. in = its generalized format)

I'd really like to see someone attempt an efficient = implementation of secure route optimized mobile IPv6 (i.e. without the = reflector spoofing hole) that doesn't keep the same state. If you see a = problem with this state end to end, then you must see the same problem = with all of the overhead-based methods that also require this state. = This was the entire message of the draft: "Because you have to = keep this state to do RO in a secure manner, you don't need the = overhead". I guess MIPv6 with any of the overhead based methods = has the same downside to it.

> - Final stabilized properties, since there may = be changes due to
>   problems found with other = uses.

Again, the "other uses/other purposes" = duplicate argument doesn't hold water because as there is nothing in = the packet for the firewalls to block or worry about. The issue with = "others" is not there. ZOD is transparent to = firewalls.

> - Interaction with IPsec
>

I did, indeed, detail the interactions and processing = rules in relation to IPSEC. This detail includes the of order of = operations of each component. If you see an specific issue, please = detail it?

> Requirement for change
> - Entry and processing of the bits = (Shims)
> - Possible robustness features (several, some = due to statefulness)
>

Again RO'd MIPv6 will have to be just as stateful = unless you want to keep the reflector hole. If we keep the hole, it = will eventually end up being blocked by firewalls anyway. I.e. a few = days after a worm starts to take advantage of it. Actually it may be = blocked from day one if the hole exists.

 
> Summary: if it had restricted itself to host = IPv6 mobility only,
>   it would have been a stronger = candidate. Then, I do not give
>   the proper credit to this otherwise = well thought draft, it
>   should be a contender with the = Deering-Zill tunneling, though
>   the requirement for state in = forwarding is a liability.
>

Again all of the alternatives (D/Z, RH, HAO, ZOT, MR. = ZOT) will all have to keep the same state in order to protect against = the reflector spoofing. The fact that the draft introduced other modes = of operation should not have a bearing on MIPv6's application of a = specific mode. This thinking is a logical fallacy.

The overhead of the extra address on the paths = between the MN and CN is a waste for MIPv6.

Thanks again for capturing your thoughts on each of = the proposals.

Glenn

------_=_NextPart_001_01C1AE8B.174B69F0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 16:38:31 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20392 for ; Tue, 5 Feb 2002 16:38:31 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA29611; Tue, 5 Feb 2002 13:38:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27089; Tue, 5 Feb 2002 13:37:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15LaP2Q011073 for ; Tue, 5 Feb 2002 13:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15LaPEX011072 for mobile-ip-dist; Tue, 5 Feb 2002 13:36:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15LaL2Q011065 for ; Tue, 5 Feb 2002 13:36:22 -0800 (PST) Received: from lillen (vpn-129-156-96-42.EMEA.Sun.COM [129.156.96.42]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g15LaVM15878; Tue, 5 Feb 2002 22:36:31 +0100 (MET) Date: Tue, 5 Feb 2002 22:32:36 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] ISSUE: BU Authorization method: design team recommendation To: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > authorization methods, using the "bit method" described in the URL > > referenced from section 1, is included in this RFC as well. > > CAN TOLERATE, but bit method should be presented to ipng and get some > input from them. Erik already proposed u/g but I guess that is too > much related to Ethernet? RFC 2373 relies on the IEEE EUI-64 addressing format (which is a superset of IEEE 802 aka Ethernet addresses) so this wouldn't add any new relationships. I'm assuming the co-chairs and AD for the WG would figure out how to do the coordination of this issue. > > 1a. MN(HoA)--->HA--->CN > > 1b. MN(CoA)--------->CN > > 2a. CN-------->HA--->MN(HoA) > > 2b. CN-------------->MN(CoA) > > 3. MN(CoA)--------->CN > > CAN TOLERATE, this sequence is obviously subject to discussion, as > it's debatable whether there's need to go twice through the HA (even > when RRing both HoA and CoA). But that can be discussed separately. There is some text in the residual_threats.txt document which explains the motivation for this. Basically if a packet has the HoA as a source address the destination address of the reply to that address should be the HoA, to avoid creating reflectors that can't be prevented using ingress filtering. Thus the 1a request needs to be tunneled from the MN to the HA to avoid ingress filtering dropping it (its source is the HoA) and the 2a reply will go through the HA since it is addressed to the HoA. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 18:29:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23564 for ; Tue, 5 Feb 2002 18:29:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02917; Tue, 5 Feb 2002 15:28:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22647; Tue, 5 Feb 2002 15:27:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15NQE2Q011425 for ; Tue, 5 Feb 2002 15:26:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15NQEKt011424 for mobile-ip-dist; Tue, 5 Feb 2002 15:26:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15NQC2Q011417 for ; Tue, 5 Feb 2002 15:26:12 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14996 for ; Tue, 5 Feb 2002 18:26:26 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA16990 for mobile-ip@sunroof.eng.sun.com; Tue, 5 Feb 2002 18:27:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g152VX2Q003806; Mon, 4 Feb 2002 18:31:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21515; Mon, 4 Feb 2002 18:31:49 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17741; Mon, 4 Feb 2002 19:31:49 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id TAA04322; Mon, 4 Feb 2002 19:31:48 -0700 (MST)] Received: [from il06exw10.corp.mot.com (il06exw10.corp.mot.com [199.5.78.81]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA03575; Mon, 4 Feb 2002 19:31:48 -0700 (MST)] Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 4 Feb 2002 20:31:48 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'Pekka Nikander'" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, monet@crm.mot.com Cc: "Charles E. Perkins" Subject: [mobile-ip] RE: [Monet] The semantics of the Routing Header? Date: Mon, 4 Feb 2002 20:31:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Pekka, In IPv6, the mobile node builds a Care-of-Address from Router Advertisements received on the visited network and uses it as a temporary, topologically correct, IPv6 address. When he moves, he gets another Care-of-Address - he always keep the Home Address, and all other nodes that communicate with him use the Home Address to identify him, except when they are capable of Route Optimization. It is in Route Optimization that the communicating node uses the Routing Header to build what looks identical to a Source Route option, with the Care-of-Address being the first entry in the source route, and the Home Address being the second - and final - entry of the source route. It is a special case of Source Route, since both addresses in the list are "being used" by the same node. Perhaps it should have been a separate option for all the confusion that it is apparently generating, but when it was conceived it must have seemed like a good thing - a way to conserve IPv6 option code points perhaps? Cyndi >The reason why I am asking this is the scenario, which >Charlie Perkins has offered, where a packet is source >routed through a Mobile Node that is away from home. >According to his argumentation, in such case the >routing header should have a route looking like > > .... - Care-of-Address - Home Address - .... > >where the Care-of-Address is the current location of >the mobile node, and the Home Address is more like >the end-point identifier of the mobile node. I am >having hard time in clearly crasping the intended >semantic meaning of this construction. > >--Pekka Nikander _______________________________________________ Monet mailing list Monet@thorgal.crm.mot.com From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 18:35:10 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23793 for ; Tue, 5 Feb 2002 18:35:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27927; Tue, 5 Feb 2002 16:34:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24612; Tue, 5 Feb 2002 15:34:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15NXf2Q011685 for ; Tue, 5 Feb 2002 15:33:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15NXfiW011684 for mobile-ip-dist; Tue, 5 Feb 2002 15:33:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15NXd2Q011677 for ; Tue, 5 Feb 2002 15:33:40 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA20104 for ; Tue, 5 Feb 2002 18:33:53 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA17025 for mobile-ip@sunroof.eng.sun.com; Tue, 5 Feb 2002 18:34:39 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15EtN2Q008356 for ; Tue, 5 Feb 2002 06:55:24 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24096 for ; Tue, 5 Feb 2002 06:55:39 -0800 (PST) From: dworley@globespanvirata.com Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01707 for ; Tue, 5 Feb 2002 06:55:38 -0800 (PST) Received: from agranat.com (alice.agranat.com [10.21.0.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id JAA22180; Tue, 5 Feb 2002 09:54:47 -0500 Received: from dhcp75.ma.virata.com (dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.11.6/8.11.6) with ESMTP id g15EskQ30825; Tue, 5 Feb 2002 09:54:46 -0500 Received: (from worley@localhost) by dhcp75.ma.virata.com (8.11.0/8.11.0) id g15Eskg12995; Tue, 5 Feb 2002 09:54:46 -0500 Date: Tue, 5 Feb 2002 09:54:46 -0500 Message-Id: <200202051454.g15Eskg12995@dhcp75.ma.virata.com> X-Authentication-Warning: dhcp75.ma.virata.com: worley set sender to dworley@globespanvirata.com using -f To: mobile-ip@sunroof.eng.sun.com, dhcwg@ietf.org In-reply-to: <200202050532.GAA08761@dumburken.it.kth.se> (message from Gerald Maguire on Tue, 5 Feb 2002 06:32:14 +0100 (MET)) Subject: Re: [dhcwg] Re: [mobile-ip] IPv4 Address Conflict Detection References: <200202041944.g14JiY026372@scv2.apple.com> <200202050532.GAA08761@dumburken.it.kth.se> X-Scanned-By: MIMEDefang 2.2 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: Gerald Maguire I think the idea of probing and waiting _before_ using an address is completely wrong. Since it involves waiting for something _not_ to happen. The better approach is to detect the conflict -- if there is one. IMHO, detecting address conflicts is not a matter of a single strategy. For instance, if there aren't resource limitations, DHCP clients should check for address conflicts, but DHCP servers should also. Hosts should also continuously monitor their interfaces for evidence of duplicate addresses (e.g., ARPs from other hosts holding the same address). Especially because this is the first attempt to formalize address conflict detection, we should be documenting all methods that are known to be useful, preferably with notes on their costs and benefits, and circumstances in which they are known to be particularly useful. Dale From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 18:40:04 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24061 for ; Tue, 5 Feb 2002 18:40:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06539; Tue, 5 Feb 2002 15:39:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25751; Tue, 5 Feb 2002 15:39:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Nbu2Q011955 for ; Tue, 5 Feb 2002 15:37:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g15Nbu4c011954 for mobile-ip-dist; Tue, 5 Feb 2002 15:37:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g15Nbr2Q011947 for ; Tue, 5 Feb 2002 15:37:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25549 for ; Tue, 5 Feb 2002 15:38:07 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23277 for ; Tue, 5 Feb 2002 16:38:07 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA11090; Tue, 5 Feb 2002 15:38:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g15Nc5N14551; Tue, 5 Feb 2002 15:38:05 -0800 X-mProtect:  Tue, 5 Feb 2002 15:38:05 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdaEkfDm; Tue, 05 Feb 2002 15:38:03 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id PAA66729; Tue, 5 Feb 2002 15:38:04 -0800 (PST) Message-ID: <3C606CDB.37BFD17D@iprg.nokia.com> Date: Tue, 05 Feb 2002 15:38:03 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, Charlie Perkins Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > Predicting the behavior of products and configuration intended to > prevent communication (also known as firewalls) is quite dicy. Agreed. Being in focus in MIPv6 discussions and considered relevant we can't help but trying to do that. > But we do have an existence proof in IPv4 with ICMP destination unreachable > code "fragmentation needed and DF set". > There are various gross hacks e.g. in PPPoE equipment to deal with > the fact that a large number of firewalls fronting large web sites > block these packets - presumably as part of either blocking all ICMP > packets or as part of blocking ICMP error packets. > I don't know of the root cause - but accidentally disabling path MTU discovery > from working through lots of deployed firewalls seem to be the net effect. Yes, though I suspect it has more to do with the fact ICMP messages that affect someone's state are unsecured rather than just being similar. > Sure, my concerns in this area could be viewed as FUD, but to me it > sure seems safer to be able to say "this is a MIPv6 option which is safe" > than "this type of the routing header shouldn't be treated as a routing > header from the perspective of a firewall". The probability of a firewall > implementor and/or adminstrator understanding the former seems higher. True though one could also say "block node-external source routing, pass node-internal source routing", which is close to what one needs to understand when deciding to block source routing. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 5 19:33:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25703 for ; Tue, 5 Feb 2002 19:33:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25984; Tue, 5 Feb 2002 17:33:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03531; Tue, 5 Feb 2002 16:33:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g160W22Q012254 for ; Tue, 5 Feb 2002 16:32:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g160W2mD012253 for mobile-ip-dist; Tue, 5 Feb 2002 16:32:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g160Vw2Q012246 for ; Tue, 5 Feb 2002 16:31:59 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10230 for ; Tue, 5 Feb 2002 16:32:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25675 for ; Tue, 5 Feb 2002 16:32:13 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA15072; Tue, 5 Feb 2002 16:32:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g160WCQ17321; Tue, 5 Feb 2002 16:32:12 -0800 X-mProtect:  Tue, 5 Feb 2002 16:32:12 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdxMkfwO; Tue, 05 Feb 2002 16:32:10 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id QAA66783; Tue, 5 Feb 2002 16:32:11 -0800 (PST) Message-ID: <3C60798B.F1899902@iprg.nokia.com> Date: Tue, 05 Feb 2002 16:32:11 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Charlie Perkins , Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: <933FADF5E673D411B8A30002A5608A0E01DD359D@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn, > > This is an entity with unselected semantics, both endpoint and > > routing semantics are described, but no restriction has been made. > > The reason there are unselected semantics is because there are options that I felt the Internet community as a whole may wish to consider. The main thing that the draft is trying get accross is that: > > "We don't need no stinking overhead. Here are some ways it works. Which way, with its accompanying restrictions do you think is appropriate? Pick one, but please get rid of the overhead - we don't need it now that we have to protect against the reflector spoofing. It is a waste." I agree with you this is a very valuable point in your draft and feel it makes injustice to this point to evaluate it as a whole for the very special case of MIPv6 in mind, if known solutions are sought. I'd be happy to see this kind of an idea to be employed with RO but not necessarily from the document you have in its current form. The possible controversies of overlay routing that may occur if the other parts of the document are proposed as standard did give a factor in the known-unknown axis (we do not yet know how people feel about these). > > That is, by reception, the Shim either switches endpoint > > addresses from authorized state for internal delivery to > > upper layer or in case of generalization, packet is > > forwarded based on state. Non-generalized mode (NGM) fulfills > > the generic requirement of not forwarding out of the node. > > I think it is quite evident that we would be doing NGM if one of the options is applied to MIPv6. The intent of the document was to convey the general concepts and requirements for signaling. The application of the concept to MIPv6 is pretty straight forward given the examples and it would use the NGM - E2E approach if you wish to call it that. Agree with that. > > Alternatively this could have been treated as the applicable > > component of the proposal but since this is a whole draft, > > NGM cannot realistically be just extracted to MIPv6 draft? > > > > We already have a MIPv6 draft. I don't want to come up with a new MIPv6 draft. The ZOD draft's purpose was to convey the idea in sufficient detail such that the rightful authors of the draft can understand the changes and the developers could understand what the reasoning behind the changes were. The mail list and the draft should be sufficient to work out choices. The generalized detail was given in order to let people understand what other uses MIP signaling could be used for to achieve functions other than just node mobility. I think it is very realistic to incorporate the change into MIPv6 in a timely fashion once a choice is made between the alternatives. Good to know. Now there is less unknown about this.. > > Known properties: > > - Header Type: Nothing needed (except a flag both ways) > > > > Derivable properties > > - Position of the flag, this was not specified for all cases, but > > rough alternatives were given. > > > > Unknown properties: > > - Problems resulting from use for other purposes: Not known, > > since this proposal does not restrict itself to host mobility. > > As for the other purposes argument, the problems with the other overhead-based proposals is due to the fact that the overhead exists and a firewall might be inspecting and blocking these other purposes. With ZOD the firewalls have nothing to block; therefore, the issue with "other purposes" is mute. This was not about firewalls, it was about having so far zero feedback on its applicability as a general-purpose proposal, not as "donesn't work" but as in "don't yet know what will the response be" (an unknown). > Again, the idea is to convey the options, bearer semantics and associated requirements for the signaling. The signaling of MIP can be used, as is, with the restrictions detailed in the draft related to host mobility. The same restrictions have pretty much already been agreed to on the mail list. This is hardly the same issue in terms of unknowns as exists with the RH or other overhead-based solutions. With this "other purposes" reasoning I guess we shouldn't use overhead based tunneling mechanisms at all because all of the uses of it are unknown as well. I guess we should throw the routing header into this bucket, as well, with this reasoning. I don't just mean throw them out for MIP only, either. I think this was Charlie's earlier point on the RH. I understand your reservations, since I looked at the whole proposal, not at the applicable part as a separate issue. > If you want to limit MIPv6 signaling to only be used for mobility - go for it. I don't think this would stop people from using it for other purposes, though. The choice of overhead vs no overhead is orthogonal to this argument. True. > With these points in mind, I see the ability of ZOD and MIPv6 signaling to be used for other functions than just mobility as a positive - not an issue or problem. It was an issue in the known-unknown scale rather than does work - doesn't -scale, not communicated well in the text. This did not imply it wouldn't work, rather of the possibility it is not yet analyzed how well does it match peoples' ideas on end-to-end tunneling or forwarding. Given this, the genericity of the proposal in its current form is a factor in the known-unknown axis. > > The choice for delivery vs. forwarding was not made nor strict > > restriction to use with host mobility in delivery, nor the use > > of RO signaling as establishing the state were mandated. This > > many open options leave room for too many unknowns given the > > level of security required for the choice at hand. > > The example of ZOD applied to MIPv6 was given that did detail delivery and forwarding. The draft also gives restrictions and requirements on the signaling related to security in a way that is irrespective of the signaling employed. It just so happens that MIPv6 RO signaling meets these restrictions and requirements. It would be the job of the MIPv6 draft to do the mandating with its specific signaling. What unknowns are you refering to - one will do? Ok. If the signaling is a totally open choice, there are different levels of strength authorization a possible signaling (out of many) would take. Given a signaling has weak authorization and the state created is used for IPsec based communication, it is not specified how this weakness be communicated to IPsec. I do not claim it not to work, just to be an unknown. Rather than saying any signaling, it would be more "known" to specify a particular signaling. > > - Interaction/security with other protocols (given the amount of > > security and other analysis in MIPv6, any generic new method > > deserves this note) > > The draft shows that the security requirements and state necessary to implement route optimized MIPv6, without the reflector spoofing hole, are the same as that which would be needed to remove the extra overhead. In short, if the security for MIPv6 with overhead based tunneling has no issues; neither does ZOD/MR. ZOD. If you could give me an example of where it might be different I can respond to the concerns? Again, this is about the genericity. > > - All possible signaling methods for setting up the > > authorized state (a downside of the proposal is its reliance > > on state, which gets the critique all non-routing-state-based > > forwarding usually does, esp. in its generalized format) > > I'd really like to see someone attempt an efficient implementation of secure route optimized mobile IPv6 (i.e. without the reflector spoofing hole) that doesn't keep the same state. If you see a problem with this state end to end, then you must see the same problem with all of the overhead-based methods that also require this state. This was the entire message of the draft: "Because you have to keep this state to do RO in a secure manner, you don't need the overhead". I guess MIPv6 with any of the overhead based methods has the same downside to it. The state issue is not about its specific use in MIPv6 but about generic use of state in ZOD-based forwarding. I withhold this argument if people see no problems with it, it is just a guess generic stateful forwarding may get some reservation due to robustness, it not using normal routing etc. Anybody reading this has the opportunity to prove me wrong on this. > > - Final stabilized properties, since there may be changes due to > > problems found with other uses. > > Again, the "other uses/other purposes" duplicate argument doesn't hold water because as there is nothing in the packet for the firewalls to block or worry about. The issue with "others" is not there. ZOD is transparent to firewalls. Firewalls is not the only other use, the issue was more of recognizing there is not yet understanding whether the generic part has the concensus to be standardized. > > - Interaction with IPsec > > > > I did, indeed, detail the interactions and processing rules in relation to IPSEC. This detail includes the of order of operations of each component. If you see an specific issue, please detail it? Re. above one example. > > Requirement for change > > - Entry and processing of the bits (Shims) > > - Possible robustness features (several, some due to statefulness) > > > > Again RO'd MIPv6 will have to be just as stateful unless you want to keep the reflector hole. If we keep the hole, it will eventually end up being blocked by firewalls anyway. I.e. a few days after a worm starts to take advantage of it. Actually it may be blocked from day one if the hole exists. Agree with that. If current HAO is not checked against BCE, the hole exists. State needs to be there for RO and HAO checked against authorized BCE. > > Summary: if it had restricted itself to host IPv6 mobility only, > > it would have been a stronger candidate. Then, I do not give > > the proper credit to this otherwise well thought draft, it > > should be a contender with the Deering-Zill tunneling, though > > the requirement for state in forwarding is a liability. > > > > Again all of the alternatives (D/Z, RH, HAO, ZOT, MR. ZOT) will all have to keep the same state in order to protect against the reflector spoofing. The fact that the draft introduced other modes of operation should not have a bearing on MIPv6's application of a specific mode. This thinking is a logical fallacy. Comments above should apply to this. > The overhead of the extra address on the paths between the MN and CN is a waste for MIPv6. Agree on that > Glenn BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 03:20:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14167 for ; Wed, 6 Feb 2002 03:20:03 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22375; Wed, 6 Feb 2002 01:19:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04853; Wed, 6 Feb 2002 00:19:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g168I92Q013302 for ; Wed, 6 Feb 2002 00:18:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g168I9rt013301 for mobile-ip-dist; Wed, 6 Feb 2002 00:18:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g168I62Q013294 for ; Wed, 6 Feb 2002 00:18:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04014 for ; Wed, 6 Feb 2002 00:18:19 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02368 for ; Wed, 6 Feb 2002 01:18:13 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g168I9i06101 for ; Wed, 6 Feb 2002 10:18:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Feb 2002 10:17:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Feb 2002 10:17:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 10:17:40 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95A9@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGuU7itDeGK2BL9SVyT4KzTQ6EKgQAku7Kg To: Cc: X-OriginalArrivalTime: 06 Feb 2002 08:17:40.0886 (UTC) FILETIME=[BEBD1B60:01C1AEE6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g168I62Q013295 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Erik, > Agreeing with what Jari Arkko said but adding an example of > how this could play out in detail. We get a bit reserved in the > low-order 64 bits of an IPv6 address. A reasonable bit might be > the 'group/individual' bit. This probably means that RFC 3041 > and perhaps other specs need to be tweaked to make it clear > that the 'reserved' bit must not be used when forming IPv6 > addresses per those specifications. > > The MIPv6 specification says that if theabove reserved bit is set in > a home address then route optimization using RR MUST NOT be used > (and also says something about CGA being further studied to > be possibly used to route optimize for home addresses that has this bit set). I think that this is a reasonable approach. John From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 03:27:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14234 for ; Wed, 6 Feb 2002 03:27:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09358; Wed, 6 Feb 2002 01:27:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05887; Wed, 6 Feb 2002 00:26:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g168Ps2Q013384 for ; Wed, 6 Feb 2002 00:25:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g168PsQO013383 for mobile-ip-dist; Wed, 6 Feb 2002 00:25:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g168Pp2Q013376 for ; Wed, 6 Feb 2002 00:25:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28573 for ; Wed, 6 Feb 2002 00:26:04 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22953 for ; Wed, 6 Feb 2002 00:26:00 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g168Pni09862 for ; Wed, 6 Feb 2002 10:25:49 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Feb 2002 10:25:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Feb 2002 10:25:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 10:25:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95AB@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGuTxTX4dkktQFIQI+z6qhMlJ7LeQAl+kBg To: Cc: X-OriginalArrivalTime: 06 Feb 2002 08:25:29.0223 (UTC) FILETIME=[D5E3A970:01C1AEE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g168Pp2Q013377 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Jari, > > > 3. Regarding issue (i), the design team recommends that the RR > > > > Can live with this. > > Ok. Hmm... when you say "can live with this", can you > give some indication of why its only "live with" and > not "agree"? 'Can live with' rather than 'Agree' because I'm still trying to sort out the details of RR vs. CGA vs. RR + BSA. I agree that that basic RR doesn't need a BSA, however, if someone wanted additional protection, are you indicating that only CGA is applicable? Are we affectively eliminating RR + BSA as an option for stronger protection? > > > 4. Regarding issue (ii), the design team recommends both CoA > > > > Can live with this. For point 4, it is 'can live with' as opposed to 'agree' basically because I think it will work, but some WG thinking is needed (to see if this can be optimized or not) - but I do think that this is the starting point. > > > 5. In order to guarantee security of the above exchange, the > > > > Can live with this. Actually, I will change my 'vote' to AGREE. > > > 6. For CGA, the design team recommends that 1a/2a can be > > > > Decision on this should be held off, note my concerns above. > > What we tried to do on this one is to evaluate the security > differences between various cases, and basically the same > results that in our opinion indicate the repetition of 1a/2a, > also point to leaving out 1a/2a from CGA in the mentioned > case. > > Do you have a specific comment on the analysis and do > you disagree with the relevant part regarding HoA test? Actually, I will change my vote for AGREE, that with CGA, 1a/2a is probably not needed. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 04:02:25 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14700 for ; Wed, 6 Feb 2002 04:02:24 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07237; Wed, 6 Feb 2002 02:01:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10580; Wed, 6 Feb 2002 01:01:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g168xw2Q013520 for ; Wed, 6 Feb 2002 00:59:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g168xv2L013519 for mobile-ip-dist; Wed, 6 Feb 2002 00:59:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g168xs2Q013512 for ; Wed, 6 Feb 2002 00:59:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06017 for ; Wed, 6 Feb 2002 01:00:08 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28699 for ; Wed, 6 Feb 2002 02:00:07 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g16902X4004674; Wed, 6 Feb 2002 10:00:02 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g16902r6027930; Wed, 6 Feb 2002 11:00:02 +0200 (EET) Message-ID: <3C60F092.FE30AB1F@lmf.ericsson.se> Date: Wed, 06 Feb 2002 11:00:02 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95AB@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > > > > 3. Regarding issue (i), the design team recommends that the RR > > > > > > Can live with this. > > > > Ok. Hmm... when you say "can live with this", can you > > give some indication of why its only "live with" and > > not "agree"? > > 'Can live with' rather than 'Agree' because I'm still trying > to sort out the details of RR vs. CGA vs. RR + BSA. I agree > that that basic RR doesn't need a BSA, however, if someone > wanted additional protection, are you indicating that only > CGA is applicable? Are we affectively eliminating RR + BSA > as an option for stronger protection? Ah, I see... The first conclusion we made was that specific signaling is always needed with RR anyway on every BU, so having a BSA does not accomplish much. A lone BSA would actually be harmful, if you didn't need to do e.g. CoA tests. So this is the justification why we believe BSA may not buy us anything in the RR case. However, I do *not* believe this eliminates any future options as to the use of BSAs with RR, CGA or other techniques. My personal opinion on the use of the BSAs e.g. a la IPsec would be that they would be *additional* protection on top of RR, not a replacement. But I would note that the design team hasn't yet produced a recommendation on the use of strong authentication to aid BU authorization. We will soon, though... > For point 4, it is 'can live with' as opposed to 'agree' basically > because I think it will work, but some WG thinking is needed > (to see if this can be optimized or not) - but I do think that > this is the starting point. Ok. All discussion on whether there can be optimizations is of course welcome. The Residual_threats.txt has tried to discuss why we believe these things are needed. We'd be very happy in particular if you can pinpoint something we missed there. > > > > 5. In order to guarantee security of the above exchange, the > > Actually, I will change my 'vote' to AGREE. Great... > Actually, I will change my vote for AGREE, that with CGA, > 1a/2a is probably not needed. Great... thanks again for your input! Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 04:18:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14895 for ; Wed, 6 Feb 2002 04:18:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13905; Wed, 6 Feb 2002 02:18:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12897; Wed, 6 Feb 2002 01:18:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g169GQ2Q013629 for ; Wed, 6 Feb 2002 01:16:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g169GQhQ013628 for mobile-ip-dist; Wed, 6 Feb 2002 01:16:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g169GN2Q013621 for ; Wed, 6 Feb 2002 01:16:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12563 for ; Wed, 6 Feb 2002 01:16:36 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24601 for ; Wed, 6 Feb 2002 02:16:35 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA00917 for ; Wed, 6 Feb 2002 02:16:35 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA05273 for ; Wed, 6 Feb 2002 02:16:34 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Wed, 6 Feb 2002 03:16:25 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0843D2EC83; Wed, 6 Feb 2002 10:11:52 +0100 (CET) To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] bit method and u/l bit (Was: BU Authorization method: design team recommendation) References: From: Alexandru Petrescu Date: 06 Feb 2002 10:16:31 +0100 In-Reply-To: Message-Id: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik Nordmark writes: > > > authorization methods, using the "bit method" described in the URL > > > referenced from section 1, is included in this RFC as well. > > > > CAN TOLERATE, but bit method should be presented to ipng and get some > > input from them. Erik already proposed u/g but I guess that is too > > much related to Ethernet? > > RFC 2373 relies on the IEEE EUI-64 addressing format (which is a superset > of IEEE 802 aka Ethernet addresses) so this wouldn't add any new > relationships. IEEE EUI-64 being a superset of IEEE 802 is still not all potential types of L2's under IPv6. I bet that most SDO's developping L2's for current telecom trends will not ask IEEE how to generate their ID's simply because their vision of a network is different. True that RFC 2373 relies on EUI-64 (modified) but reserves space for future addresses that don't necessarily rely on EUI-64 (again, the 0::/3 prefixes). Or I might have wrong understanding of their purpose, or wrongly interpreting the text. Just a thought. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 04:25:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14995 for ; Wed, 6 Feb 2002 04:25:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29201; Wed, 6 Feb 2002 02:24:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12397; Wed, 6 Feb 2002 01:24:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g169Ni2Q013817 for ; Wed, 6 Feb 2002 01:23:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g169NiKS013816 for mobile-ip-dist; Wed, 6 Feb 2002 01:23:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g169Nf2Q013809 for ; Wed, 6 Feb 2002 01:23:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26167 for ; Wed, 6 Feb 2002 01:23:55 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11542 for ; Wed, 6 Feb 2002 01:23:49 -0800 (PST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 1606743181 for ; Wed, 6 Feb 2002 10:23:48 +0100 (CET) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 8938699E76 for ; Wed, 6 Feb 2002 10:23:47 +0100 (CET) Message-ID: <3C60F61F.ECBC6A51@it.uc3m.es> Date: Wed, 06 Feb 2002 10:23:43 +0100 From: Ignacio Soto Campos X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft on random interface identifiers available References: <82ECD4351A4A9547957C606034A3CB8DBF940B@daebe005.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefano, stefano.faccin@nokia.com wrote: > I have a question regarding section 3 on generation of random numbers. In the ID you state: > > "... it should be noted that because of the randomness of the identifier, it is not necessary to create the identifier in real time, i.e. when the node joins the network, but the identifier can be already created ... What is more, this random number can be pre-configured in the interface driver and the node can use always the same number without changing the probabilities calculations made above. This reduces the needed complexity in the nodes." > > My question is: how is this then any different from having a 62 bit interface identifier allocated to the mobile node? You just need to make sure that the identifier is unique. The identifier can be assigned to physical nodes such as mobile phones by e.g. the manufacturer, and for laptops either by the manufacturer or e.g. by the ISP when a subscription is activated. > The difference is "you just need to make sure that the identifier is unique". This is not an easy task, mainly if you think of a network with a lot of different access technologies (it is not only for mobile nodes because they can visit networks with desktop computers). If we'd have a way of creating unique identifiers for any case, that would solve the problem. The draft says that you can generate the random number by any means you want, for example when the network driver is installed a random number can be generated and associated with the driver so that the node can use it any time it joins a network. But we don't assume a centralized mechanism or a procedure to guarantee that this random number is unique, that wouldn't be realistic at this time. Regards, Ignacio > > Thanks for any clarifications, > Stefano > > -----Original Message----- > From: ext Ignacio Soto Campos [mailto:isoto@it.uc3m.es] > Sent: Monday, February 04, 2002 9:52 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: marcelo@it.uc3m.es; alberto@it.uc3m.es > Subject: [mobile-ip] draft on random interface identifiers available > > Hi all, > > We have submitted the draft "Random generation of interface > identifiers" that is available from: > > http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt > > The abstract is included below. Comments are welcomed. > > Abstract > > This document evaluates the use of random numbers to generate the > interface identifier part of an IPv6 address on mobile environments, > where Duplicate Address Detection (DAD) mechanisms are expensive. > We have estimated the probability of having an address duplication > using this mechanism and we conclude that the IPv6 addresses created > in this way could be used without previously doing DAD to test the > uniqueness of the address in a link. > > Best regards, > > Ignacio From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 05:26:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15846 for ; Wed, 6 Feb 2002 05:26:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08138; Wed, 6 Feb 2002 03:25:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07181; Wed, 6 Feb 2002 02:25:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16AOP2Q014003 for ; Wed, 6 Feb 2002 02:24:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16AOPO3014002 for mobile-ip-dist; Wed, 6 Feb 2002 02:24:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16AOL2Q013995 for ; Wed, 6 Feb 2002 02:24:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g16AOUM07237; Wed, 6 Feb 2002 11:24:30 +0100 (MET) Date: Wed, 6 Feb 2002 11:20:35 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] bit method and u/l bit (Was: BU Authorization method: design team recommendation) To: Alexandru Petrescu Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > IEEE EUI-64 being a superset of IEEE 802 is still not all potential > types of L2's under IPv6. I bet that most SDO's developping L2's for > current telecom trends will not ask IEEE how to generate their ID's > simply because their vision of a network is different. They don't need to - they can set the "universal" bit to zero and use a number which is not from the IEEE space. But when they do that they need to realize that RFC 3041 generates random interface IDs in that space. > True that RFC 2373 relies on EUI-64 (modified) but reserves space for > future addresses that don't necessarily rely on EUI-64 (again, the > 0::/3 prefixes). Or I might have wrong understanding of their > purpose, or wrongly interpreting the text. 0::/3 is not intended for such use at all. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 06:06:39 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16709 for ; Wed, 6 Feb 2002 06:06:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18040; Wed, 6 Feb 2002 02:56:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13167; Wed, 6 Feb 2002 02:55:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Asw2Q014130 for ; Wed, 6 Feb 2002 02:54:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16AswPf014129 for mobile-ip-dist; Wed, 6 Feb 2002 02:54:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ast2Q014122 for ; Wed, 6 Feb 2002 02:54:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04115 for ; Wed, 6 Feb 2002 02:55:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00312 for ; Wed, 6 Feb 2002 03:55:09 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16At7a25599; Wed, 6 Feb 2002 11:55:07 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA01682; Wed, 6 Feb 2002 11:55:07 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16At7g73520; Wed, 6 Feb 2002 11:55:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061055.g16At7g73520@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available In-reply-to: Your message of Mon, 04 Feb 2002 16:51:46 +0100. <3C5EAE12.DA5F9400@it.uc3m.es> Date: Wed, 06 Feb 2002 11:55:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From the end of the conclusion: Whether DAD should be performed after or it can be avoided, needs further study. For now, we think that performing DAD after joining the link is needed. => in fact there is no real difference between to perform after or to avoid: if there is a duplicate you are simply dead... Personnaly I don't like things which mostly work and IMHO the best solution is to put the control of to do or not DAD in the hands of the user because of the special situations (*partial* lists: - universal interface IDs which are known to be really universal (MAC addresses of NICs not found in the trash can) - PPP (two nodes so collisions are not so frequent, and IPv6CP manages the two interface IDs and guarantees they are different)). The only thing important (and done in the MIPv6 I-D) is to remove the absolute requirement for DAD. Regards Francis.Dupont@enst-bretagne.fr PS: I'd prefer to see a proposal for building universal IIDs for EMEI (does someone share this opinion? We have a lot of GSM experts in the building :-) From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 06:47:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17567 for ; Wed, 6 Feb 2002 06:47:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA24178; Wed, 6 Feb 2002 03:37:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26724; Wed, 6 Feb 2002 03:37:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16BaA2Q014277 for ; Wed, 6 Feb 2002 03:36:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16BaAsd014276 for mobile-ip-dist; Wed, 6 Feb 2002 03:36:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ba62Q014269 for ; Wed, 6 Feb 2002 03:36:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27291 for ; Wed, 6 Feb 2002 03:36:20 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22422 for ; Wed, 6 Feb 2002 03:36:19 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16BaGa31512; Wed, 6 Feb 2002 12:36:16 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA02534; Wed, 6 Feb 2002 12:36:16 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16BaGg73814; Wed, 6 Feb 2002 12:36:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061136.g16BaGg73814@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available In-reply-to: Your message of Tue, 05 Feb 2002 13:29:15 +0100. <3C5FD01B.AD58421A@it.uc3m.es> Date: Wed, 06 Feb 2002 12:36:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: We'd like to know if the described approach are seen as relevant for mobile environments. => this term "mobile environments" disturbs me because MIPv6 is supposed to work anywhere, i.e. not only in "mobile environments". BTW I agree this is an IPv6 topic. Francis.Dupont@enst-bretagne.fr PS: about IMEI, they have 14 decimal digits (7 bytes in BCD, 6 in binary) so it is possible to build EUI-64 from them... From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 06:53:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17730 for ; Wed, 6 Feb 2002 06:53:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02739; Wed, 6 Feb 2002 04:42:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27247; Wed, 6 Feb 2002 03:42:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Bfm2Q014353 for ; Wed, 6 Feb 2002 03:41:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16BflId014352 for mobile-ip-dist; Wed, 6 Feb 2002 03:41:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Bfi2Q014345; Wed, 6 Feb 2002 03:41:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21351; Wed, 6 Feb 2002 03:41:58 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20149; Wed, 6 Feb 2002 03:41:57 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA17562; Wed, 6 Feb 2002 04:41:56 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id EAA20181; Wed, 6 Feb 2002 04:41:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Wed, 6 Feb 2002 04:41:53 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id B9A572EC83; Wed, 6 Feb 2002 12:37:11 +0100 (CET) To: monet@nal.motlabs.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, seamoby@ietf.org Subject: [mobile-ip] Announce: monet list moved, archives available over http From: Alexandru Petrescu Date: 06 Feb 2002 12:41:51 +0100 Message-Id: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Please excuse cross-posting and multiple copies] Hi, This is to announce that the monet list has been moved to monet@nal.motlabs.com. Archives of discussions starting now as well as archives of discussions Dec 2001-Jan 2002 are available at: http://www.nal.motlabs.com/mailman/listinfo/monet All subscribers to the old monet list have been de-subscribed from it and re-subscribed to the new location. The subject line changed from Monet to monet, so your local filters might need update. Thanks, Alex PS: the change in hosting name was needed in order to deliver archives directly over the web. PPS: I still have delivery problems to three addresses, I will try to contact them personally. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 07:25:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18199 for ; Wed, 6 Feb 2002 07:25:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13284; Wed, 6 Feb 2002 05:15:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02490; Wed, 6 Feb 2002 04:15:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16CE92Q014721 for ; Wed, 6 Feb 2002 04:14:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16CE9fl014720 for mobile-ip-dist; Wed, 6 Feb 2002 04:14:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16CE62Q014713 for ; Wed, 6 Feb 2002 04:14:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01345 for ; Wed, 6 Feb 2002 04:14:20 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04522 for ; Wed, 6 Feb 2002 05:14:15 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id E5638431E7; Wed, 6 Feb 2002 13:14:10 +0100 (CET) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 2F78699E71; Wed, 6 Feb 2002 13:13:36 +0100 (CET) Message-ID: <3C611DEC.4D494EB9@it.uc3m.es> Date: Wed, 06 Feb 2002 13:13:32 +0100 From: Ignacio Soto Campos X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Francis Dupont Cc: alberto@it.uc3m.es, marcelo@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available References: <200202061055.g16At7g73520@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, Francis Dupont wrote: > >From the end of the conclusion: > Whether DAD should be performed after or it can be avoided, needs further > study. For now, we think that performing DAD after joining the link > is needed. > > => in fact there is no real difference between to perform after > or to avoid: if there is a duplicate you are simply dead... > Actually, we don't think that the situation is as bad as being dead. If you are able to detect the duplication and to generate a new interface identifier, you just have suffered an interruption in your communication (which we agree it can be serious enough to make your established communications to time out). Besides, performing DAD after allows you, for example, to detect the duplicate address pro-actively when communications are not established. Even when communications are established, performing DAD allows you to improve your recovery time. Whether this is worth the cost of doing it, is what we propose to discuss. > Personnaly I don't like things which mostly work and IMHO the > best solution is to put the control of to do or not DAD in the hands > of the user because of the special situations (*partial* lists: > - universal interface IDs which are known to be really universal > (MAC addresses of NICs not found in the trash can) > - PPP (two nodes so collisions are not so frequent, and IPv6CP > manages the two interface IDs and guarantees they are different)). > The only thing important (and done in the MIPv6 I-D) is to remove > the absolute requirement for DAD. > The MIPv6 I-D states: "After forming a new care-of address, a mobile node MAY perform Duplicate Address Detection [27] on that new address to confirm its uniqueness. However, doing so represents a tradeoff between safety (ensuring that the new address is not used if it is a duplicate address) and overhead..." Our draft tries to asses how safe is to avoid DAD before using IPv6 addresses created from random numbers. We think this is interesting because is a concrete method to create the interface identifiers and a quantification of the risks involved in using the resulting addresses before doing DAD. > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I'd prefer to see a proposal for building universal IIDs for EMEI > (does someone share this opinion? We have a lot of GSM experts in the > building :-) Universal unique IIDs for IPv6 addresses is an interesting subject, have you any idea of any steps to its implementation? Regards, Marcelo and Ignacio From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 08:44:02 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19768 for ; Wed, 6 Feb 2002 08:44:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12825; Wed, 6 Feb 2002 05:33:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13478; Wed, 6 Feb 2002 05:33:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16DWB2Q014830 for ; Wed, 6 Feb 2002 05:32:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16DWB9b014829 for mobile-ip-dist; Wed, 6 Feb 2002 05:32:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16DW72Q014819 for ; Wed, 6 Feb 2002 05:32:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11738 for ; Wed, 6 Feb 2002 05:32:22 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10450 for ; Wed, 6 Feb 2002 06:32:21 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g16DWJC16487 for ; Wed, 6 Feb 2002 14:32:20 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Feb 06 14:32:19 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 14:22:58 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A9A6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: RE: [mobile-ip] draft on random interface identifiers available Date: Wed, 6 Feb 2002 14:31:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Francis.Dupont@enst-bretagne.fr: > > PS: about IMEI, they have 14 decimal digits (7 bytes in > BCD, 6 in binary) > so it is possible to build EUI-64 from them... => Yes, it is, but that's only for the GSM family of course (and WCDMA). Anyway, I think this will probably raise some privacy issues (tracking devices ...etc) Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 09:10:50 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20359 for ; Wed, 6 Feb 2002 09:10:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17692; Wed, 6 Feb 2002 06:00:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20780; Wed, 6 Feb 2002 05:59:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Dwm2Q014975 for ; Wed, 6 Feb 2002 05:58:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16DwmeI014974 for mobile-ip-dist; Wed, 6 Feb 2002 05:58:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Dwj2Q014967 for ; Wed, 6 Feb 2002 05:58:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15400 for ; Wed, 6 Feb 2002 05:59:00 -0800 (PST) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15481 for ; Wed, 6 Feb 2002 06:58:59 -0700 (MST) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id g16DwvkB009810 ; Wed, 6 Feb 2002 14:58:57 +0100 X-pt: isis.lip6.fr Received: from otos (otos.lip6.fr [132.227.61.47]) by tibre.lip6.fr (8.11.3nb1/8.11.3) with SMTP id g16Dwvx00629; Wed, 6 Feb 2002 14:58:57 +0100 (MET) From: "Rolland Vida" To: Cc: Subject: RE: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources Date: Wed, 6 Feb 2002 14:58:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C5FEBF9.50409@clarinet.u-strasbg.fr> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Cristophe, > First I want to insist on the fact that Dave's solution is quite > different in the sense that after the source handoff, there is no > multicast delivery until receivers join the new tree. At the IETF, Dave only presented the problem, and described a possible solution. He did not enter in the details, he did not put it in a draft yet, as far as I know. So the details can be discussed. The idea that you do not prune off the branch of the old tree before receiving data on the new one, is OK. But you can do the same thing with Dave's solution. The only difference is the path on which you receive BUs. > in Dave's solution there is a need to keep two trees, and the one rooted at the HA > is almost never used (unless to send BU), and this means that extra > router states are created for very little use. That might be true. It might be inefficient, but maybe necessary. > Moreover, I haven't seen > anything about session and channel identifiers in Dave's proposal. As I said, Dave presented only a proposal, not an entire draft, treating all the possible details. But talking about this issue, I have a related question. How do you manage newcomer receivers? As far as I understood, you will advertise the cCoA of the source, and everybody that wants to join the session, should be aware of the current position of the source. This means that all the time the source moves, it should update the information in the whole Internet. Otherwise, if a newomer tries to join a CoA, and the source already moved, the join will be lost. On the other hand, if a newomer sends its joins towards the home domain, it will always succeed. The problem is that in the home domain there is a HA that tunnels packets. In a foreign domain there's no such agent. So how do you transmit this channel address change in the Internet? You might use a multicast tree for this, and here we are with your second tree, that you wanted to avoid in the first place. > Also, I want to stress the fact that even after the source handoff, only > one branch per receiver is active, since when the new branch is active > (packets received on the new tree) the old branch is prunned. Yes, but for a sparse group and a rapidly moving source, you might lose completely the advantages of multicast, and use only tunnels and branches with a single receiver (i.e. unicast). > Answering your point about a fast moving source (CoA1, CoA2, CoA3) : the > source moves from CoA1 to CoA2, it sends an encapsulated BU on the tree > rooted at CoA1, receivers start to join towards CoA2. The source moves > to CoA3 before all receivers have joined CoA2. It sends a BU on the tree > rooted at CoA1, and another BU on the tree rooted at CoA2. Receivers > start to join CoA3. Data is sent on the three trees, so that receivers > joining CoA3 still receive data on old trees. When the source is being > notified by NSNIP (not covered in the draft) that there are no receivers > on old trees (CoA1 and/or CoA2), it stops sending BU and data on the > appropriate old tree. Also note that even if data is sent on the three > trees, only one branch is active per receiver and therefore data is not > sent three times more than with just one tree. > > Of course, the best point in Dave's solution is, as you say, that > receivers will always get the BU but it is also the case in our > proposal. Our solution is slightly more complicated but we believe that > it is the price to minimise the disruption time after a source handoff. > Rolland From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 09:44:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21383 for ; Wed, 6 Feb 2002 09:44:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00312; Wed, 6 Feb 2002 07:33:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20450; Wed, 6 Feb 2002 06:32:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16ETw2Q015035 for ; Wed, 6 Feb 2002 06:29:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16ETwPW015034 for mobile-ip-dist; Wed, 6 Feb 2002 06:29:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16ETt2Q015027 for ; Wed, 6 Feb 2002 06:29:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21721 for ; Wed, 6 Feb 2002 06:30:10 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28656 for ; Wed, 6 Feb 2002 07:30:10 -0700 (MST) Received: from clarinet.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id PAA24273 for ; Wed, 6 Feb 2002 15:30:08 +0100 Message-ID: <3C613E01.2090607@clarinet.u-strasbg.fr> Date: Wed, 06 Feb 2002 15:30:26 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.3) Gecko/20020129 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Draft on mobile (MIPv6) PIM-SSM sources References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Rolland and thanks for your comments, Newcomer receivers is indeed an interesting issue in our proposal. We proposed to use an extended version of SDR (which, once again, is not covered in the current draft) that should be capable of annoucing the CoA, the group address, and also the source home address H@. A new receiver would be interested by the pair (H@,G) which we call the SSM session, and would connect to the tree (CoA,G) which we call the SSM channel. You are right when you say that this information should be made known to the whole Internet, but that's the way it works now with the current version of SDR. It is however important to note that the SDR tree is a shared tree, i.e. there is only one tree for the whole set of multicast groups/sources. Therefore we do not add an extra tree, it already exists and we just propose to extend this solution to announce the (CoA,G,H@) information needed to join the tree. Of course, Dave's solution which is to keep a tree rooted at the home agent avoids the need for an extended version of SDR. But a new receiver still needs to be made aware of the (H@,G) pair, and unless you want to have it statically somewhere (e.g. on a web site), SDR should still be used and you'll also have to join the SDR shared tree. Well we really appreciate your replies and we are very opened to people comments and suggestions. In fact, it would be interesting to see new ideas and proposals (that are not in our current draft) which could be compared with our current solution (which is still a draft 00, and is far from being complete). Maybe this could lead to a common effort to propose a new unique draft combining the best parts of all solutions. Best regards, Christophe Rolland Vida wrote: > >As I said, Dave presented only a proposal, not an entire draft, treating all >the possible details. >But talking about this issue, I have a related question. >How do you manage newcomer receivers? As far as I understood, you will >advertise the cCoA of the source, and everybody that wants to join the >session, should be aware of the current position of the source. This means >that all the time the source moves, it should update the information in the >whole Internet. >Otherwise, if a newomer tries to join a CoA, and the source already moved, >the join will be lost. On the other hand, if a newomer sends its joins >towards the home domain, it will always succeed. The problem is that in the >home domain there is a HA that tunnels packets. In a foreign domain there's >no such agent. > >So how do you transmit this channel address change in the Internet? You >might use a multicast tree for this, and here we are with your second tree, >that you wanted to avoid in the first place. > > >Rolland > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 09:51:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21576 for ; Wed, 6 Feb 2002 09:51:29 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26461; Wed, 6 Feb 2002 06:40:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21419; Wed, 6 Feb 2002 06:40:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ect2Q015084 for ; Wed, 6 Feb 2002 06:38:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16EctXB015083 for mobile-ip-dist; Wed, 6 Feb 2002 06:38:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ecp2Q015076 for ; Wed, 6 Feb 2002 06:38:51 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g16Ed3M02477; Wed, 6 Feb 2002 15:39:03 +0100 (MET) Date: Wed, 6 Feb 2002 15:35:09 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] draft on random interface identifiers available To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, marcelo@it.uc3m.es, alberto@it.uc3m.es In-Reply-To: "Your message with ID" <200202061055.g16At7g73520@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is an IPv6 WG topic - why don't we move it there? > => in fact there is no real difference between to perform after > or to avoid: if there is a duplicate you are simply dead... Question is who and how many are dead. If one node has been around communicating for a while and a new node appears that has a duplicate address with the first we can choose between: 1. Have both be disrupted - presumably to the extent they can pick new addresses they will both need to do so. 2. Have one be disrupted a. Have the new guy be disrupted b. Have the old node be disrupted Only if you think #1 makes sense it is true that after vs. before makes no difference. But Duplicate Address Detection as defined does 2a. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 09:53:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21636 for ; Wed, 6 Feb 2002 09:53:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21436; Wed, 6 Feb 2002 07:42:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21841; Wed, 6 Feb 2002 06:42:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Eew2Q015109 for ; Wed, 6 Feb 2002 06:40:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16EevBc015108 for mobile-ip-dist; Wed, 6 Feb 2002 06:40:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ees2Q015101 for ; Wed, 6 Feb 2002 06:40:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24103 for ; Wed, 6 Feb 2002 06:41:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07665 for ; Wed, 6 Feb 2002 07:41:08 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16Ef6a27319; Wed, 6 Feb 2002 15:41:06 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA07409; Wed, 6 Feb 2002 15:41:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16Ef6g74635; Wed, 6 Feb 2002 15:41:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061441.g16Ef6g74635@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ignacio Soto Campos cc: mobile-ip@sunroof.eng.sun.com, alberto@it.uc3m.es, marcelo@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available In-reply-to: Your message of Wed, 06 Feb 2002 13:13:32 +0100. <3C611DEC.4D494EB9@it.uc3m.es> Date: Wed, 06 Feb 2002 15:41:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > >From the end of the conclusion: > Whether DAD should be performed after or it can be avoided, needs further > study. For now, we think that performing DAD after joining the link > is needed. > > => in fact there is no real difference between to perform after > or to avoid: if there is a duplicate you are simply dead... Actually, we don't think that the situation is as bad as being dead. => just try it... There is a race condition between the two nodes with the same address, in general none wins (any packet goes to the wrong node :-). If you are able to detect the duplication and to generate a new interface identifier, you just have suffered an interruption in your communication (which we agree it can be serious enough to make your established communications to time out). => don't forget the other node... With IPv6 NUD helps to recover but each time I saw this kind of problems (in IPv4) it caused real damage! Our draft tries to asses how safe is to avoid DAD before using IPv6 addresses created from random numbers. We think this is interesting because is a concrete method to create the interface identifiers and a quantification of the risks involved in using the resulting addresses before doing DAD. => my answer is simple: please don't play Russian roulette with my network! Universal unique IIDs for IPv6 addresses is an interesting subject, => they are a far better solution too because if the source of the IID is not really unique something at the link-layer should break too (for instance duplicate MAC addresses). have you any idea of any steps to its implementation? => MAC addresses (MAC-48 -> EUI-48 -> EUI-64 -> IID) have the property, in GSM or UMTS IMEIs have it (I just need the time to write an I-D). I don't know for ESNs in USA, 3GPP2 documents are not very clear, ESNs are a bit short and are involved into security (in this case the 3GPP has done a far better job than the 3GPP2). Regards Francis.Dupont@enst-bretagne.fr PS: I already saw a case where DAD avoided a disaster: DAD *is* useful! From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 10:00:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21909 for ; Wed, 6 Feb 2002 10:00:06 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28660; Wed, 6 Feb 2002 06:49:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22680; Wed, 6 Feb 2002 06:49:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Els2Q015207 for ; Wed, 6 Feb 2002 06:47:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16ElsNJ015206 for mobile-ip-dist; Wed, 6 Feb 2002 06:47:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Elp2Q015199 for ; Wed, 6 Feb 2002 06:47:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25629 for ; Wed, 6 Feb 2002 06:48:07 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16242 for ; Wed, 6 Feb 2002 06:48:06 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16Em3a28302; Wed, 6 Feb 2002 15:48:03 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA07591; Wed, 6 Feb 2002 15:48:03 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16Em2g74698; Wed, 6 Feb 2002 15:48:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061448.g16Em2g74698@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available In-reply-to: Your message of Wed, 06 Feb 2002 14:31:51 +0100. <4DA6EA82906FD511BE2F00508BCF053802C6A9A6@Esealnt861.al.sw.ericsson.se> Date: Wed, 06 Feb 2002 15:48:02 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => Yes, it is, but that's only for the GSM family of course (and WCDMA). Anyway, I think this will probably raise some privacy issues (tracking devices ...etc) => privacy issues are the same than for MAC based IIDs... Both (MAC and IMEI based IIDs) are attached to the hardware and are reasonnably guaranteed to be unique in the whole universe. Regards Francis.Dupont@enst-bretagne.fr (through the 00:10:dc:a2:53:82 Ethernet) From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 10:11:07 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22458 for ; Wed, 6 Feb 2002 10:11:06 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12766; Wed, 6 Feb 2002 08:00:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24500; Wed, 6 Feb 2002 07:00:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ex42Q015327 for ; Wed, 6 Feb 2002 06:59:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Ex37l015326 for mobile-ip-dist; Wed, 6 Feb 2002 06:59:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ex02Q015319 for ; Wed, 6 Feb 2002 06:59:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03057 for ; Wed, 6 Feb 2002 06:59:14 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18514 for ; Wed, 6 Feb 2002 07:59:13 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g16Ex9v08324; Wed, 6 Feb 2002 06:59:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV27276; Wed, 6 Feb 2002 06:58:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA24543; Wed, 6 Feb 2002 06:59:08 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15457.17596.186810.603818@thomasm-u1.cisco.com> Date: Wed, 6 Feb 2002 06:59:08 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: john.loughney@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: <3C60F092.FE30AB1F@lmf.ericsson.se> References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95AB@esebe004.NOE.Nokia.com> <3C60F092.FE30AB1F@lmf.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > However, I do *not* believe this eliminates any > future options as to the use of BSAs with RR, CGA > or other techniques. My personal opinion on the > use of the BSAs e.g. a la IPsec would be that they > would be *additional* protection on top of RR, > not a replacement. Even in the case of HA/MN? The HA really knows the authorization status of the subnet the MN is using, therefore possession of the key should be sufficient test, right? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 10:23:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22919 for ; Wed, 6 Feb 2002 10:23:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04109; Wed, 6 Feb 2002 07:12:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26295; Wed, 6 Feb 2002 07:12:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16FBF2Q015433 for ; Wed, 6 Feb 2002 07:11:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16FBF1Q015432 for mobile-ip-dist; Wed, 6 Feb 2002 07:11:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16FBC2Q015425 for ; Wed, 6 Feb 2002 07:11:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27984 for ; Wed, 6 Feb 2002 07:11:26 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22694 for ; Wed, 6 Feb 2002 08:11:24 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g16FBMX4018967; Wed, 6 Feb 2002 16:11:22 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g16FBMr6024656; Wed, 6 Feb 2002 17:11:22 +0200 (EET) Message-ID: <3C61479A.9DEB3464@lmf.ericsson.se> Date: Wed, 06 Feb 2002 17:11:22 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, mat@cisco.com CC: john.loughney@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95AB@esebe004.NOE.Nokia.com> <3C60F092.FE30AB1F@lmf.ericsson.se> <15457.17596.186810.603818@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Jari Arkko writes: > > However, I do *not* believe this eliminates any > > future options as to the use of BSAs with RR, CGA > > or other techniques. My personal opinion on the > > use of the BSAs e.g. a la IPsec would be that they > > would be *additional* protection on top of RR, > > not a replacement. > > Even in the case of HA/MN? The HA really knows > the authorization status of the subnet the MN > is using, therefore possession of the key should > be sufficient test, right? Sorry for the confusion. I was talking about MN-CN security in the above. I believe IPsec SA would be sufficient for the HA-MN security. RR nor CGA would not be run MN-HA. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 10:28:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23114 for ; Wed, 6 Feb 2002 10:28:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25818; Wed, 6 Feb 2002 08:26:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05228; Wed, 6 Feb 2002 07:26:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16FPM2Q015491 for ; Wed, 6 Feb 2002 07:25:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16FPLpi015490 for mobile-ip-dist; Wed, 6 Feb 2002 07:25:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16FPI2Q015483 for ; Wed, 6 Feb 2002 07:25:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00711 for ; Wed, 6 Feb 2002 07:25:32 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11288 for ; Wed, 6 Feb 2002 08:25:31 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g16FPQa02765; Wed, 6 Feb 2002 16:25:26 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA08655; Wed, 6 Feb 2002 16:25:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g16FPQg74926; Wed, 6 Feb 2002 16:25:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202061525.g16FPQg74926@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, marcelo@it.uc3m.es, alberto@it.uc3m.es Subject: Re: [mobile-ip] draft on random interface identifiers available In-reply-to: Your message of Wed, 06 Feb 2002 15:35:09 +0100. Date: Wed, 06 Feb 2002 16:25:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: This is an IPv6 WG topic - why don't we move it there? => I agree! > => in fact there is no real difference between to perform after > or to avoid: if there is a duplicate you are simply dead... Question is who and how many are dead. If one node has been around communicating for a while and a new node appears that has a duplicate address with the first we can choose between: 1. Have both be disrupted - presumably to the extent they can pick new addresses they will both need to do so. => without DAD the result is #1, in general they are so disrupted than at least one picks a new address and the situation recovers after some timeouts (short timeouts in IPv6 because of NUD). 2. Have one be disrupted a. Have the new guy be disrupted b. Have the old node be disrupted Only if you think #1 makes sense it is true that after vs. before makes no difference. But Duplicate Address Detection as defined does 2a. => 2a is the best solution so DAD is good. I never got it in a real situation for IPv4 when there is no DAD, in general the result is #1 and sometimes 2b (simply because there is someone who looks at what happens). Regards Francis.Dupont@enst-bretagne.fr PS: I don't want a new DAD or not DAD discussion. I prefer a globally unique vs. probably unique one with who should do the choice/where should be the control, etc. I.e. more operational topics, DAD is an operational tool, its theoretical aspect is no more than the birthday paradox (i.e. IMHO has no interest). From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 11:09:56 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24644 for ; Wed, 6 Feb 2002 11:09:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18740; Wed, 6 Feb 2002 08:09:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08231; Wed, 6 Feb 2002 08:08:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16G7d2Q015708 for ; Wed, 6 Feb 2002 08:07:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16G7dRY015707 for mobile-ip-dist; Wed, 6 Feb 2002 08:07:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16G7a2Q015700 for ; Wed, 6 Feb 2002 08:07:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08039 for ; Wed, 6 Feb 2002 08:07:50 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18700 for ; Wed, 6 Feb 2002 09:07:50 -0700 (MST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 6 Feb 2002 08:07:35 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Feb 2002 08:07:35 -0800 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 08:07:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [mobile-ip] RE: BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 08:07:34 -0800 Message-ID: Thread-Topic: BU Authorization method: design team recommendation Thread-Index: AcGtv8HeZUUJAwVzS+eCgc3pxeY72gBWwhfwAAMWrWA= From: "Tuomas Aura" To: X-OriginalArrivalTime: 06 Feb 2002 16:07:34.0716 (UTC) FILETIME=[639227C0:01C1AF28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g16G7a2Q015701 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit [Resending because of garbled line breaks] Some comments on the recommendations: > (i) Whether or not Binding Security Associations (BSAs) are > used Yes, BSA is needed in order to implement Recommendation 6! Since HoA RR is omitted for most BUs, you need some other way of authenticating these BUs. Otherwise, the attacker could use its own address as the CoA, pass the CoA RR test, and send false BU. > (ii) What addresses need RR tests (HoA, CoA, or both), and > what is the correct time to perform the tests, always > at the time the binding is requested? When CREATING a BCE, both HoA RR and CoA RR are needed. CGA Authentication is a plus. (At this time, a BSA can be established either with CGA+DH or by sending the key in plain text in the HoA RR message.) When UPDATING a BCE with a new CoA, only CoA RR is needed. HoA RR before a location change adds unnecessary latency and should be avoided, but read further for an exception. (Without BSA, HoA RR would also be needed to authenticate the BU.) When REFRESHING a BCE without changing the CoA, I suggest testing both CoA RR and HoA RR every time. CoA RR verifies that the mobile really has stayed at CoA. Frequent HoA RR ensures that CN can delete the BCE at any time and when it does, a HoA RR test has been done recently. This prevents bombing attacks against HoA (to be documented in draft-aura-mipv6-bu-attacks-02). Yes, both RR tests could be done only periodically, but the cost of doing them every when refreshing a BCE time is low. No latency is added by the RR tests because is the protocol can be executed well in advance in the background. Finally, if the mobile has a new CoA in every BU and never refreshes without changing the address, HoA RR must nevertheless be done periodically. Again, this prevents bombing attacks against HoA. > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN I have an issue with the introduction of reverse tunnelling. Message 1a requires a major addition to the Home Agent functionality. For all other purposes, the Home Agent is acting as a simple router that forwards packets into an IPIP tunnel. I wonder if the reflection attack is really serious enough to warrant the complexity that is added to the Home Agent by Message 1a. May I suggest an alternative protection: Consider a modification of the above the protocol where Message 1a has been removed. Yes, CN could be used for reflection (and amplification by a factor of 2). In order to discourage the attack, copy the source address of Message 1b into Message 2a. That way, the source address of the attacker is not masked in the reflection and tracing attackers is easier. Tuomas From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 11:37:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25300 for ; Wed, 6 Feb 2002 11:37:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAB05043; Wed, 6 Feb 2002 09:37:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14749; Wed, 6 Feb 2002 08:37:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ga62Q015889 for ; Wed, 6 Feb 2002 08:36:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Ga6Qd015888 for mobile-ip-dist; Wed, 6 Feb 2002 08:36:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Ga12Q015881 for ; Wed, 6 Feb 2002 08:36:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14392 for ; Wed, 6 Feb 2002 08:36:16 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10935 for ; Wed, 6 Feb 2002 09:36:15 -0700 (MST) Received: from jariws1 ([62.248.153.32]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020206163613.THSS24910.fep01-app.kolumbus.fi@jariws1>; Wed, 6 Feb 2002 18:36:13 +0200 Message-ID: <007301c1af2c$6973c0a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: "Jari Arkko" , "Michael Roe" , "Greg O'Shea" , "Pekka Nikander" , References: Subject: Re: [mobile-ip] RE: BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 18:36:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Tuomas for your input! Some further discussion below: > Yes, BSA is needed in order to implement Recommendation 6! Since HoA RR > is > omitted for most BUs, you need some other way of authenticating these > BUs. Otherwise, the attacker could use its own address as the CoA, pass > the > CoA RR test, and send false BU. Yes. I believe we stated something about BSAs being needed for CGA. Are you saying that you want the BSAs also for RR? > When CREATING a BCE, both HoA RR and CoA RR are needed. > When UPDATING a BCE with a new CoA, only CoA RR is needed. > When REFRESHING a BCE without changing the CoA, I suggest testing both > CoA RR and HoA RR every time. > Finally, if the mobile has a new CoA in every BU and never refreshes > without changing the address, HoA RR must nevertheless be done periodically. I think what you suggest is actually quite close to what we were thinking in the recommendation, just that instead of considering these separate cases we simply grouped the above different update actions into one kind of an update, and considered a time limit on the lifetimes. But I have nothing against e.g. doing the HoA test periodically instead of limiting BCE lifetime. You mentioned improved latency as an advantage of the above scheme. Are there other advantages and/or tradeoffs, will there be additional complexity or does this simplify things? > I have an issue with the introduction of reverse tunnelling. Message 1a > requires a major addition to the Home Agent functionality. For all other > purposes, the Home Agent is acting as a simple router that forwards > packets into an IPIP tunnel. With 'major addition', do you refer to reverse tunneling, i.e. forwarding packets also out of an IPIP tunnel? Or did you have something else in mind? The HA is not expected to do anything for the > I wonder if the reflection attack is really serious This is indeed the question. You could say that the reflection attack for the BU authorization protocol is dangerous, if we decide that the HAO is dangerous in general. We haven't gotten to that recommendation yet, though there's been a lengthy discussion on the mailing list. What's your opinion? > That way, the source address of the attacker is > not masked in the reflection and tracing attackers is easier. Yes, this would reveal the attacker's source address. I believe the concern we had about this is what happens after you notice that you are being attacked. With the address in the packet coming towards the victim, we now have a chance to e.g. block it at the ISP router in both methods. However, the blocking is easier if the address is in the IP header directly rather than hidden at an "application layer". There may be some itrace/IPPT differences as well. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 11:39:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25321 for ; Wed, 6 Feb 2002 11:39:11 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26543; Wed, 6 Feb 2002 08:38:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14927; Wed, 6 Feb 2002 08:38:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Gb72Q015918 for ; Wed, 6 Feb 2002 08:37:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Gb7og015917 for mobile-ip-dist; Wed, 6 Feb 2002 08:37:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Gb32Q015910 for ; Wed, 6 Feb 2002 08:37:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24868 for ; Wed, 6 Feb 2002 08:37:18 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09962 for ; Wed, 6 Feb 2002 09:37:16 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g16GbEX4004205 for ; Wed, 6 Feb 2002 17:37:15 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 06 17:37:08 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Feb 2002 17:37:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A9AB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RE: BU Authorization method: design team recommen dation Date: Wed, 6 Feb 2002 17:36:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 1a. MN(HoA)--->HA--->CN > > 1b. MN(CoA)--------->CN > > 2a. CN-------->HA--->MN(HoA) > > 2b. CN-------------->MN(CoA) > > 3. MN(CoA)--------->CN > > I have an issue with the introduction of reverse tunnelling. > Message 1a requires a major addition to the Home Agent > functionality. For all other purposes, the Home Agent is > acting as a simple router that forwards packets into an IPIP > tunnel. I wonder if the reflection attack is really serious > enough to warrant the complexity that is added to the Home > Agent by Message 1a. => This might be a stupid question, but where are the 'major additions' to the HA functionality? You can setup a bidirectional tunnel between the MN and HA immediately after receiving the BU from the MN. From there on reverse tunnelling is pretty straight forward. Where is the complication? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 11:39:38 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25354 for ; Wed, 6 Feb 2002 11:39:37 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18543; Wed, 6 Feb 2002 08:39:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08830; Wed, 6 Feb 2002 07:39:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Fbt2Q015574 for ; Wed, 6 Feb 2002 07:37:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Fbtru015573 for mobile-ip-dist; Wed, 6 Feb 2002 07:37:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Fbq2Q015566 for ; Wed, 6 Feb 2002 07:37:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08580 for ; Wed, 6 Feb 2002 07:38:05 -0800 (PST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06296 for ; Wed, 6 Feb 2002 07:37:44 -0800 (PST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 6 Feb 2002 07:37:29 -0800 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Feb 2002 07:37:43 -0800 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 07:37:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [mobile-ip] RE: BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 07:37:28 -0800 Message-ID: Thread-Topic: BU Authorization method: design team recommendation Thread-Index: AcGtv8HeZUUJAwVzS+eCgc3pxeY72gBWwhfw From: "Tuomas Aura" To: Cc: "Jari Arkko" , "Michael Roe" , "Greg O'Shea" , "Pekka Nikander" X-OriginalArrivalTime: 06 Feb 2002 15:37:29.0008 (UTC) FILETIME=[2F48FB00:01C1AF24] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g16Fbq2Q015567 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Some comments on the recommendations: > (i) Whether or not Binding Security Associations (BSAs) are > used Yes, BSA is needed in order to implement Recommendation 6! Since HoA RR is omitted for most BUs, you need some other way of authenticating these BUs. Otherwise, the attacker could use its own address as the CoA, pass the CoA RR test, and send false BU. > (ii) What addresses need RR tests (HoA, CoA, or both), and > what is the correct time to perform the tests, always > at the time the binding is requested? When CREATING a BCE, both HoA RR and CoA RR are needed. CGA authentication is a plus. (At this time, a BSA can be established either with CGA+DH or by sending the key in plain text in the HoA RR message.) When UPDATING a BCE with a new CoA, only CoA RR is needed. HoA RR before a location change adds unnecessary latency and should be avoided, but read further for an exception. (Without BSA, HoA RR would also be needed to authenticate the BU.) When REFRESHING a BCE without changing the CoA, I suggest testing both CoA RR and HoA RR every time. CoA RR verifies that the mobile really has stayed at CoA. Frequent HoA RR ensures that CN can delete the BCE at any time and when it does, a HoA RR test has been done recently. This prevents bombing attacks against HoA (to be documented in draft-aura-mipv6-bu-attacks-02). Yes, both RR tests could be done only periodically, but the cost of doing them every when refreshing a BCE time is low. No latency is added by the RR tests because is the protocol can be executed well in advance in the background. Finally, if the mobile has a new CoA in every BU and never refreshes without changing the address, HoA RR must nevertheless be done periodically. Again, this prevents bombing attacks against HoA. > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN I have an issue with the introduction of reverse tunnelling. Message 1a requires a major addition to the Home Agent functionality. For all other purposes, the Home Agent is acting as a simple router that forwards packets into an IPIP tunnel. I wonder if the reflection attack is really serious enough to warrant the complexity that is added to the Home Agent by Message 1a. May I suggest an alternative protection: Consider a modification of the above the protocol where Message 1a has been removed. Yes, CN could be used for reflection (and amplification by a factor of 2). In order to discourage the attack, copy the source address of Message 1b into Message 2a. That way, the source address of the attacker is not masked in the reflection and tracing attackers is easier. Tuomas From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 12:11:21 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25926 for ; Wed, 6 Feb 2002 12:11:21 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05419; Wed, 6 Feb 2002 09:08:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04848; Wed, 6 Feb 2002 09:08:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16H7c2Q016112 for ; Wed, 6 Feb 2002 09:07:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16H7cUU016111 for mobile-ip-dist; Wed, 6 Feb 2002 09:07:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16H7Z2Q016104 for ; Wed, 6 Feb 2002 09:07:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18792 for ; Wed, 6 Feb 2002 09:07:49 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14807 for ; Wed, 6 Feb 2002 09:07:49 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Wed, 6 Feb 2002 09:07:35 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Feb 2002 09:07:48 -0800 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 09:07:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] RE: BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 09:07:33 -0800 Message-ID: Thread-Topic: [mobile-ip] RE: BU Authorization method: design team recommendation Thread-Index: AcGvLNM4q6A6kEVuRtmD+IR0d/eQrAAAZGUw From: "Tuomas Aura" To: X-OriginalArrivalTime: 06 Feb 2002 17:07:34.0514 (UTC) FILETIME=[C537BD20:01C1AF30] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g16H7Z2Q016105 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Ok, I agree. Reverse tunnelling is fairly simple if it is provided as a general-purpose mechanism, which MN may use for any purpose. In that case, HA does not need to look into the packet contents or understand what is going on in the (particular version) of BU authentication. I have assumed that since general-purpose reverse tunnelling was not included in MIPv6 design from the beginning, it would not be reasonable to introduce it for the purposes of security. Maybe it was a wrong assumption. (Jari, BTW, the security of reverse tunnelling with the unauthenticated home agents needs more thought.) > => This might be a stupid question, but where > are the 'major additions' to the HA functionality? > > You can setup a bidirectional tunnel between > the MN and HA immediately after receiving the > BU from the MN. From there on reverse > tunnelling is pretty straight forward. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 13:55:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28400 for ; Wed, 6 Feb 2002 13:55:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09684; Wed, 6 Feb 2002 11:54:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12299; Wed, 6 Feb 2002 10:54:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16IrJ2Q016371 for ; Wed, 6 Feb 2002 10:53:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16IrJ8N016370 for mobile-ip-dist; Wed, 6 Feb 2002 10:53:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16IrG2Q016361 for ; Wed, 6 Feb 2002 10:53:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17496 for ; Wed, 6 Feb 2002 10:53:31 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02707 for ; Wed, 6 Feb 2002 11:53:30 -0700 (MST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id TAA12011; Wed, 6 Feb 2002 19:53:29 +0100 (MET) Date: Wed, 6 Feb 2002 19:53:29 +0100 (MET) Message-Id: <200202061853.TAA12011@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com, marcelo@it.uc3m.es, alberto@it.uc3m.es In-reply-to: <200202061448.g16Em2g74698@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Wed, 06 Feb 2002 15:48:02 +0100) Subject: Re: [mobile-ip] draft on random interface identifiers available References: <200202061448.g16Em2g74698@givry.rennes.enst-bretagne.fr> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: One should be aware that there is a public space of IEEE MAC addresses. (See the list which IEEE maintains - http://standards.ieee.org/regauth/oui/oui.txt.) The problem goes much deeper and one should look at the excellent material which Alberto Escudero has pepared on this topic. He is approaching the problem with a stronger requirement, that those who desire privacy should be indistinguishable (statistically) from those who do not. Chip From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 14:44:00 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29658 for ; Wed, 6 Feb 2002 14:44:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20826; Wed, 6 Feb 2002 12:43:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07362; Wed, 6 Feb 2002 11:43:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Jg22Q016568 for ; Wed, 6 Feb 2002 11:42:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16Jg2vI016567 for mobile-ip-dist; Wed, 6 Feb 2002 11:42:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Jfx2Q016560 for ; Wed, 6 Feb 2002 11:41:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06500 for ; Wed, 6 Feb 2002 11:42:13 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20189 for ; Wed, 6 Feb 2002 12:42:12 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 6 Feb 2002 11:42:12 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF46.5F106883" Subject: RE:[CLARIFICATION] [mobile-ip] BU Authorization method: design team recommendation X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 6 Feb 2002 11:42:12 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF143@TNEXVS02.tahoenetworks.com> Thread-Topic: RE:[CLARIFICATION] [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGtv70+NGsrUaY5R7iQD8qk9LMJBABhL6lw From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 06 Feb 2002 19:42:12.0191 (UTC) FILETIME=[5F24E6F0:01C1AF46] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C1AF46.5F106883 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 5. In order to guarantee security of the above exchange, the=20 > HA-MN tunnel should be encrypted for the RR messages (but not=20 > necessarily for other messages on this tunnel). Note that=20 How does exposing the CN-HA link and protecting the HA-MN link guarantee the security of the above exchange ? I am not disagreeing with the proposal here. But I am not clear on the requirement of the need for MN-HA link to be secured in the RR proposal. If I did not protect the MN-HA link, the same attacks that are possible on the CN-HA link are possible on this link also. Am I correct ? So, the idea behind protecting the MN-HA link is to limit the total number of attacks possible. Correct ? Or are there are attacks specific to HA-MN link ? thanks -mohan > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Monday, February 04, 2002 1:01 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] BU Authorization method: design team=20 > recommendation >=20 >=20 > The MIPv6 security design team is trying to resolve the=20 > issues around the method to use for authorizing binding updates. >=20 > This note specifies the design team's motivation and current=20 > position. In order to move forward in an efficient manner it=20 > would be beneficial if responses could make it clear they are > - a clarification (by putting CLARIFICATION: in the Subject > field) > - an issue with a particular point (by ISSUE:) > - disagreement with the conclusion (by CONCLUSION:) >=20 > We would also like folks to state for each of our six=20 > separate recommendations whether they AGREE, CAN TOLERATE, or=20 > DISAGREE with them. In case of DISAGREE, please explain why. >=20 > 1. INTRODUCTION > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > To date, various BU authorization methods have been proposed.=20 > Of the proposals that don't assume a separate infrastructure=20 > the properties they rely on are either RR and/or CGA=20 > properties. An analysis of the security properties of those=20 > general categories of CGA and RR can be found at: >=20 > =20 > http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt >=20 > 2. ALTERNATIVES > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The main alternatives for the actual address ownership=20 > authorization problem are: >=20 > (a) Return Routability, RR > (b) RR enhanced with Cryptographically Generated Addresses, CGA >=20 > The security properties of these methods have been described > in the URL referenced from section 1. In addition, there are=20 > a few additional properties we would like to bring to the > attention: >=20 > - CGA requires additional computational power. It is not > clear though if this is big enough requirement to be an > issue, particularly when very constrained nodes could > refuse RO, and given that it has been demonstrated that > protocols can be designed where MNs and CNs can offload > their expensive computations to their HAs. >=20 > - Several IPR claims have been made regarding CGA. >=20 > In addition to the basic mechanism there are a few additional=20 > issues that we need to decide: >=20 > (i) Whether or not Binding Security Associations (BSAs) are > used >=20 > (ii) What addresses need RR tests (HoA, CoA, or both), and > what is the correct time to perform the tests, always > at the time the binding is requested? >=20 > 3. RECOMMENDATIONS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 1. The design team recommends a mandatory RR mechanism for > IPv6 nodes, but with limitations on how long bindings can=20 > stay alive before they need to be refreshed. This=20 > recommendation is based on the findings of the security=20 > analysis, which point to some deficiences in the RR method=20 > below the "do no harm" principle, to which the limitations=20 > provide a reasonable answer. The RR mechanism should be=20 > placed in the MIPv6 RFC. Given that RR may not be sufficient=20 > in all situations or may need to be replaced later with=20 > something else, we recommend that a secure mechanism for=20 > selecting different BU authorization methods, using the "bit=20 > method" described in the URL referenced from section 1, is=20 > included in this RFC as well. >=20 > 2. The design team additionally recommends an optional CGA=20 > mechanism to be standardized in a separate RFC in the MIPv6=20 > WG, using the above "bit method". This recommendation is=20 > based on the findings of the security analysis, which point=20 > to lesser signaling requirements and improved security=20 > properties of CGA, as well as potential for solving=20 > additional, IPv6 problems. Due to IPR and CPU consumption=20 > concerns it seems problematic to make CGA a mandatory=20 > requirement, however. >=20 > 3. Regarding issue (i), the design team recommends that the=20 > RR method should not use a BSA since we already recommend=20 > both HoA and CoA RR tests to be performed every time a=20 > binding is refreshed or updated with RR. For CGA, the design=20 > team recommends that a (simplified) BSA can be used to store=20 > the Diffie-Hellman value generated as a part of the initial=20 > binding, since with CGA, only the CoA test needs to be=20 > performed on every binding refresh. >=20 > 4. Regarding issue (ii), the design team recommends both CoA=20 > and HoA tests to be performed every time binding is refreshed=20 > or updated with RR. We also recommend additionally that these=20 > tests are made using separate requests in order to avoid=20 > reflection problems with the authorization protocol itself (a=20 > BU authorization request sent from the CoA should not be=20 > answered to the HoA). This essentially leads to a five=20 > message exchange that lasts 1.5 RTTs since because two pairs=20 > of the messages can occur in parallel: >=20 > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN >=20 > 5. In order to guarantee security of the above exchange, the=20 > HA-MN tunnel should be encrypted for the RR messages (but not=20 > necessarily for other messages on this tunnel). Note that=20 > there aren't similar scalability problems with this as there=20 > are with MN-CN security, since the home agents and mobile=20 > nodes must have an existing relationship anyway. This could=20 > be done e.g. using IPsec ESP with pre-shared keys. >=20 > 6. For CGA, the design team recommends that 1a/2a can be=20 > omitted for all but the initial exchange and periodic tests=20 > every few hours or perhaps once a day. >=20 >=20 ------_=_NextPart_001_01C1AF46.5F106883 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE:[CLARIFICATION] [mobile-ip] BU Authorization method: design = team recommendation

> 5. In order to guarantee security of the above = exchange, the
> HA-MN tunnel should be encrypted for the RR = messages (but not
> necessarily for other messages on this tunnel). = Note that

How does exposing the CN-HA link and protecting the = HA-MN link
guarantee the security of the above exchange ? I am = not disagreeing
with the proposal here. But I am not clear on the = requirement of
the need for MN-HA link to be secured in the RR = proposal. If I
did not protect the MN-HA link, the same attacks that = are possible
on the CN-HA link are possible on this link also. Am = I correct ?
So, the idea behind protecting the MN-HA link is to = limit the
total number of attacks possible. Correct ? Or are = there are
attacks specific to HA-MN link ?

thanks
-mohan



> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] =
> Sent: Monday, February 04, 2002 1:01 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] BU Authorization method: = design team
> recommendation
>
>
> The MIPv6 security design team is trying to = resolve the
> issues around the method to use for authorizing = binding updates.
>
> This note specifies the design team's motivation = and current
> position. In order to move forward in an = efficient manner it
> would be beneficial if responses could make it = clear they are
> - a clarification (by putting CLARIFICATION: in = the Subject
>    field)
> - an issue with a particular point (by = ISSUE:)
> - disagreement with the conclusion (by = CONCLUSION:)
>
> We would also like folks to state for each of = our six
> separate recommendations whether they AGREE, CAN = TOLERATE, or
> DISAGREE with them. In case of DISAGREE, please = explain why.
>
> 1. INTRODUCTION
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> To date, various BU authorization methods have = been proposed.
> Of the proposals that don't assume a separate = infrastructure
> the properties they rely on are either RR and/or = CGA
> properties.  An analysis of the security = properties of those
> general categories of CGA and RR can be found = at:
>
>     
> http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt=
>
> 2. ALTERNATIVES
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The main alternatives for the actual address = ownership
> authorization problem are:
>
> (a) Return Routability, RR
> (b) RR enhanced with Cryptographically Generated = Addresses, CGA
>
> The security properties of these methods have = been described
> in the URL referenced from section 1. In = addition, there are
> a few additional properties we would like to = bring to the
> attention:
>
> - CGA requires additional computational power. = It is not
>    clear though if this is big = enough requirement to be an
>    issue, particularly when very = constrained nodes could
>    refuse RO, and given that it = has been demonstrated that
>    protocols can be designed = where MNs and CNs can offload
>    their expensive computations = to their HAs.
>
> - Several IPR claims have been made regarding = CGA.
>
> In addition to the basic mechanism there are a = few additional
> issues that we need to decide:
>
> (i)  Whether or not Binding Security = Associations (BSAs) are
>       used
>
> (ii) What addresses need RR tests (HoA, CoA, or = both), and
>       what is the = correct time to perform the tests, always
>       at the time = the binding is requested?
>
> 3. RECOMMENDATIONS
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> 1. The design team recommends a mandatory RR = mechanism for
> IPv6 nodes, but with limitations on how long = bindings can
> stay alive before they need to be refreshed. = This
> recommendation is based on the findings of the = security
> analysis, which point to some deficiences in the = RR method
> below the "do no harm" principle, to = which the limitations
> provide a reasonable answer. The RR mechanism = should be
> placed in the MIPv6 RFC. Given that RR may not = be sufficient
> in all situations or may need to be replaced = later with
> something else, we recommend that a secure = mechanism for
> selecting different BU authorization methods, = using the "bit
> method" described in the URL referenced = from section 1, is
> included in this RFC as well.
>
> 2. The design team additionally recommends an = optional CGA
> mechanism to be standardized in a separate RFC = in the MIPv6
> WG, using the above "bit method". This = recommendation is
> based on the findings of the security analysis, = which point
> to lesser signaling requirements and improved = security
> properties of CGA, as well as potential for = solving
> additional, IPv6 problems. Due to IPR and CPU = consumption
> concerns it seems problematic to make CGA a = mandatory
> requirement, however.
>
> 3. Regarding issue (i), the design team = recommends that the
> RR method should not use a BSA since we already = recommend
> both HoA and CoA RR tests to be performed every = time a
> binding is refreshed or updated with RR. For = CGA, the design
> team recommends that a (simplified) BSA can be = used to store
> the Diffie-Hellman value generated as a part of = the initial
> binding, since with CGA, only the CoA test needs = to be
> performed on every binding refresh.
>
> 4. Regarding issue (ii), the design team = recommends both CoA
> and HoA tests to be performed every time binding = is refreshed
> or updated with RR. We also recommend = additionally that these
> tests are made using separate requests in order = to avoid
> reflection problems with the authorization = protocol itself (a
> BU authorization request sent from the CoA = should not be
> answered to the HoA). This essentially leads to = a five
> message exchange that lasts 1.5 RTTs since = because two pairs
> of the messages can occur in parallel:
>
> 1a. MN(HoA)--->HA--->CN
> 1b. MN(CoA)--------->CN
> 2a. CN-------->HA--->MN(HoA)
> 2b. CN-------------->MN(CoA)
> 3.  MN(CoA)--------->CN
>
> 5. In order to guarantee security of the above = exchange, the
> HA-MN tunnel should be encrypted for the RR = messages (but not
> necessarily for other messages on this tunnel). = Note that
> there aren't similar scalability problems with = this as there
> are with MN-CN security, since the home agents = and mobile
> nodes must have an existing relationship anyway. = This could
> be done e.g. using IPsec ESP with pre-shared = keys.
>
> 6. For CGA, the design team recommends that = 1a/2a can be
> omitted for all but the initial exchange and = periodic tests
> every few hours or perhaps once a day.
>
>

------_=_NextPart_001_01C1AF46.5F106883-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 15:21:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00432 for ; Wed, 6 Feb 2002 15:21:38 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19849; Wed, 6 Feb 2002 13:21:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11865; Wed, 6 Feb 2002 12:21:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16KJe2Q016668 for ; Wed, 6 Feb 2002 12:19:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16KJeeR016667 for mobile-ip-dist; Wed, 6 Feb 2002 12:19:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16KJa2Q016660 for ; Wed, 6 Feb 2002 12:19:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16515 for ; Wed, 6 Feb 2002 12:19:46 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11920 for ; Wed, 6 Feb 2002 13:19:45 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA06736; Wed, 6 Feb 2002 12:19:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g16KJa723324; Wed, 6 Feb 2002 12:19:36 -0800 X-mProtect:  Wed, 6 Feb 2002 12:19:36 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGRHx2b; Wed, 06 Feb 2002 12:19:33 PST Message-ID: <3C618FD6.F21B7F07@iprg.nokia.com> Date: Wed, 06 Feb 2002 12:19:34 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net CC: basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> <3C5EF68B.4060606@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, first of all, let me commend the design team for their excellent work (the writeup is great). Jari Arkko wrote: > 3. RECOMMENDATIONS > ================== > > 1. The design team recommends a mandatory RR mechanism for > IPv6 nodes, but with limitations on how long bindings can stay > alive before they need to be refreshed. This recommendation is > based on the findings of the security analysis, which point to > some deficiences in the RR method below the "do no harm" > principle, to which the limitations provide a reasonable > answer. The RR mechanism should be placed in the MIPv6 > RFC. AGREE with the above. > Given that RR may not be sufficient in all situations or > may need to be replaced later with something else, we > recommend that a secure mechanism for selecting different BU > authorization methods, using the "bit method" described in the > URL referenced from section 1, is included in this RFC as > well. DISAGREE. As agreed above, RR is the only mandatory protocol that needs to be specified in MIPv6. If there is only one mandatory mechanism, it does not need any specific selection method, eg. the "bit method". I guess we all agree that "a better BU authorization" mechanism is not restricted to CGA alone. Whenever somebody specifies a new "BU authorization mechanism" _they_ need to specify how it is selected over RR. Perhaps, it would be best to avoid any reference to a "better" BU mechanims for now. Having a dependency (in MIPv6 doc) on specifying an extension in the IP address configuration in order to support a mechanism that is not deemed mandatory for MIPv6 is counter-intuitive and would encumber the progress of MIPv6 specification. The specific advantages offered by the "bit method" themselves need discussion elsewhere (i.e., not coupling it with progressing MIPv6 spec). > 2. The design team additionally recommends an optional CGA > mechanism to be standardized in a separate RFC in the MIPv6 > WG, using the above "bit method". This recommendation is based > on the findings of the security analysis, which point to > lesser signaling requirements and improved security properties > of CGA, as well as potential for solving additional, IPv6 > problems. Due to IPR and CPU consumption concerns it seems > problematic to make CGA a mandatory requirement, however. AGREE. and the "bit method" should be specified in this draft. > 3. Regarding issue (i), the design team recommends that the RR > method should not use a BSA since we already recommend both > HoA and CoA RR tests to be performed every time a binding is > refreshed or updated with RR. For CGA, the design team > recommends that a (simplified) BSA can be used to store the > Diffie-Hellman value generated as a part of the initial > binding, since with CGA, only the CoA test needs to be > performed on every binding refresh. CAN TOLERATE (I would have preferred creating BSAs. but I guess that opens up new attacks. so its fine) > 4. Regarding issue (ii), the design team recommends both CoA > and HoA tests to be performed every time binding is refreshed > or updated with RR. We also recommend additionally that these > tests are made using separate requests in order to avoid > reflection problems with the authorization protocol itself (a > BU authorization request sent from the CoA should not be > answered to the HoA). This essentially leads to a five message > exchange that lasts 1.5 RTTs since because two pairs of the > messages can occur in parallel: > > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN AGREE > 5. In order to guarantee security of the above exchange, the > HA-MN tunnel should be encrypted for the RR messages (but not > necessarily for other messages on this tunnel). Note that > there aren't similar scalability problems with this as there > are with MN-CN security, since the home agents and mobile > nodes must have an existing relationship anyway. This could be > done e.g. using IPsec ESP with pre-shared keys. AGREE > 6. For CGA, the design team recommends that 1a/2a can be > omitted for all but the initial exchange and periodic tests > every few hours or perhaps once a day. AGREE. (but lets take up CGA separately). regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 15:21:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00483 for ; Wed, 6 Feb 2002 15:21:55 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24366; Wed, 6 Feb 2002 13:21:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11933; Wed, 6 Feb 2002 12:21:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16KK72Q016678 for ; Wed, 6 Feb 2002 12:20:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16KK7ZP016677 for mobile-ip-dist; Wed, 6 Feb 2002 12:20:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16KK22Q016670 for ; Wed, 6 Feb 2002 12:20:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20152 for ; Wed, 6 Feb 2002 12:20:17 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12141 for ; Wed, 6 Feb 2002 13:20:15 -0700 (MST) Received: from jariws1 ([62.248.153.32]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020206202014.UMWL24910.fep01-app.kolumbus.fi@jariws1> for ; Wed, 6 Feb 2002 22:20:14 +0200 Message-ID: <00e601c1af4b$b5b79580$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF143@TNEXVS02.tahoenetworks.com> Subject: Re: [CLARIFICATION] [mobile-ip] BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 22:20:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: RE: [CLARIFICATION] [mobile-ip] BU Authorization method: design team recommendation>How does exposing the CN-HA link and protecting Content-Transfer-Encoding: 7bit the HA-MN link >guarantee the security of the above exchange ? I am not disagreeing >with the proposal here. But I am not clear on the requirement of >the need for MN-HA link to be secured in the RR proposal. If I >did not protect the MN-HA link, the same attacks that are possible >on the CN-HA link are possible on this link also. Am I correct ? >So, the idea behind protecting the MN-HA link is to limit the >total number of attacks possible. Correct ? Or are there are >attacks specific to HA-MN link ? Yes, the idea is to limit the attackers to those who are on the HA-CN path. (Besides, security for the HA-CN path would be hard or impossible to get anyway.) Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 15:37:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01160 for ; Wed, 6 Feb 2002 15:37:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18064; Wed, 6 Feb 2002 13:36:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16858; Wed, 6 Feb 2002 12:36:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16KZ22Q016809 for ; Wed, 6 Feb 2002 12:35:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16KZ2Zn016808 for mobile-ip-dist; Wed, 6 Feb 2002 12:35:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16KYw2Q016801 for ; Wed, 6 Feb 2002 12:34:58 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17188 for ; Wed, 6 Feb 2002 12:35:12 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20404 for ; Wed, 6 Feb 2002 12:35:11 -0800 (PST) Received: from jariws1 ([62.248.153.32]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020206203509.UOSK24910.fep01-app.kolumbus.fi@jariws1>; Wed, 6 Feb 2002 22:35:09 +0200 Message-ID: <00f401c1af4d$cb0612c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Vijay Devarapalli" Cc: , References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> <3C5EF68B.4060606@piuha.net> <3C618FD6.F21B7F07@iprg.nokia.com> Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Wed, 6 Feb 2002 22:35:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Vijay for your comments! I'll comment briefly the one point where you had DISAGREE: > I guess we all agree that "a better BU authorization" > mechanism is not restricted to CGA alone. Agreed. > Whenever somebody > specifies a new "BU authorization mechanism" _they_ need to > specify how it is selected over RR. Perhaps, it would be best > to avoid any reference to a "better" BU mechanims for now. Ah, I can see now that you just want the bit method moved from one place to another. This would be logical, but I think what we worried about was bidding-down attacks. Basically, since we are not assuming any sort of global trust or pre-established knowledge, it's pretty hard to know if the the RR request came from a real node or the man in the middle. Thus, it seems security-wise very useful or maybe even necessary to know from the addresses what to do. Otherwise, once deployed RR mechanism might not be possible to be upgraded anymore, since the resulting security in any case be RR. Of course, if you can come up with suggestions in this space we could discuss them. [One idea originally presented by Henrik Petander was also floated in the design team that you could in theory use the bit method to have two sets of nodes: All RR MNs, and the union of all CGA MNs and stationary nodes. Thus, it would be evident that BU authorization can't be tricked to move communications of stationary nodes. I'm not sure yet if that would work, but it's an idea.] Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 17:07:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03987 for ; Wed, 6 Feb 2002 17:07:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02336; Wed, 6 Feb 2002 15:06:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06472; Wed, 6 Feb 2002 14:06:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16M592Q017095 for ; Wed, 6 Feb 2002 14:05:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16M59wJ017094 for mobile-ip-dist; Wed, 6 Feb 2002 14:05:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16M572Q017087 for ; Wed, 6 Feb 2002 14:05:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19313 for ; Wed, 6 Feb 2002 17:05:22 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA21502 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Feb 2002 17:06:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16GOv2Q015847 for ; Wed, 6 Feb 2002 08:24:57 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09865 for ; Wed, 6 Feb 2002 08:25:11 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02086 for ; Wed, 6 Feb 2002 08:25:03 -0800 (PST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id EB1F24327E; Wed, 6 Feb 2002 17:25:00 +0100 (CET) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp02.uc3m.es (Postfix) with SMTP id 9B95099E7A; Wed, 6 Feb 2002 17:24:59 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: , "Erik Nordmark" Cc: , , "Ignacio Soto" Subject: RE: [mobile-ip] draft on random interface identifiers available Date: Wed, 6 Feb 2002 17:22:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200202061525.g16FPQg74926@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Well, in my opinion, the relevant point in this discussion is the following: In the MIPv6 draft it has been pointed out that "After forming a new care-of address, a mobile node MAY perform Duplicate Address Detection [27] on that new address to confirm its uniqueness. However, doing so represents a tradeoff between safety (ensuring that the new address is not used if it is a duplicate address) and overhead..." What I would like to know from the mobile IP working group is if the benefit from avoiding the interruption of the communication after a handover caused by DAD pays for the possibility of address collision (with a computed probability of 6 users out of 1.000.000.000 affected in a year by an address collision if all of them perform 140 handovers per day in networks containing 500 interfaces). If this probability is yet considered too high, then I wonder if the tradeoff stated in the MIPv6 draft is a strong one. Regarding to the globaly unique vs. probably unique discussion, I agree in general, but I do not know if this topic is enough close in time for waiting for it. Additionally, I think that it raises some privacy concerns that could be problematic for obtaining consensus. Regards > -----Mensaje original----- > De: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Enviado el: miércoles, 06 de febrero de 2002 16:25 > Para: Erik Nordmark > CC: mobile-ip@sunroof.eng.sun.com; marcelo@it.uc3m.es; > alberto@it.uc3m.es > Asunto: Re: [mobile-ip] draft on random interface identifiers available > > > In your previous mail you wrote: > > This is an IPv6 WG topic - why don't we move it there? > > => I agree! > > > => in fact there is no real difference between to perform after > > or to avoid: if there is a duplicate you are simply dead... > > Question is who and how many are dead. > If one node has been around communicating for a while and a new node > appears that has a duplicate address with the first we can > choose between: > 1. Have both be disrupted - presumably to the extent they can pick > new addresses they will both need to do so. > > => without DAD the result is #1, in general they are so disrupted than > at least one picks a new address and the situation recovers after > some timeouts (short timeouts in IPv6 because of NUD). > > 2. Have one be disrupted > a. Have the new guy be disrupted > b. Have the old node be disrupted > > Only if you think #1 makes sense it is true that after vs. before makes > no difference. > But Duplicate Address Detection as defined does 2a. > > => 2a is the best solution so DAD is good. I never got it in a real > situation for IPv4 when there is no DAD, in general the result is #1 > and sometimes 2b (simply because there is someone who looks at > what happens). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I don't want a new DAD or not DAD discussion. I prefer a globally > unique vs. probably unique one with who should do the choice/where should > be the control, etc. I.e. more operational topics, DAD is an operational > tool, its theoretical aspect is no more than the birthday paradox (i.e. > IMHO has no interest). > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 17:09:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04028 for ; Wed, 6 Feb 2002 17:09:11 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20093; Wed, 6 Feb 2002 14:08:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07083; Wed, 6 Feb 2002 14:08:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16M7A2Q017176 for ; Wed, 6 Feb 2002 14:07:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16M7AN0017175 for mobile-ip-dist; Wed, 6 Feb 2002 14:07:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16M782Q017165 for ; Wed, 6 Feb 2002 14:07:08 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23833 for ; Wed, 6 Feb 2002 17:07:23 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA21519 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Feb 2002 17:08:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16Gfl2Q016047 for ; Wed, 6 Feb 2002 08:41:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15766 for ; Wed, 6 Feb 2002 08:42:02 -0800 (PST) Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15182 for ; Wed, 6 Feb 2002 09:41:59 -0700 (MST) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id C968943321; Wed, 6 Feb 2002 17:41:56 +0100 (CET) Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) by smtp02.uc3m.es (Postfix) with SMTP id 9BBBA99E7F; Wed, 6 Feb 2002 17:41:55 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "Erik Nordmark" , Cc: , Subject: RE: [mobile-ip] draft on random interface identifiers available Date: Wed, 6 Feb 2002 17:38:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > -----Mensaje original----- > De: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Enviado el: miércoles, 06 de febrero de 2002 15:35 > Para: Francis.Dupont@enst-bretagne.fr > CC: mobile-ip@sunroof.eng.sun.com; marcelo@it.uc3m.es; > alberto@it.uc3m.es > Asunto: Re: [mobile-ip] draft on random interface identifiers available > > > > This is an IPv6 WG topic - why don't we move it there? > > > > => in fact there is no real difference between to perform after > > or to avoid: if there is a duplicate you are simply dead... > > Question is who and how many are dead. > If one node has been around communicating for a while and a new node > appears that has a duplicate address with the first we can choose between: > 1. Have both be disrupted - presumably to the extent they can pick > new addresses they will both need to do so. > 2. Have one be disrupted > a. Have the new guy be disrupted > b. Have the old node be disrupted > If the question is how many are affected, perhaps we could also consider that when you do perform DAD, all the mobile hosts in every handover always suffer interruptions in their communication, while in the other case, only the two that collide are affected. It is also true that when you perform DAD only the mobile hosts suffer the interruption, while not performing DAD can also affect the fixed hosts on the network. What's the best option? By the way, your comment suggests that DAD should be performed at least after the handover, in order to recover the connection correponding to the oldest host in the network, in order to reduce the damage of address collision. However, the fact that both hosts are affected by not performing DAD was included in the probability estimation. Regards > Only if you think #1 makes sense it is true that after vs. before makes > no difference. > But Duplicate Address Detection as defined does 2a. > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 17:15:38 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04135 for ; Wed, 6 Feb 2002 17:15:36 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21584; Wed, 6 Feb 2002 14:15:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09018; Wed, 6 Feb 2002 14:15:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16ME02Q017639 for ; Wed, 6 Feb 2002 14:14:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16ME0eE017638 for mobile-ip-dist; Wed, 6 Feb 2002 14:14:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16MDv2Q017631 for ; Wed, 6 Feb 2002 14:13:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15640 for ; Wed, 6 Feb 2002 14:14:12 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27483 for ; Wed, 6 Feb 2002 14:14:12 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g16MEAU08012; Wed, 6 Feb 2002 16:14:10 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MB47Y7T>; Wed, 6 Feb 2002 16:14:09 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01E2D80B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: Charlie Perkins , Erik Nordmark Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Wed, 6 Feb 2002 16:14:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF5B.95A6DCF0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF5B.95A6DCF0 Content-Type: text/plain; charset="iso-8859-1" Jari, I am very relieved to hear that you agree that the overhead is a waste. I hope others can see this as well and we can find an acceptable way to get rid of the overhead as a team for MIPv6. Getting people to realize this was the intent of the ID. The draft was trying to emulate existing precedent IDs related to tunneling that did not specify such signaling specifics. These precedent IDs also gave rough topolical deployment examples. This was the reason for the generalized mode and the avoidance of signaling specific scope. I do see that there have been other IDs that say "use this generic tunneling mechanisms with this signaling" but we had to have the reference to the generic method 1st. If the WG can agree that the overhead is a waste and pick one of the end to end alternatives: - ZOD (relies solely on end to end fate sharing principle) (not as robust as overhead-based methods) - More Robust ZOD (as robust as the overhead-based methods) - flow label bit - traffic class bit If one of these are chosen we just need to pick one of the bits. Then I will certainly volunteer to write a more formal and exact ID that is MIPv6 signaling specific; though, I think that Charlie would probably do a better job of just incorporating the change into the existing MIPv6 spec and we can just let the existing ZOD ID expire. It will have served its purpose at that point. The reasoning can be captured in the MIPv6 spec, itself, for prosperity's sake. I also wouldn't mind if someone else wanted to author a more specific ID. If not, then I do not see much use in going through the effort of another ID. There are other issues that need attention, too. I think I have contributed enough on this topic and in sufficient detail to convey the information at this time. Thanks again, Glenn ------_=_NextPart_001_01C1AF5B.95A6DCF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team = recommendation

Jari,

I am very relieved to hear that you agree that the = overhead is a waste. I hope others can see this as well and we can find = an acceptable way to get rid of the overhead as a team for MIPv6. = Getting people to realize this was the intent of the ID.

The draft was trying to emulate existing precedent = IDs related to tunneling that did not specify such signaling specifics. = These precedent IDs also gave rough topolical deployment examples. This = was the reason for the generalized mode and the avoidance of signaling = specific scope. I do see that there have been other IDs that say = "use this generic tunneling mechanisms with this signaling" = but we had to have the reference to the generic method 1st.

If the WG can agree that the overhead is a waste and = pick one of the end to end alternatives:

- ZOD
    (relies solely on end to end fate = sharing principle)
    (not as robust as overhead-based = methods)

- More Robust ZOD  (as robust as the = overhead-based methods)
   - flow label bit
   - traffic class bit
   If one of these are chosen we just need = to pick one of the bits.

Then I will certainly volunteer to write a more = formal and exact ID that is MIPv6 signaling specific; though, I think = that Charlie would probably do a better job of just incorporating the = change into the existing MIPv6 spec and we can just let the existing = ZOD ID expire. It will have served its purpose at that point. The = reasoning can be captured in the MIPv6 spec, itself, for prosperity's = sake. I also wouldn't mind if someone else wanted to author a more = specific ID.

If not, then I do not see much use in going through = the effort of another ID. There are other issues that need attention, = too. I think I have contributed enough on this topic and in sufficient = detail to convey the information at this time.

Thanks again,

Glenn

 

------_=_NextPart_001_01C1AF5B.95A6DCF0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 17:31:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04409 for ; Wed, 6 Feb 2002 17:31:34 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14413; Wed, 6 Feb 2002 15:31:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12898; Wed, 6 Feb 2002 14:31:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16MTU2Q017829 for ; Wed, 6 Feb 2002 14:29:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g16MTUMO017828 for mobile-ip-dist; Wed, 6 Feb 2002 14:29:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16MTS2Q017821 for ; Wed, 6 Feb 2002 14:29:29 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24382 for ; Wed, 6 Feb 2002 17:29:43 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA21595 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Feb 2002 17:30:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16HxC2Q016230 for ; Wed, 6 Feb 2002 09:59:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27813 for ; Wed, 6 Feb 2002 09:59:27 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08863 for ; Wed, 6 Feb 2002 10:59:27 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 01BBC3AEB for ; Wed, 6 Feb 2002 11:59:27 -0600 (CST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E9D731582 for ; Wed, 6 Feb 2002 11:59:24 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g16HxOq31883; Wed, 6 Feb 2002 12:59:24 -0500 (EST) Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g16HxB115105; Wed, 6 Feb 2002 12:59:11 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA12449; Wed, 6 Feb 2002 12:59:00 -0500 Message-Id: <200202061759.AA12449@dogbert.zk3.dec.com> From: Brian.Haley@compaq.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: BU Authorization method: design team recommendation Date: Wed, 06 Feb 2002 12:59:00 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Tuomas Aura wrote: > I have assumed that since general-purpose reverse > tunnelling was not included in MIPv6 design from the > beginning, it would not be reasonable to introduce it for > the purposes of security. Maybe it was a wrong assumption. The MIPv6 draft does cover reverse tunneled packets: 9.5. Handling Reverse Tunneled Packets from a Mobile Node A home agent MUST support decapsulating reverse tunneled packets sent to it from a mobile node's home address. Such reverse tunneled packets MAY be discarded unless accompanied by a valid AH or ESP header. This support for reverse tunneling allows mobile nodes to defeat certain kinds of traffic analysis. Requiring IPsec headers on reverse tunneled packets allows the home agent to protect the home network against unwarranted intrusions by malicious nodes masquerading as a mobile node with a home address on the network served by the home agent. Of course I'm curious now why it says "from a mobile node's home address", I would have assumed the packet would be from the care-of address for ingress-filtering reasons. Maybe I'll have to start another thread to ask about that... -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 20:35:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06462 for ; Wed, 6 Feb 2002 20:35:56 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03978; Wed, 6 Feb 2002 18:35:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14073; Wed, 6 Feb 2002 17:35:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g171Y22Q018434 for ; Wed, 6 Feb 2002 17:34:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g171Y1rE018433 for mobile-ip-dist; Wed, 6 Feb 2002 17:34:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g171Xw2Q018426 for ; Wed, 6 Feb 2002 17:33:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27290 for ; Wed, 6 Feb 2002 17:34:14 -0800 (PST) Received: from mailcity.com (fes.whowhere.com [209.185.123.154]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA15893 for ; Wed, 6 Feb 2002 18:34:13 -0700 (MST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Feb 6 17:34:00 2002 To: mobile-ip@sunroof.eng.sun.com Date: Thu, 07 Feb 2002 07:04:00 +0530 From: "Srinivasan" Message-ID: Mime-Version: 1.0 Content-Language: en X-Sent-Mail: on X-Mailer: MailCity Service Subject: [mobile-ip] [Mobile IP] MN performing Address resolution on returning home. X-Priority: 3 X-Sender-Ip: 165.213.0.2 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is regarding the mobile node performing Address Resolution on Returning Home, for determining the link-layer address of its Home agent to send a Binding Update. Under section 10.20 of Mobility Support in IPv6 draft , it has been quoted as follows "If the mobile node does Neighbor Solicitation to learn the home agent's link-layer address, in this special case of the mobile node returning home, the mobile node MUST unicast the packet, and in addition set the Source Address of this Neighbor Solicitation to the unspecified address (0:0:0:0:0:0:0:0). Since the solicitation is unicast, the home agent will be able to distinguish from a similar packet that would only be used for DAD. " My doubts are: 1. Is it possible to send a neighbor soliciation using unicast address when u don't know targets link-layer address. 2. If MN uses unicast address of HA as destination address, and sends somehow the packet to HA. When HA sends the Neighbor advertisement, HA MAY omit the target link-layer address option. This is specified in RFC 2461. Then how do I know the link-layer address of HA. Any pointers please. Thanks in advance, srinivasan From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 6 21:43:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08769 for ; Wed, 6 Feb 2002 21:43:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07978; Wed, 6 Feb 2002 19:43:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14228; Wed, 6 Feb 2002 18:42:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g172fa2Q018509 for ; Wed, 6 Feb 2002 18:41:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g172faAx018508 for mobile-ip-dist; Wed, 6 Feb 2002 18:41:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g172fR2Q018501 for ; Wed, 6 Feb 2002 18:41:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02657 for ; Wed, 6 Feb 2002 18:41:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08522 for ; Wed, 6 Feb 2002 18:41:23 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA02054; Wed, 6 Feb 2002 18:41:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g172fLv14516; Wed, 6 Feb 2002 18:41:21 -0800 X-mProtect:  Wed, 6 Feb 2002 18:41:21 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdslyobA; Wed, 06 Feb 2002 18:41:20 PST Message-ID: <3C61E950.C373C55F@iprg.nokia.com> Date: Wed, 06 Feb 2002 18:41:20 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> <3C5EF68B.4060606@piuha.net> <3C618FD6.F21B7F07@iprg.nokia.com> <00f401c1af4d$cb0612c0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jari, four comments.... Jari Arkko wrote: > > Whenever somebody > > specifies a new "BU authorization mechanism" _they_ need to > > specify how it is selected over RR. Perhaps, it would be best > > to avoid any reference to a "better" BU mechanims for now. > > Ah, I can see now that you just want the bit method moved from > one place to another. This would be logical, but I think what > we worried about was bidding-down attacks. Basically, since > we are not assuming any sort of global trust or pre-established > knowledge, it's pretty hard to know if the the RR request came > from a real node or the man in the middle. Thus, it seems security-wise > very useful or maybe even necessary to know from the addresses > what to do. Otherwise, once deployed RR mechanism might not be possible > to be upgraded anymore, since the resulting security in any case > be RR. 1. The "1 bit method" seems to be designed with CGA as the only possible strong authorization mechanism for securing BUs. However you have also agreed that other strong BU authorization solutions are possible in the future. Has the design team looked at other signaling mechanisms to indicate the preferred mechanism by an MN or CN? Section 8 in Residual_Threats.txt does not have enough info as to why you chose the "bit method" over the other methods. 2. Also, please let us know what other RFCs (other dependencies) need to be changed to have this 1 bit in the IPv6 address? 3. Assume, I have more than 2 mechanisms for BU authorization (RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here? For this, (IMO) the obvious thing would be a set of bits in the Binding Update. You dont have to specify this now. We can do this later using the reserved bits in the BU. 4. The following is from Residual_Threats.txt > - A mechanism for the MN to indicate on-line that it wants to > use CGA and not RR. This assumes the RR attacker can't > prevent the MN from seeing the RR packets. This, however, > seems hard given that the attacker is on the CN-HA path. > I tried really hard to figure out why the above mechanism is inferior to the "1 bit" method. If the RR attacker prevents the MN from seeing the RR packets, then you have RR itself failing. If RR fails, CGA also fails. Am I missing something very obvious? regards Vijay > Of course, if you can come up with suggestions in this space > we could discuss them. > > [One idea originally presented by Henrik Petander was also floated > in the design team that you could in theory use the bit method to have > two sets of nodes: All RR MNs, and the union of all CGA MNs and > stationary nodes. Thus, it would be evident that BU authorization > can't be tricked to move communications of stationary nodes. > I'm not sure yet if that would work, but it's an idea.] > > Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 03:31:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22501 for ; Thu, 7 Feb 2002 03:31:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03941; Thu, 7 Feb 2002 01:30:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17340; Thu, 7 Feb 2002 00:30:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g178TK2Q019030 for ; Thu, 7 Feb 2002 00:29:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g178TKwB019029 for mobile-ip-dist; Thu, 7 Feb 2002 00:29:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g178TG2Q019022 for ; Thu, 7 Feb 2002 00:29:16 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g178TRM12252; Thu, 7 Feb 2002 09:29:28 +0100 (MET) Date: Thu, 7 Feb 2002 09:25:31 +0100 (CET) From: Erik Nordmark Subject: RE:[CLARIFICATION] [mobile-ip] BU Authorization method: design team recommendation To: mohanp@tahoenetworks.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <416B5AF360DED54088DAD3CA8BFBEA6E1DF143@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 5. In order to guarantee security of the above exchange, the > > HA-MN tunnel should be encrypted for the RR messages (but not > > necessarily for other messages on this tunnel). Note that > > How does exposing the CN-HA link and protecting the HA-MN link > guarantee the security of the above exchange ? I am not disagreeing > with the proposal here. But I am not clear on the requirement of > the need for MN-HA link to be secured in the RR proposal. If I > did not protect the MN-HA link, the same attacks that are possible > on the CN-HA link are possible on this link also. Am I correct ? > So, the idea behind protecting the MN-HA link is to limit the > total number of attacks possible. Correct ? Or are there are > attacks specific to HA-MN link ? Mohan, The wording above is far from correct as you observe. The intent was to say something more like In order to minimize the exposure by preventing attacks on the path between the HA and MN, ... There aren't any specific attacks on the HA-MN link - it is just a question whether the attacker is on-path or off-path. By protecting the HA-MN part of the path even on-path attackers on that part of the path can't cause anything but DoS (by dropping packets). Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 04:32:17 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23434 for ; Thu, 7 Feb 2002 04:32:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14241; Thu, 7 Feb 2002 02:31:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06321; Thu, 7 Feb 2002 01:31:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g179Uc2Q019162 for ; Thu, 7 Feb 2002 01:30:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g179Ubuh019161 for mobile-ip-dist; Thu, 7 Feb 2002 01:30:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g179UY2Q019154 for ; Thu, 7 Feb 2002 01:30:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24037 for ; Thu, 7 Feb 2002 01:30:49 -0800 (PST) Received: from disys.korea.ac.kr (disys.korea.ac.kr [163.152.39.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13793 for ; Thu, 7 Feb 2002 02:30:48 -0700 (MST) Received: from rickhan ([163.152.45.70]) by disys.korea.ac.kr (8.12.1/8.12.1) with SMTP id g179Qglr017823 for ; Thu, 7 Feb 2002 18:26:42 +0900 (KST) Message-ID: <005d01c1afba$2fed1910$462d98a3@disys42.korea.ac.kr> From: "Youn-Hee Han" To: Subject: [mobile-ip] Valid Period of Home Address? Date: Thu, 7 Feb 2002 18:31:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g179UZ2Q019155 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Before I read the MIPv6 draft, I believed the followings "After the MN acquires a home address, the home address is fixed at the MN and is permanent." That is, I have assured that the home address of a MN becomes the identifier of the MN. In many places in the MIPv6 draft, however, I can find that the eternity of home address is not true. Of course, the home network renumbering and the initial address configuration cause the home address to be configured by using 'ICMP Mobile Prefix Solicitation'. But, the ICMP message is also used in order to refresh home addresses before the expiration of their validity. Also, I think that the Duplicate Address Detection is also another evidence of the short-lived of home address. If the home address is not permanent. I am worried about the followings. 1. If the home address is changed, how does a correspondent node open any TCP connection with the MN after the changes? 2. We cannot find any terms about the valid period of home address. Is the period depended of an implementation? I admit that any temporary home address should be used in some cases. However, the temporary home address is conflict with the following goal of Mobile IP. "Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet" Thanks in advance. Best regards, From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 04:50:02 2002 Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23686 for ; Thu, 7 Feb 2002 04:50:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28243; Thu, 7 Feb 2002 02:49:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24300; Thu, 7 Feb 2002 01:41:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g179eV2Q019214 for ; Thu, 7 Feb 2002 01:40:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g179eVeh019213 for mobile-ip-dist; Thu, 7 Feb 2002 01:40:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g179eR2Q019206 for ; Thu, 7 Feb 2002 01:40:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24152 for ; Thu, 7 Feb 2002 01:40:42 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA22237 for ; Thu, 7 Feb 2002 02:40:41 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA02282 for ; Thu, 7 Feb 2002 02:40:41 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA16617 for ; Thu, 7 Feb 2002 02:40:40 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 7 Feb 2002 03:40:28 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 27A722EC83; Thu, 7 Feb 2002 10:35:51 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: , "Erik Nordmark" , , "Ignacio Soto" Subject: Re: [mobile-ip] draft on random interface identifiers available References: From: Alexandru Petrescu Date: 07 Feb 2002 10:40:34 +0100 In-Reply-To: Message-Id: Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g179eS2Q019207 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Alberto and thanks for this reflection. I have a tangent remark with respect to numbers, please take it as my own personal view. Alberto García writes: > What I would like to know from the mobile IP working group is if the benefit > from avoiding the interruption of the communication after a handover caused > by DAD pays for the possibility of address collision (with a computed > probability of 6 users out of 1.000.000.000 affected in a year by an address > collision if all of them perform 140 handovers per day in networks > containing 500 interfaces). This argument looks so compelling, probability results say indeed a lot. To be even more convincing, I think it should take into consideration at least one other factor: 30% of the users employ a widespread implementation of this random generator. With this in mind, how much should one rely on the _corectness_ of the respective implementation comparing to how much one relies on the corectness of probability results. Please note that I don't question in any way the text in the draft, people certainly had reasons when they put it there. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 07:31:37 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25544 for ; Thu, 7 Feb 2002 07:31:37 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21312; Thu, 7 Feb 2002 05:31:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05552; Thu, 7 Feb 2002 04:30:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17CTT2Q019632 for ; Thu, 7 Feb 2002 04:29:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17CTTjk019631 for mobile-ip-dist; Thu, 7 Feb 2002 04:29:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17CTP2Q019624 for ; Thu, 7 Feb 2002 04:29:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18089 for ; Thu, 7 Feb 2002 04:29:40 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14100 for ; Thu, 7 Feb 2002 05:29:39 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g17CTbC08273 for ; Thu, 7 Feb 2002 13:29:38 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Feb 07 13:29:36 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 13:20:14 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D789@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark Subject: RE: [mobile-ip] bit method and u/l bit (Was: BU Authorization met hod: design team recommendation) Date: Thu, 7 Feb 2002 13:29:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alex > IEEE EUI-64 being a superset of IEEE 802 is still not all potential > types of L2's under IPv6. I bet that most SDO's > developping L2's for > current telecom trends will not ask IEEE how to generate their ID's > simply because their vision of a network is different. => As far as 'telecom' L2s are concerned (cellular) there is no concept of MAC address. These are p2p links. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 07:32:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25568 for ; Thu, 7 Feb 2002 07:32:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10538; Thu, 7 Feb 2002 04:31:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05709; Thu, 7 Feb 2002 04:31:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17CTO2Q019622 for ; Thu, 7 Feb 2002 04:29:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17CTOv1019621 for mobile-ip-dist; Thu, 7 Feb 2002 04:29:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17CTL2Q019614 for ; Thu, 7 Feb 2002 04:29:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18075 for ; Thu, 7 Feb 2002 04:29:35 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20771 for ; Thu, 7 Feb 2002 05:29:34 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g17CTXX4016462 for ; Thu, 7 Feb 2002 13:29:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Feb 07 13:29:33 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 13:29:32 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D78B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RE: BU Authorization method: design team recommen dation Date: Thu, 7 Feb 2002 13:29:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I have assumed that since general-purpose reverse > tunnelling was not included in MIPv6 design from the > beginning, it would not be reasonable to introduce it for > the purposes of security. Maybe it was a wrong assumption. => It was mentioned in one of the earlier revisions, I haven't looked at the latest draft though. It's just the MN's decision anyway so there isn't much to be said. HAs should always setup bidirectional tunnels after BU reception. I think FreeBSD does it be default. > > (Jari, BTW, the security of reverse tunnelling with the > unauthenticated home agents needs more thought.) => What do you mean by 'unauthenticated HA'? Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 08:10:28 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25932 for ; Thu, 7 Feb 2002 08:10:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16771; Thu, 7 Feb 2002 05:09:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13150; Thu, 7 Feb 2002 05:09:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17D8k2Q019942 for ; Thu, 7 Feb 2002 05:08:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17D8kmb019941 for mobile-ip-dist; Thu, 7 Feb 2002 05:08:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17D8h2Q019934 for ; Thu, 7 Feb 2002 05:08:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16191 for ; Thu, 7 Feb 2002 05:08:58 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04903 for ; Thu, 7 Feb 2002 06:08:57 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA02716 for ; Thu, 7 Feb 2002 06:08:57 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id FAA26842 for ; Thu, 7 Feb 2002 05:57:41 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Thu, 7 Feb 2002 07:08:55 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 444BB2EC83; Thu, 7 Feb 2002 14:04:09 +0100 (CET) To: hesham.soliman@era.ericsson.se Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] bit method and u/l bit (Was: BU Authorization met hod: design team recommendation) References: <4DA6EA82906FD511BE2F00508BCF053802D4D789@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 07 Feb 2002 14:08:52 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802D4D789@Esealnt861.al.sw.ericsson.se> Message-Id: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, "Hesham Soliman (ERA)" writes: > Alex > > > IEEE EUI-64 being a superset of IEEE 802 is still not all potential > > types of L2's under IPv6. I bet that most SDO's > > developping L2's for > > current telecom trends will not ask IEEE how to generate their ID's > > simply because their vision of a network is different. > > => As far as 'telecom' L2s are concerned (cellular) > there is no concept of MAC address. These are > p2p links. Sure. That's what I was saying too, different visions. Having looked a bit into how to run IP over wCDMA I remember being very much tempted to make those channels looking more like "multi-access" to IP. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:00:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26705 for ; Thu, 7 Feb 2002 09:00:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12058; Thu, 7 Feb 2002 06:59:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29624; Thu, 7 Feb 2002 05:56:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17DtE2Q020199 for ; Thu, 7 Feb 2002 05:55:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17DtEmi020198 for mobile-ip-dist; Thu, 7 Feb 2002 05:55:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Dt92Q020191 for ; Thu, 7 Feb 2002 05:55:10 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g17DtLM19630; Thu, 7 Feb 2002 14:55:21 +0100 (MET) Date: Thu, 7 Feb 2002 14:51:24 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RE: BU Authorization method: design team recommendation To: tuomaura@microsoft.com Cc: mobile-ip@sunroof.eng.sun.com, Jari Arkko , Michael Roe , "Greg O'Shea" , Pekka Nikander In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 1a. MN(HoA)--->HA--->CN > > 1b. MN(CoA)--------->CN > > 2a. CN-------->HA--->MN(HoA) > > 2b. CN-------------->MN(CoA) > > 3. MN(CoA)--------->CN > > I have an issue with the introduction of reverse tunnelling. Message 1a > requires a major addition to the Home Agent functionality. For all other > purposes, the Home Agent is acting as a simple router that forwards > packets > into an IPIP tunnel. I wonder if the reflection attack is really serious > enough to warrant the complexity that is added to the Home Agent by > Message 1a. Tuomas, For 1a the HA is also just a router that forwards packets - in this case from an IP-in-IP tunnel out on some other interface. Is your point that we shouldn't mandate support for reverse tunneling in the HA or is there another point that am I missing? I think HAs need to support reverse tunneling in general - e.g. in order to deal with multicast packets sourced from the HoA, in order to allow MNs not to disclose their current CoA to some CNs, etc. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:07:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27041 for ; Thu, 7 Feb 2002 09:07:54 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16012; Thu, 7 Feb 2002 07:07:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01242; Thu, 7 Feb 2002 06:07:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17E6S2Q020252 for ; Thu, 7 Feb 2002 06:06:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17E6STO020251 for mobile-ip-dist; Thu, 7 Feb 2002 06:06:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17E6O2Q020244 for ; Thu, 7 Feb 2002 06:06:24 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g17E6aM21003; Thu, 7 Feb 2002 15:06:36 +0100 (MET) Date: Thu, 7 Feb 2002 15:02:39 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: vijayd@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net, basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <3C618FD6.F21B7F07@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > As agreed above, RR is the only mandatory protocol that > needs to be specified in MIPv6. If there is only one > mandatory mechanism, it does not need any specific > selection method, eg. the "bit method". > > I guess we all agree that "a better BU authorization" > mechanism is not restricted to CGA alone. Whenever somebody > specifies a new "BU authorization mechanism" _they_ need to > specify how it is selected over RR. Perhaps, it would be best > to avoid any reference to a "better" BU mechanims for now. > > Having a dependency (in MIPv6 doc) on specifying an > extension in the IP address configuration in order to > support a mechanism that is not deemed mandatory for MIPv6 > is counter-intuitive and would encumber the progress of > MIPv6 specification. > > The specific advantages offered by the "bit method" > themselves need discussion elsewhere (i.e., not coupling > it with progressing MIPv6 spec). Vijay, We haven't managed to come up with a scheme where CGA can be completely(*) added later without opening up a "beating down" attack where an attacker on path between CN and HA could 1) claim to be the MN and 2) cause the CN to accept a BU protected by just RR. Thus the idea (which perhaps isn't written up that well) is to do two things initially: 1) get a bit (or pattern of bits) in the low order 64 bits of IPv6 addresses marked as reserved. 2) have the MIPv6 specification say that when the HoA bottom 64 bits has this reserved bit/pattern then it MUST NOT accept a BU protected by RR. If we can do the above, and only the above, then we can later add CGA (or something else more secure that RR) by having the MNs who wish to require the more secure scheme set the bit/pattern in their home address. Does the above description make more sense than what is in the writeup? Does is make you change your mind? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:18:45 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27600 for ; Thu, 7 Feb 2002 09:18:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00563; Thu, 7 Feb 2002 06:17:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02540; Thu, 7 Feb 2002 06:17:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EGL2Q020306 for ; Thu, 7 Feb 2002 06:16:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17EGLLA020305 for mobile-ip-dist; Thu, 7 Feb 2002 06:16:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EGF2Q020290 for ; Thu, 7 Feb 2002 06:16:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24691 for ; Thu, 7 Feb 2002 06:16:20 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18251 for ; Thu, 7 Feb 2002 07:16:18 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g17EGNZ18380 for ; Thu, 7 Feb 2002 16:16:23 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Feb 2002 16:16:13 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Feb 2002 16:16:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Thu, 7 Feb 2002 16:16:01 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95E8@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGv4SSh5hM1c3UEQdGaIYyDJjsm8QAAJZgA To: , Cc: , X-OriginalArrivalTime: 07 Feb 2002 14:16:01.0724 (UTC) FILETIME=[F8A65FC0:01C1AFE1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g17EGH2Q020291 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Erik, > If we can do the above, and only the above, > then we can later add CGA (or something else more secure that RR) > by having the MNs who wish to require the more secure scheme set the > bit/pattern in their home address. > > Does the above description make more sense than what is in > the writeup? I think that your comment is clearer - but does this add a dependency to the MIPv6 base spec, or can MIPv6 move forward even if the CGA or something else is not ready? thanks, John From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:33:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28031 for ; Thu, 7 Feb 2002 09:33:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08093; Thu, 7 Feb 2002 07:33:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04681; Thu, 7 Feb 2002 06:32:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EUD2Q020426 for ; Thu, 7 Feb 2002 06:30:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17EUD01020425 for mobile-ip-dist; Thu, 7 Feb 2002 06:30:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EUA2Q020418 for ; Thu, 7 Feb 2002 06:30:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26497 for ; Thu, 7 Feb 2002 06:30:26 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26563 for ; Thu, 7 Feb 2002 07:30:24 -0700 (MST) Received: from ipunplugged.com (wormhole.local.ipunplugged.com [213.88.134.210]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id PAA29836 for ; Thu, 7 Feb 2002 15:28:22 +0100 Message-ID: <3C628F5A.80608@ipunplugged.com> Date: Thu, 07 Feb 2002 15:29:46 +0100 From: Hans =?ISO-8859-1?Q?Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis interpretation question References: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> <20020205140612.GA3758@lifix.fi> Content-Type: multipart/alternative; boundary="------------090001020102030601000705" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------090001020102030601000705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We register with the care-of-address advertised in the advertisement. We use the home address as source address. Collocated care-of-address we only use when registering directly with HA. Have never thought of this as ambiguous, interesting to note that otheres have. So, whats the score George ? It would be interesting to know even though not revealing who does what for those that haven't responded to the list. Regards /// Hasse Bjorn Andersson wrote: >On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote: > >>I am trying to figure out how implementers have interpreted the Rbit part of >>rfc2002. I have asked a few people privately and I do not get identical >>feedback so some discussion here maybe helpful. >> >>I remind you that if the Rbit is set in a Foreign Agent Advertisement the >>MIP client is required to register through the Foreign Agent even if it has >>access to a collocated address... >>But what does that mean exactly? >>1. Should the client register its Collocated care-of-address (and thus >>ignore the advertized CoA) but send the registration request to the FA and >>the FA forwards it to the HA? >>2. Should the client register with the care-of-address advertised in the >>advertisement? If this is the case, can the mobile now also use a collocated >>care of address as source address for some traffic?? >> > >I think it is pretty clear that it is alternative 1. The purpose, as >said in draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites to >enforce visiting policies (such as accounting) which require exchanges >of authorization." What would the use of the collocated CoA be if the >MN did not register it with anyone? It would be able to use the >address as any node, but it would not be a care-of address. > > Bjorn > --------------090001020102030601000705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit We register with the care-of-address advertised in the advertisement. We use the home address as source address. Collocated care-of-address we only use when registering directly with HA.

Have never thought of this as ambiguous, interesting to note that otheres have.

So, whats the score George ? It would be interesting to know even though not revealing who does what for those that haven't responded to the list.

Regards
/// Hasse

Bjorn Andersson wrote:
On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote:
I am trying to figure out how implementers have interpreted the Rbit part of
rfc2002. I have asked a few people privately and I do not get identical
feedback so some discussion here maybe helpful. 

I remind you that if the Rbit is set in a Foreign Agent Advertisement the
MIP client is required to register through the Foreign Agent even if it has
access to a collocated address...
But what does that mean exactly?
1. Should the client register its Collocated care-of-address (and thus
ignore the advertized CoA) but send the registration request to the FA and
the FA forwards it to the HA?
2. Should the client register with the care-of-address advertised in the
advertisement? If this is the case, can the mobile now also use a collocated
care of address as source address for some traffic??

I think it is pretty clear that it is alternative 1. The purpose, as
said in draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites to
enforce visiting policies (such as accounting) which require exchanges
of authorization." What would the use of the collocated CoA be if the
MN did not register it with anyone? It would be able to use the
address as any node, but it would not be a care-of address.

  Bjorn


--------------090001020102030601000705-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:35:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28123 for ; Thu, 7 Feb 2002 09:35:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28994; Thu, 7 Feb 2002 07:35:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05031; Thu, 7 Feb 2002 06:35:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EY32Q020464 for ; Thu, 7 Feb 2002 06:34:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17EY3HK020463 for mobile-ip-dist; Thu, 7 Feb 2002 06:34:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EXx2Q020456 for ; Thu, 7 Feb 2002 06:34:00 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g17EYCM24213; Thu, 7 Feb 2002 15:34:12 +0100 (MET) Date: Thu, 7 Feb 2002 15:30:15 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] BU Authorization method: design team recommendation To: john.loughney@nokia.com Cc: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, jari.arkko@piuha.net, Basavaraj.Patil@nokia.com In-Reply-To: "Your message with ID" <0C1353ABB1DEB74DB067ADFF749C4EEF5D95E8@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I think that your comment is clearer - but does this add a > dependency to the MIPv6 base spec, or can MIPv6 > move forward even if the CGA or something else is not > ready? There isn't a dependency on CGA, but there is a dependency on getting a bit/pattern reserved before the RFC is actually published (but we could do IETF last call etc. without actually knowing the bit/pattern and fill it in later.) Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:39:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28284 for ; Thu, 7 Feb 2002 09:39:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05771; Thu, 7 Feb 2002 06:39:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05630; Thu, 7 Feb 2002 06:39:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Ea32Q020508 for ; Thu, 7 Feb 2002 06:36:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17Ea3KX020507 for mobile-ip-dist; Thu, 7 Feb 2002 06:36:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EZu2Q020497 for ; Thu, 7 Feb 2002 06:35:56 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g17Ea8M24547; Thu, 7 Feb 2002 15:36:08 +0100 (MET) Date: Thu, 7 Feb 2002 15:32:12 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: vijayd@iprg.nokia.com Cc: Jari Arkko , basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C61E950.C373C55F@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 1. The "1 bit method" seems to be designed with CGA as the > only possible strong authorization mechanism for securing BUs. > However you have also agreed that other strong BU authorization > solutions are possible in the future. Has the design team > looked at other signaling mechanisms to indicate the preferred > mechanism by an MN or CN? Section 8 in Residual_Threats.txt > does not have enough info as to why you chose the "bit method" > over the other methods. I can see now that the writeup is a bit thin on these issues. Hopefully this email can help explain at least my views of what went into the thinking. > 2. Also, please let us know what other RFCs (other dependencies) > need to be changed to have this 1 bit in the IPv6 address? Depends what bit pattern we might want to reserve but (for reasons relating the unknown future) it might make sense to reserve both of these with the potential for using one or both of the for CGA or something else in the future. RFC 2373 defines the details of the format when the universal bit is set. However, EUI-64 addresses assigned to interfaces never have the group bit set. Thus I think it makes sense to reserve the combination universal = 1, group = 1. RFC 2373 also talks about links without global identifiers, and this is used in RFC 2472 (PPP for IPv6) and RFC 3041. In order to have some spare space for potential future direction I think it makes sense to also reserve universal = 0, group = 1 even though that means that RFC 2472 and RFC 3041 (and implementations of those?) would need to be modified. > 3. Assume, I have more than 2 mechanisms for BU authorization > (RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here? > For this, (IMO) the obvious thing would be a set of bits > in the Binding Update. You dont have to specify this now. We > can do this later using the reserved bits in the BU. RR+DH seems to incur close to the same processing overhead as RR+CGA while not providing much more security that just RR. MiTM is still possible. Perhaps there is a subtle difference (I don't know for sure) that such a DH MiTM requires seeing packets in both directions (i.e. that unicast routing is somewhat symmetric between the CN and HA) whereas a RR MiTM does not require this. Infrastructure-based mechanisms might make sense in some cases. I have doubts whether a PKI would ever carry accurate information about what Home Addresses a given certificate has authority to create binding for. So personally I think that a PKI can be used in addition to whatever BU authorization mechanism there is (e.g. RR) to be able to provide corse level distinction between "known friends" and "others". I don't personally understand AAA-based authorization of binding updates would entail and whether it would fit into the architecture of AAA that the AAAwg is assuming to comment on that. But up-leveling - the property that "the low-order 64 bits of the address is allocated according to EUI-64" is currently encoded in the IPv6 address - it is a property of the address. The fact that "the low-order 64 bits is a of a public key" is also a property of the address, thus it would make sense to encode this in the address as well. The fact that a MN or CN uses AAA (or some other infrastructure) for pair-wise authentication and authorization is not a property of an IPv6 address. > 4. The following is from Residual_Threats.txt > > > - A mechanism for the MN to indicate on-line that it wants to > > use CGA and not RR. This assumes the RR attacker can't > > prevent the MN from seeing the RR packets. This, however, > > seems hard given that the attacker is on the CN-HA path. > > > > I tried really hard to figure out why the above mechanism > is inferior to the "1 bit" method. If the RR attacker prevents > the MN from seeing the RR packets, then you have RR itself > failing. If RR fails, CGA also fails. Am I missing something > very obvious? Example: attacker on the path between the CN and the HA. Attacker can pretend to be the MN since it is on-path. Using the above mechanism it can get the CN to accept RR-protected BUs even though the MN actually only wants to allow CGA-protected BUs. This is different than the bit being securely retrieved from the secure DNS before the communication started (and if you don't have DNSSEC you really don't care if you're communicating with the real peer or not :-) and the CN refusing RR-protected BUs if the bit is set. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 09:42:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28364 for ; Thu, 7 Feb 2002 09:42:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13072; Thu, 7 Feb 2002 07:42:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28156; Thu, 7 Feb 2002 06:42:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Eeb2Q020557 for ; Thu, 7 Feb 2002 06:40:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17EeamN020556 for mobile-ip-dist; Thu, 7 Feb 2002 06:40:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17EeX2Q020549 for ; Thu, 7 Feb 2002 06:40:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02288 for ; Thu, 7 Feb 2002 06:40:48 -0800 (PST) Received: from muminmamman.lifix.fi ([195.238.204.197]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12317 for ; Thu, 7 Feb 2002 07:40:39 -0700 (MST) Received: from ban by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian)) id 16Ypj4-00073g-00 for ; Thu, 07 Feb 2002 16:40:38 +0200 Date: Thu, 7 Feb 2002 16:40:38 +0200 From: Bjorn Andersson To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis interpretation question Message-ID: <20020207144038.GA26971@lifix.fi> Mail-Followup-To: Bjorn Andersson , mobile-ip@sunroof.eng.sun.com References: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> <20020205140612.GA3758@lifix.fi> <3C628F5A.80608@ipunplugged.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C628F5A.80608@ipunplugged.com> User-Agent: Mutt/1.3.25i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Thu, Feb 07 2002, at 15:29:46 +0100, Hans Sjöstrand wrote: > We register with the care-of-address advertised in the advertisement. We use > the home address as source address. Collocated care-of-address we only use when > registering directly with HA. This is actually what our MN implementation does also, although I interpreted it differently in my previous mail. So now we have three MNs registering the FA care-of address. Björn -- Björn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 10:17:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29562 for ; Thu, 7 Feb 2002 10:17:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04581; Thu, 7 Feb 2002 08:17:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03874; Thu, 7 Feb 2002 07:17:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17FFk2Q020746 for ; Thu, 7 Feb 2002 07:15:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17FFktV020745 for mobile-ip-dist; Thu, 7 Feb 2002 07:15:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17FFh2Q020738 for ; Thu, 7 Feb 2002 07:15:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11110 for ; Thu, 7 Feb 2002 07:15:57 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03756 for ; Thu, 7 Feb 2002 08:15:56 -0700 (MST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1LTW75RQ>; Thu, 7 Feb 2002 10:15:52 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABAC3@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question Date: Thu, 7 Feb 2002 10:15:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g17FFh2Q020739 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit First of all thanks to Hans and all the others that responded. The score is 2-all but I only got 4 responses altogether Behavior 1 (2 votes): if R bit is set the forget the collocated address and register using the advertised CoA. Behavior 2 (2 votes): if Rbit is set then register the collocated address via the FA. I have also some information that Rbit has never been tested in interop events but please correct me if you know otherwise. This is important because if an FA is implemented to expect behavior 1 but mobiles implements behavior 2 (and vise versa) I am not sure things will work out as expected. My opinion is that the Rbit is weakly specified in the spec. I also interpret the spec as behavior 2, so I guess this has 3 votes :-) , but I think Behavior 1 is clearly also allowed by the current text. The problem is the following: The Rbit was invented to make sure that all nodes connected to the FA register with it. This means as a minimum that if the Rbit is set and if you want to use a collocated address then you MUST register it to the FA otherwise the FA will drop your packets. This was an opinion that was expressed by someone privately and I also agree with. One, however, should be able to use an FA that *requires* registration but DOES NOT offer encaps/decaps services based on CoA. i.e. all mobile nodes are supposed to have collocated addresses but before they use them they MUST register through the FA. Unfortunately, the spec does not allow that because if you send an Foreign Agent Advertisement you MUST include at least one valid CoA. I think this is an unreasonable over-specification and disallows a potentially useful model. The collocated and non-collocated models are independent and should be possible to be deployed independently. Can we fix this? Thoughts? Regards George -----Original Message----- From: Hans Sjöstrand [mailto:hans@ipunplugged.com] Sent: Thursday, February 07, 2002 2:30 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis interpretation question We register with the care-of-address advertised in the advertisement. We use the home address as source address. Collocated care-of-address we only use when registering directly with HA. Have never thought of this as ambiguous, interesting to note that otheres have. So, whats the score George ? It would be interesting to know even though not revealing who does what for those that haven't responded to the list. Regards /// Hasse Bjorn Andersson wrote: On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote: I am trying to figure out how implementers have interpreted the Rbit part ofrfc2002. I have asked a few people privately and I do not get identicalfeedback so some discussion here maybe helpful. I remind you that if the Rbit is set in a Foreign Agent Advertisement theMIP client is required to register through the Foreign Agent even if it hasaccess to a collocated address...But what does that mean exactly?1. Should the client register its Collocated care-of-address (and thusignore the advertized CoA) but send the registration request to the FA andthe FA forwards it to the HA?2. Should the client register with the care-of-address advertised in theadvertisement? If this is the case, can the mobile now also use a collocatedcare of address as source address for some traffic?? I think it is pretty clear that it is alternative 1. The purpose, assaid in draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites toenforce visiting policies (such as accounting) which require exchangesof authorization." What would the use of the collocated CoA be if theMN did not register it with anyone? It would be able to use theaddress as any node, but it would not be a care-of address. Bjorn From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 11:11:50 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01067 for ; Thu, 7 Feb 2002 11:11:50 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20908; Thu, 7 Feb 2002 09:11:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13788; Thu, 7 Feb 2002 08:11:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17G9W2Q020957 for ; Thu, 7 Feb 2002 08:09:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17G9WML020956 for mobile-ip-dist; Thu, 7 Feb 2002 08:09:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17G9T2Q020949 for ; Thu, 7 Feb 2002 08:09:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25907 for ; Thu, 7 Feb 2002 08:09:43 -0800 (PST) Received: from pat.uio.no (pat.uio.no [129.240.130.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29085 for ; Thu, 7 Feb 2002 09:09:43 -0700 (MST) Received: from ifi.uio.no ([129.240.64.2]) by pat.uio.no with esmtp (Exim 2.12 #7) id 16Yr7F-0000xL-00 for mobile-ip@sunroof.eng.sun.com; Thu, 7 Feb 2002 17:09:41 +0100 Received: from ESPENHOMEPC (hbryhnipc2.uio.no [129.240.206.227]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id RAA02351 for ; Thu, 7 Feb 2002 17:09:41 +0100 (MET) From: "eskl" To: Subject: RE: [mobile-ip] RFC2002bis interpretation question Date: Thu, 7 Feb 2002 17:13:58 +0100 Message-ID: <000001c1aff2$72f6ae00$e3cef081@ESPENHOMEPC> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20020207144038.GA26971@lifix.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g17G9T2Q020950 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Our MN is also using the FA care-of-address. espen Espen Klovning Birdstep Technology ASA www.birdstep.com -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Bjorn Andersson Sent: 7. februar 2002 15:41 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis interpretation question On Thu, Feb 07 2002, at 15:29:46 +0100, Hans Sjöstrand wrote: > We register with the care-of-address advertised in the advertisement. We use > the home address as source address. Collocated care-of-address we only use when > registering directly with HA. This is actually what our MN implementation does also, although I interpreted it differently in my previous mail. So now we have three MNs registering the FA care-of address. Björn -- Björn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 11:40:45 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01656 for ; Thu, 7 Feb 2002 11:40:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05888; Thu, 7 Feb 2002 08:40:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02678; Thu, 7 Feb 2002 08:40:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Gcl2Q021047 for ; Thu, 7 Feb 2002 08:38:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17Gcl2Q021046 for mobile-ip-dist; Thu, 7 Feb 2002 08:38:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Gch2Q021039 for ; Thu, 7 Feb 2002 08:38:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20355 for ; Thu, 7 Feb 2002 08:38:58 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06746 for ; Thu, 7 Feb 2002 09:38:57 -0700 (MST) Received: from ipunplugged.com (wormhole.local.ipunplugged.com [213.88.134.210]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA32387 for ; Thu, 7 Feb 2002 17:36:59 +0100 Message-ID: <3C62AD7E.4000406@ipunplugged.com> Date: Thu, 07 Feb 2002 17:38:22 +0100 From: Hans =?ISO-8859-1?Q?Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question References: <8C92E23A3E87FB479988285F9E22BE465ABAC3@ftmail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thank you George for finding this and bringing it up, BTW, it seams to be up to 5-1 now. You learn something every day, I didn't know of this little finesse, registering with the FA adn yet running co-located mode. And I don't know what would be the big benafit. What is the advantage of running co-located when yuo have a FA. How does a FA indicate that it doesn't support "encaps/decaps services based on CoA"? We have never run into the problem because our MN always switch to FA registered if a adverticements comes out, regardless of R-bit. So, an interop with us would be pointless. If someone perceives to run co-located despite our agents adverticements, they will be sean as using our simple IP service and not mobile IP. The packets will be treated according to the policy configured in the FA (not really a FA in that case, more of a ACD (Access Control Device)) and if he is authenticated by some other means (like web-login or 802.1x). My private feeling is that there are no advantage for the MN to run co-located over registered with FA. And there is no way for a FA to tell that he proposes co-located mode. So, in my mind it's already set, adn instead the spec could be clarified to disallow registering with co-located address to FA. E.g. says 3024 However, one of the primary objectives of the Mobile IP specification is not to require this mode of operation. The mechanisms outlined in this document are primarily intended for use by mobile nodes that rely on the foreign agent for forward tunnel support. It is desirable to continue supporting these mobile nodes, even in the presence of filtering routers. Regards /// Hasse George Tsirtsis wrote: >First of all thanks to Hans and all the others that responded. > >The score is 2-all but I only got 4 responses altogether >Behavior 1 (2 votes): if R bit is set the forget the collocated address and >register using the advertised CoA. >Behavior 2 (2 votes): if Rbit is set then register the collocated address >via the FA. > >I have also some information that Rbit has never been tested in interop >events but please correct me if you know otherwise. This is important >because if an FA is implemented to expect behavior 1 but mobiles implements >behavior 2 (and vise versa) I am not sure things will work out as expected. >My opinion is that the Rbit is weakly specified in the spec. I also >interpret the spec as behavior 2, so I guess this has 3 votes :-) , but I >think Behavior 1 is clearly also allowed by the current text. The problem is >the following: > >The Rbit was invented to make sure that all nodes connected to the FA >register with it. This means as a minimum that if the Rbit is set and if you >want to use a collocated address then you MUST register it to the FA >otherwise the FA will drop your packets. This was an opinion that was >expressed by someone privately and I also agree with. > >One, however, should be able to use an FA that *requires* registration but >DOES NOT offer encaps/decaps services based on CoA. i.e. all mobile nodes >are supposed to have collocated addresses but before they use them they MUST >register through the FA. > >Unfortunately, the spec does not allow that because if you send an Foreign >Agent Advertisement you MUST include at least one valid CoA. I think this is >an unreasonable over-specification and disallows a potentially useful model. >The collocated and non-collocated models are independent and should be >possible to be deployed independently. > >Can we fix this? > >Thoughts? > >Regards >George > > > > >-----Original Message----- >From: Hans Sjöstrand [mailto:hans@ipunplugged.com] >Sent: Thursday, February 07, 2002 2:30 PM >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] RFC2002bis interpretation question > > >We register with the care-of-address advertised in the advertisement. We use >the home address as source address. Collocated care-of-address we only use >when registering directly with HA. > >Have never thought of this as ambiguous, interesting to note that otheres >have. > >So, whats the score George ? It would be interesting to know even though not >revealing who does what for those that haven't responded to the list. > >Regards >/// Hasse > >Bjorn Andersson wrote: > >On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote: >I am trying to figure out how implementers have interpreted the Rbit part >ofrfc2002. I have asked a few people privately and I do not get >identicalfeedback so some discussion here maybe helpful. I remind you that >if the Rbit is set in a Foreign Agent Advertisement theMIP client is >required to register through the Foreign Agent even if it hasaccess to a >collocated address...But what does that mean exactly?1. Should the client >register its Collocated care-of-address (and thusignore the advertized CoA) >but send the registration request to the FA andthe FA forwards it to the >HA?2. Should the client register with the care-of-address advertised in >theadvertisement? If this is the case, can the mobile now also use a >collocatedcare of address as source address for some traffic?? >I think it is pretty clear that it is alternative 1. The purpose, assaid in >draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites toenforce >visiting policies (such as accounting) which require exchangesof >authorization." What would the use of the collocated CoA be if theMN did not >register it with anyone? It would be able to use theaddress as any node, but >it would not be a care-of address. Bjorn > From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 11:57:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02211 for ; Thu, 7 Feb 2002 11:57:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18071; Thu, 7 Feb 2002 09:57:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08701; Thu, 7 Feb 2002 08:57:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17GtT2Q021117 for ; Thu, 7 Feb 2002 08:55:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17GtSuP021116 for mobile-ip-dist; Thu, 7 Feb 2002 08:55:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17GtP2Q021109 for ; Thu, 7 Feb 2002 08:55:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08994 for ; Thu, 7 Feb 2002 08:55:40 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16882 for ; Thu, 7 Feb 2002 09:55:39 -0700 (MST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1LTW75Z3>; Thu, 7 Feb 2002 11:55:38 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABAC9@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: results and proposal was: RE: [mobile-ip] RFC2002bis interpre tati on question Date: Thu, 7 Feb 2002 11:55:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g17GtQ2Q021110 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit -----Original Message----- From: Hans Sjöstrand [mailto:hans@ipunplugged.com] Sent: Thursday, February 07, 2002 4:38 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question Thank you George for finding this and bringing it up, BTW, it seams to be up to 5-1 now. GT> I think it is 4-2 but this was not a contest :-) as I said I think both behaviors are correct given the current text. You learn something every day, I didn't know of this little finesse, registering with the FA adn yet running co-located mode. And I don't know what would be the big benafit. What is the advantage of running co-located when yuo have a FA. GT> Well that is the point...you do not have an FA that encapsulates/decapsulates just a control node that let you pass through or not based on registrations, which is a much lighter function. How does a FA indicate that it doesn't support "encaps/decaps services based on CoA"? GT> This is easy. One way would be to allow an FA advert to have Rbit set but does not include a CoA. The Mobile Node would then see that there is no CoA so it needs to get a collocated address and since the Rbit is set the node will have to register it through the FA. We have never run into the problem because our MN always switch to FA registered if a adverticements comes out, regardless of R-bit. So, an interop with us would be pointless. If someone perceives to run co-located despite our agents adverticements, they will be sean as using our simple IP service and not mobile IP. The packets will be treated according to the policy configured in the FA (not really a FA in that case, more of a ACD (Access Control Device)) and if he is authenticated by some other means (like web-login or 802.1x). My private feeling is that there are no advantage for the MN to run co-located over registered with FA. And there is no way for a FA to tell that he proposes co-located mode. So, in my mind it's already set, adn instead the spec could be clarified to disallow registering with co-located address to FA. GT> No, no, now you are totally missing the point of the Rbit. Just because some implementers chose to prefer CoAs if they can get them it does not mean that CCoAs are not needed and it does not mean that the FA should not be able to request registration. The Rbit is useful but it is weakly specified which unfortunately allows you to think that is not needed. George George Tsirtsis wrote: >First of all thanks to Hans and all the others that responded. > >The score is 2-all but I only got 4 responses altogether >Behavior 1 (2 votes): if R bit is set the forget the collocated address and >register using the advertised CoA. >Behavior 2 (2 votes): if Rbit is set then register the collocated address >via the FA. > >I have also some information that Rbit has never been tested in interop >events but please correct me if you know otherwise. This is important >because if an FA is implemented to expect behavior 1 but mobiles implements >behavior 2 (and vise versa) I am not sure things will work out as expected. >My opinion is that the Rbit is weakly specified in the spec. I also >interpret the spec as behavior 2, so I guess this has 3 votes :-) , but I >think Behavior 1 is clearly also allowed by the current text. The problem is >the following: > >The Rbit was invented to make sure that all nodes connected to the FA >register with it. This means as a minimum that if the Rbit is set and if you >want to use a collocated address then you MUST register it to the FA >otherwise the FA will drop your packets. This was an opinion that was >expressed by someone privately and I also agree with. > >One, however, should be able to use an FA that *requires* registration but >DOES NOT offer encaps/decaps services based on CoA. i.e. all mobile nodes >are supposed to have collocated addresses but before they use them they MUST >register through the FA. > >Unfortunately, the spec does not allow that because if you send an Foreign >Agent Advertisement you MUST include at least one valid CoA. I think this is >an unreasonable over-specification and disallows a potentially useful model. >The collocated and non-collocated models are independent and should be >possible to be deployed independently. > >Can we fix this? > >Thoughts? > >Regards >George > > > > >-----Original Message----- >From: Hans Sjöstrand [mailto:hans@ipunplugged.com] >Sent: Thursday, February 07, 2002 2:30 PM >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] RFC2002bis interpretation question > > >We register with the care-of-address advertised in the advertisement. We use >the home address as source address. Collocated care-of-address we only use >when registering directly with HA. > >Have never thought of this as ambiguous, interesting to note that otheres >have. > >So, whats the score George ? It would be interesting to know even though not >revealing who does what for those that haven't responded to the list. > >Regards >/// Hasse > >Bjorn Andersson wrote: > >On Tue, Feb 05 2002, at 07:53:55 -0500, George Tsirtsis wrote: >I am trying to figure out how implementers have interpreted the Rbit part >ofrfc2002. I have asked a few people privately and I do not get >identicalfeedback so some discussion here maybe helpful. I remind you that >if the Rbit is set in a Foreign Agent Advertisement theMIP client is >required to register through the Foreign Agent even if it hasaccess to a >collocated address...But what does that mean exactly?1. Should the client >register its Collocated care-of-address (and thusignore the advertized CoA) >but send the registration request to the FA andthe FA forwards it to the >HA?2. Should the client register with the care-of-address advertised in >theadvertisement? If this is the case, can the mobile now also use a >collocatedcare of address as source address for some traffic?? >I think it is pretty clear that it is alternative 1. The purpose, assaid in >draft-ietf-mobileip-rfc2002-bis-08.txt, is: "to allow sites toenforce >visiting policies (such as accounting) which require exchangesof >authorization." What would the use of the collocated CoA be if theMN did not >register it with anyone? It would be able to use theaddress as any node, but >it would not be a care-of address. Bjorn > From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 13:08:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04061 for ; Thu, 7 Feb 2002 13:08:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15944; Thu, 7 Feb 2002 11:07:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19878; Thu, 7 Feb 2002 10:07:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17I4R2Q021202 for ; Thu, 7 Feb 2002 10:04:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17I4QLu021201 for mobile-ip-dist; Thu, 7 Feb 2002 10:04:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17I4N2Q021194 for ; Thu, 7 Feb 2002 10:04:23 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04614 for ; Thu, 7 Feb 2002 10:04:39 -0800 (PST) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26587 for ; Thu, 7 Feb 2002 10:04:38 -0800 (PST) Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id SAA08155 for ; Thu, 7 Feb 2002 18:04:37 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002020710034614003 for ; Thu, 07 Feb 2002 10:03:46 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1124XVTX>; Thu, 7 Feb 2002 10:04:37 -0800 Message-ID: From: "Narjala, Ranjit S" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RFC2002bis interpretation question Date: Thu, 7 Feb 2002 10:04:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g17I4O2Q021195 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Our implementation (at Intel) supports both methods - registering with the FA via a colocated care-of address, as well as a FA care-of address. The spec, as has been said before, left this open, and we thought it would be wise to support both. In our implementation, we register using the FA care-of address by default (reason below), but the user has the option to force the MN to use the colocated care-of address when in this situation. In the interests of saving time on handoffs, we've noticed that registering with the FA care-of address is better. When a link comes up (ethernet cable plugged in to a wired NIC, for example), Agent Discovery can usually be completed faster than obtaining a DHCP address (the colocated address), and then registering with the FA using the FA care-of address is in most cases significantly faster than waiting to obtain a DHCP address and then registering with the FA using that colocated address. My two cents. Regards, - Ranjit -----Original Message----- From: eskl [mailto:espen@birdstep.com] Sent: Thursday, February 07, 2002 8:14 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RFC2002bis interpretation question Our MN is also using the FA care-of-address. espen Espen Klovning Birdstep Technology ASA www.birdstep.com -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Bjorn Andersson Sent: 7. februar 2002 15:41 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC2002bis interpretation question On Thu, Feb 07 2002, at 15:29:46 +0100, Hans Sjöstrand wrote: > We register with the care-of-address advertised in the advertisement. We use > the home address as source address. Collocated care-of-address we only use when > registering directly with HA. This is actually what our MN implementation does also, although I interpreted it differently in my previous mail. So now we have three MNs registering the FA care-of address. Björn -- Björn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 13:10:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04199 for ; Thu, 7 Feb 2002 13:10:37 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01723; Thu, 7 Feb 2002 11:10:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20834; Thu, 7 Feb 2002 10:10:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17I8H2Q021255 for ; Thu, 7 Feb 2002 10:08:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17I8Hhj021254 for mobile-ip-dist; Thu, 7 Feb 2002 10:08:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17I8D2Q021247 for ; Thu, 7 Feb 2002 10:08:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06071 for ; Thu, 7 Feb 2002 10:08:29 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14000 for ; Thu, 7 Feb 2002 11:08:28 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g17I8Kj02255 for ; Thu, 7 Feb 2002 10:08:20 -0800 (PST) Received: from cisco.com (sjc-vpn1-242.cisco.com [10.21.96.242]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABQ79822; Thu, 7 Feb 2002 10:08:05 -0800 (PST) Message-ID: <3C62C2A7.A0AE46D1@cisco.com> Date: Thu, 07 Feb 2002 10:08:39 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question References: <8C92E23A3E87FB479988285F9E22BE465ABAC9@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Tsirtsis wrote: > How does a FA indicate that it doesn't > support "encaps/decaps services based on CoA"? > > GT> This is easy. One way would be to allow an FA advert to have Rbit set > but does not include a CoA. The Mobile Node would then see that there is no > CoA so it needs to get a collocated address and since the Rbit is set the > node will have to register it through the FA. > Since FA supports tunneling, why shouldn't FA advert its CoA? Then it's up to MNs to decide to use CCoA or FA CoA. The R bit is for FA access (or MIP service authorization) control. The CoA is not meant for tunneling control, but merely advertised service. But the above scheme use CoA as tunneling control. As said, MNs will likely use the FA CoA when advert received. Though I think the generic properties of existing spec allows flexibility for MN to choose where it wants tunnel termination. The access authentication/authorization scheme may factor in MN's decision since it may go through 2 levels (802.1x and MIP) when CCOA is used. Of course, FA may decide to bypass MIP authentication when it sees RRQ with D bit set and external CoA if it is aware that 802.1x already occurred. Flexibility comes complexity. :) But forcing MNs to use FA COA with R bit advertised is rigid, though simpler for the common scenario. So if we leave spec as is, then MNs choose either CCoA or FA CoA when it sends RRQ to FA, which advert the R bit. Is this ambiguous? Seems like the new proposal is to enforce CCOA tunneling by removing COA in advert. And on the other end, proposal to mandate that MN must use FA COA. Both cases when R bit set in advert. Both takes the right to choose from MN. This is what we want, right? Kent > > We have never run into the problem because our MN always switch to FA > registered if a adverticements comes out, regardless of R-bit. So, an > interop with us would be pointless. > > If someone perceives to run co-located despite our agents > adverticements, they will be sean as using our simple IP service and not > mobile IP. The packets will be treated according to the policy > configured in the FA (not really a FA in that case, more of a ACD > (Access Control Device)) and if he is authenticated by some other means > (like web-login or 802.1x). > > My private feeling is that there are no advantage for the MN to run > co-located over registered with FA. And there is no way for a FA to tell > that he proposes co-located mode. So, in my mind it's already set, adn > instead the spec could be clarified to disallow registering with > co-located address to FA. > > GT> No, no, now you are totally missing the point of the Rbit. Just because > some implementers chose to prefer CoAs if they can get them it does not mean > that CCoAs are not needed and it does not mean that the FA should not be > able to request registration. The Rbit is useful but it is weakly specified > which unfortunately allows you to think that is not needed. > > George From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 13:28:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04907 for ; Thu, 7 Feb 2002 13:28:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05005; Thu, 7 Feb 2002 10:28:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26995; Thu, 7 Feb 2002 10:28:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17IMt2Q021379 for ; Thu, 7 Feb 2002 10:22:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17IMsSl021378 for mobile-ip-dist; Thu, 7 Feb 2002 10:22:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17IMq2Q021371 for ; Thu, 7 Feb 2002 10:22:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13585 for ; Thu, 7 Feb 2002 10:23:07 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08558 for ; Thu, 7 Feb 2002 11:23:06 -0700 (MST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 6BFB040012F for ; Thu, 7 Feb 2002 10:23:06 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id KAA13108 for ; Thu, 7 Feb 2002 10:24:05 -0800 (PST) Date: Thu, 7 Feb 2002 10:24:03 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Mobile IP Working Group Subject: [mobile-ip] [AAA-WG]: HA-FA key in Mobile IP (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, I had sent the attached email to the AAA WG but am yet to receive a response. Can someone in this group provide any info in this regard? Given all the energy in this list (the R bit issue) and the involvement of many Mobile IP implementors, my hopes are positive...:-) Thanks in advance! Siva ps: for those in the AAA WG list, sorry for the cross post.... ---------- Forwarded message ---------- Date: Fri, 1 Feb 2002 16:40:00 -0800 (PST) From: Sivasundar Ramamurthy To: AAA Working Group Subject: [AAA-WG]: HA-FA key in Mobile IP Hello, Section 4.5 in the Diameter Mobile IP Application draft states: If the FA's local policy allows it to receive AAA session keys, and it it does have any exisiting keys with the HA, it may set the FA-HA-Key request flag (in the feature vector). The word "any" seems to imply that for every HA that it talks to, the FA can maintain a single key and use it whenever it communicates with that HA (irrespective of the MN involved). And to be in sync with the FA, the HA should also maintain a single HA-FA key for each FA and use it whenever it communicates with the FA (irrespective of the MN involved) At the same time, the phrase "AAA Session Key" seems to imply that the HA-FA key is session specific. That is, the FA will maintain a seperate HA-FA key for each session (MN), irrespective of whether the FA has a key to the same HA that was obtained via some other MN. Thus the HA-FA key used to create or verify the authenticator will depend on the MN in question. And to be in sync with the FA, the HA will need to maintain session specific HA-FA keys, irrespective of whether the HA has a key to the same FA that was obtained via some other MN. Thus the HA-FA key used to create or verify the authenticator will depend on the MN in question. Are both interpretations correct? If so, then it does seem possible that the implementor of the HA follows one of them and the FA implementor the other. This will lead to unnecessary authentication failures between the HA and FA, which can be prevented by making one interpretation the standard. But if only of the above interpretations is correct, I am guessing it is the first one. But can we make it more explicit? thanks! Siva From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 14:50:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07538 for ; Thu, 7 Feb 2002 14:50:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06529; Thu, 7 Feb 2002 12:49:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18318; Thu, 7 Feb 2002 11:49:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Jj62Q021588 for ; Thu, 7 Feb 2002 11:45:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17Jj6KY021587 for mobile-ip-dist; Thu, 7 Feb 2002 11:45:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Jj22Q021580 for ; Thu, 7 Feb 2002 11:45:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12174; Thu, 7 Feb 2002 11:45:16 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05540; Thu, 7 Feb 2002 11:45:15 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17JjCa17276; Thu, 7 Feb 2002 20:45:12 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA08566; Thu, 7 Feb 2002 20:45:13 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17JjCg80994; Thu, 7 Feb 2002 20:45:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202071945.g17JjCg80994@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Charlie Perkins , Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 04 Feb 2002 23:29:51 PST. <3C5F89EF.9C6ADC01@iprg.nokia.com> Date: Thu, 07 Feb 2002 20:45:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: 4. Deering-Zill Tunneling ... Unknown properties: - ... - Interaction with IPsec (a part of it) => I have done it (authors have it). Summary: This proposal has a cleaner semantics and would have been a stronger candidate should its security implications for all its potential uses (IPsec etc) have been better understood today. => so my D/Z tunneling and IPsec interaction note can become useful if the D/Z tunneling receives more interest. (summary of my note: the important point is the order of the crypto transform and the D/Z compression, and AH gives more choice because the two operations can commute). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 14:54:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07698 for ; Thu, 7 Feb 2002 14:54:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27777; Thu, 7 Feb 2002 12:54:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19561; Thu, 7 Feb 2002 11:54:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Jps2Q021671 for ; Thu, 7 Feb 2002 11:51:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17Jps5u021670 for mobile-ip-dist; Thu, 7 Feb 2002 11:51:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17Jpp2Q021660 for ; Thu, 7 Feb 2002 11:51:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13717; Thu, 7 Feb 2002 11:52:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08464; Thu, 7 Feb 2002 11:52:03 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17Jq1a18577; Thu, 7 Feb 2002 20:52:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA08685; Thu, 7 Feb 2002 20:52:02 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17Jq1g81042; Thu, 7 Feb 2002 20:52:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202071952.g17Jq1g81042@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Tue, 05 Feb 2002 14:15:54 +0100. Date: Thu, 07 Feb 2002 20:52:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > is more organization and feed back from other issues (if we'll give up HAO > the situation will be very different). Has anybody talked about giving up HAO? => not yet but I don't know what the design team want to do. Are you referring to the possibility of replacing it with D/Z tunneling? => for instance. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 15:19:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08441 for ; Thu, 7 Feb 2002 15:19:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20747; Thu, 7 Feb 2002 13:19:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26015; Thu, 7 Feb 2002 12:18:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17K9T2Q021804 for ; Thu, 7 Feb 2002 12:09:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17K9T7o021803 for mobile-ip-dist; Thu, 7 Feb 2002 12:09:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17K9Q2Q021796 for ; Thu, 7 Feb 2002 12:09:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18634; Thu, 7 Feb 2002 12:09:38 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23405; Thu, 7 Feb 2002 13:09:37 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g17K9Wa20835; Thu, 7 Feb 2002 21:09:32 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA08999; Thu, 7 Feb 2002 21:09:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g17K9Wg81172; Thu, 7 Feb 2002 21:09:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202072009.g17K9Wg81172@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "Jari T. Malinen" , Charlie Perkins , Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Tue, 05 Feb 2002 12:00:54 +0100. Date: Thu, 07 Feb 2002 21:09:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I imagine we want the rule that when both HAO and ADA options are sent they MUST be included in the same destination options header. It makes no sense to allow two destination option headers in the packet for the purpose of having one carry the HAO and the other carry the ADA and I suspect it's easier for an implementation to be able to extract both addresses in the same context in the code. => this kind of MUST is clearly an abuse (things can still work without it) but it makes things far simpler without drawbacks... I.e. it makes sense. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 17:36:50 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11685 for ; Thu, 7 Feb 2002 17:36:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03184; Thu, 7 Feb 2002 14:36:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11659; Thu, 7 Feb 2002 14:35:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17MIM2Q022183 for ; Thu, 7 Feb 2002 14:18:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17MIM59022182 for mobile-ip-dist; Thu, 7 Feb 2002 14:18:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17MIF2Q022175 for ; Thu, 7 Feb 2002 14:18:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06265; Thu, 7 Feb 2002 14:18:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09117; Thu, 7 Feb 2002 15:18:18 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA22296; Thu, 7 Feb 2002 14:18:14 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g17MIDS16842; Thu, 7 Feb 2002 14:18:13 -0800 X-mProtect:  Thu, 7 Feb 2002 14:18:13 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdS7qTvD; Thu, 07 Feb 2002 14:18:11 PST Message-ID: <3C62FD24.4C8AD26@iprg.nokia.com> Date: Thu, 07 Feb 2002 14:18:12 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net, basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Erik, comments below Erik Nordmark wrote: > > Vijay, > > We haven't managed to come up with a scheme where CGA can be completely(*) > added later without opening up a "beating down" attack where an attacker > on path between CN and HA could 1) claim to be the MN and 2) cause the > CN to accept a BU protected by just RR. > > Thus the idea (which perhaps isn't written up that well) is to do > two things initially: > 1) get a bit (or pattern of bits) in the low order 64 bits of IPv6 addresses > marked as reserved. > 2) have the MIPv6 specification say that when the HoA bottom 64 bits has > this reserved bit/pattern then it MUST NOT accept a BU protected by RR. > > If we can do the above, and only the above, > then we can later add CGA (or something else more secure that RR) > by having the MNs who wish to require the more secure scheme set the > bit/pattern in their home address. > As I said before, my only problem is with this "1 bit method" in the IPv6 address. when you say "pattern of bits", how many bits can you reserve in the IPv6 address to take into account all the stronger BU Authorization metods that could be specified in the future? As far as I know, I already need 3 bits to select a mechanism among 5 mechanisms. It would be difficult to justify reserving enough bits in the IPv6 host id space so that Mobile IPv6 could select from among several BU Authorization mechanisms. For CGA, maybe the "1 bit method" is the best selection mechanism. And this should be specified as part of the "CGA for MIPv6" spec. regards Vijay > Does the above description make more sense than what is in the writeup? > > Does is make you change your mind? > > Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 17:36:50 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11687 for ; Thu, 7 Feb 2002 17:36:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03180; Thu, 7 Feb 2002 14:36:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11610; Thu, 7 Feb 2002 14:34:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17MDV2Q022148 for ; Thu, 7 Feb 2002 14:13:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17MDVhl022147 for mobile-ip-dist; Thu, 7 Feb 2002 14:13:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17MDS2Q022140 for ; Thu, 7 Feb 2002 14:13:29 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08597 for ; Thu, 7 Feb 2002 17:13:44 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA22358 for mobile-ip@sunroof.eng.sun.com; Thu, 7 Feb 2002 17:14:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g174GZ2Q018813 for ; Wed, 6 Feb 2002 20:16:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19824 for ; Wed, 6 Feb 2002 20:16:50 -0800 (PST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04953 for ; Wed, 6 Feb 2002 20:16:47 -0800 (PST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g174GdK19127 for ; Thu, 7 Feb 2002 09:46:40 +0530 (IST) Received: from shiva (pcz-shiva.sasken.com [10.1.48.88]) by sunrnd2.sasken.com (8.11.6/8.11.6) with SMTP id g174GbW26709 for ; Thu, 7 Feb 2002 09:46:37 +0530 (IST) Message-ID: <001201c1af8e$9c82a8f0$5830010a@shiva> From: "Shiva Raman Pandey" To: Subject: [mobile-ip] New draft Date: Thu, 7 Feb 2002 09:49:18 +0530 Organization: Sasken Communication Technologies Limited MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C1AFBC.B631BD30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C1AFBC.B631BD30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A new draft in the domain of "Fast Handoff in Mobile IP" is available - Improved Low Latency Handoff in Mobile IPv4 =20 http://search.ietf.org/internet-drafts/draft-shiva-improved-lowlatency-ha= ndoff-v4-01.txt All are welcome to have a discussion over it. Please send your comments to shiva@sasken.com Regards Shiva ------=_NextPart_000_000F_01C1AFBC.B631BD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
A new draft in the domain of "Fast = Handoff in=20 Mobile IP" is available -
 
Improved Low Latency Handoff in Mobile=20 IPv4
           = ;=20
http://search.ietf.org/internet-drafts/draft-shi= va-improved-lowlatency-handoff-v4-01.txt
 
All are welcome to have a discussion = over=20 it.
Please send your comments to shiva@sasken.com
 
Regards
Shiva
------=_NextPart_000_000F_01C1AFBC.B631BD30-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 18:29:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12834 for ; Thu, 7 Feb 2002 18:29:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23736; Thu, 7 Feb 2002 16:29:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22660; Thu, 7 Feb 2002 15:29:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NKQ2Q022743 for ; Thu, 7 Feb 2002 15:20:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17NKQYZ022742 for mobile-ip-dist; Thu, 7 Feb 2002 15:20:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NKL2Q022735 for ; Thu, 7 Feb 2002 15:20:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21495 for ; Thu, 7 Feb 2002 15:20:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17110 for ; Thu, 7 Feb 2002 16:20:32 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA28119 for ; Thu, 7 Feb 2002 15:20:32 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g17NKWV02051 for ; Thu, 7 Feb 2002 15:20:32 -0800 X-mProtect:  Thu, 7 Feb 2002 15:20:32 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdkPoXU5; Thu, 07 Feb 2002 15:20:29 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id PAA69925 for ; Thu, 7 Feb 2002 15:20:28 -0800 (PST) Message-ID: <3C630BBC.576D0EBC@iprg.nokia.com> Date: Thu, 07 Feb 2002 15:20:28 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: bidding down References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Reading recent texts this came to mind as a comment. It would be good to explain the bidding down attack scope a bit more. If the relevant scope is to prevent bidding down from authorizing BCE with a currently used method x having higher priority than y, then it prompts this logic: Suppose we are using a simple rule in CN which tags BCE telling how it was authorized and refuses BUs with lower-priority authorizations during the lifetime of a BCE but any time accepts authorizations of the same or higher method. Legitimate MN is never blocked from regaining the BCE nor can it lose it when it needs the BCE. When legitimate MN is not communicating, it should be enough for the CN to expire unused BCEs injected by RR attacker for the CN to be able to communicate with the legitimate MN, and/or always start its sessions with non RO data packet despite BCE. When the true MN initiates the RO connection it chooses a higher method and no RR attacker even from CN-HA path can change that by RR during the lifetime of the BCE, since it only accepts CGA or higher. The BCE can only be refreshed by the higher method run by the original MN during the time of the BCE being needed. If the attacker can block those legitimate messages, it can tamper with forwarding and do more harm even without MIPv6. Something is obviously missing, can you make it explicit.. BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 7 18:30:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12850 for ; Thu, 7 Feb 2002 18:30:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14135; Thu, 7 Feb 2002 15:29:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22722; Thu, 7 Feb 2002 15:29:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NO42Q022753 for ; Thu, 7 Feb 2002 15:24:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g17NO4bt022752 for mobile-ip-dist; Thu, 7 Feb 2002 15:24:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g17NO02Q022745 for ; Thu, 7 Feb 2002 15:24:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21447 for ; Thu, 7 Feb 2002 15:24:14 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21090 for ; Thu, 7 Feb 2002 16:24:14 -0700 (MST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id 481A16006AA for ; Thu, 7 Feb 2002 15:24:13 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA13414 for ; Thu, 7 Feb 2002 15:25:10 -0800 (PST) Date: Thu, 7 Feb 2002 15:25:08 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: "Mobile-Ip (E-mail)" Subject: Re: [mobile-ip] RFC2002bis interpretation question In-Reply-To: <8C92E23A3E87FB479988285F9E22BE465ABA90@ftmail> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, On Tue, 5 Feb 2002, George Tsirtsis wrote: > Hi all > > I am trying to figure out how implementers have interpreted the Rbit part of > rfc2002. I have asked a few people privately and I do not get identical > feedback so some discussion here maybe helpful. > > I remind you that if the Rbit is set in a Foreign Agent Advertisement the > MIP client is required to register through the Foreign Agent even if it has > access to a collocated address... > But what does that mean exactly? > 1. Should the client register its Collocated care-of-address (and thus > ignore the advertized CoA) but send the registration request to the FA and > the FA forwards it to the HA? > 2. Should the client register with the care-of-address advertised in the > advertisement? If this is the case, can the mobile now also use a collocated > care of address as source address for some traffic?? > > Is one of the above the "correct" behavior? How does your MIP client > implementation behave and what does your Foreign Agent implementation > expect? > I have not completely following the emails posted in this regard. So please bear with me if this has already been mentioned. section 3.7.2.1 of rfc2002 bis8 indicates (indirectly) that the FA could receive requests in which the D bit is set and the COA is not one of its own, and that it should not reject these requests. This would probably happen when a MN with a co-located COA acknowledges the R bit in the advertisement and registers via the FA. As far as the FA goes, it looks like it should be able to handle both types of behaviour. Of course, behaviour #2 would appear to the FA like a "regular" reg request. Siva From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 11:17:06 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13202 for ; Fri, 8 Feb 2002 11:17:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28791; Fri, 8 Feb 2002 08:16:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11800; Fri, 8 Feb 2002 08:15:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G33BJ000491 for ; Fri, 8 Feb 2002 08:03:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18G337n000490 for mobile-ip-dist; Fri, 8 Feb 2002 08:03:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G30BJ000483 for ; Fri, 8 Feb 2002 08:03:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15617 for ; Fri, 8 Feb 2002 06:19:39 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02364 for ; Fri, 8 Feb 2002 07:19:39 -0700 (MST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1LTW77K0>; Fri, 8 Feb 2002 09:19:38 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABAD8@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis in terpretation question Date: Fri, 8 Feb 2002 09:19:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I sent this many hours ago but never came back via the list....apologies if you receive it twice. -----Original Message----- From: George Tsirtsis Sent: Friday, February 08, 2002 11:41 AM To: 'mobile-ip@sunroof.eng.sun.com' Cc: 'Phil Roberts'; 'Basavaraj Patil' Subject: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis interpretation question So my question to this group is still the same. Mobile IPv4 has 3 modes of operation. - 1. using CoAs, registration via FA - 2. using collocated addresses, registration directly to HA - 3. using collocated addresses, registration via FA (Rbit) According to current text an FA can be configured: A. To support case 1 only, while case 2 is transparent to it (FA does not care) B. To support case 1 & 3. Yet, the spec does not allow an FA to support case 3 ONLY; i.e.: send an FA Advertisement with Rbit set and no CoA. This would allow the deployment of lightweght FAs that do not have to do encapsulation/decapsulation but can control access into the network. This is especially useful when the mobiles are either slow moving or when link layer mobility enables Collocated addresses to be valid for long periods of time. If the applicability is not clear I could use 5min in Minneapolis to illustrate the use of this. Regards George -----Original Message----- From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] Sent: Thursday, February 07, 2002 11:25 PM To: Mobile-Ip (E-mail) Subject: Re: [mobile-ip] RFC2002bis interpretation question Hello, On Tue, 5 Feb 2002, George Tsirtsis wrote: > Hi all > > I am trying to figure out how implementers have interpreted the Rbit part of > rfc2002. I have asked a few people privately and I do not get identical > feedback so some discussion here maybe helpful. > > I remind you that if the Rbit is set in a Foreign Agent Advertisement the > MIP client is required to register through the Foreign Agent even if it has > access to a collocated address... > But what does that mean exactly? > 1. Should the client register its Collocated care-of-address (and thus > ignore the advertized CoA) but send the registration request to the FA and > the FA forwards it to the HA? > 2. Should the client register with the care-of-address advertised in the > advertisement? If this is the case, can the mobile now also use a collocated > care of address as source address for some traffic?? > > Is one of the above the "correct" behavior? How does your MIP client > implementation behave and what does your Foreign Agent implementation > expect? > I have not completely following the emails posted in this regard. So please bear with me if this has already been mentioned. section 3.7.2.1 of rfc2002 bis8 indicates (indirectly) that the FA could receive requests in which the D bit is set and the COA is not one of its own, and that it should not reject these requests. This would probably happen when a MN with a co-located COA acknowledges the R bit in the advertisement and registers via the FA. As far as the FA goes, it looks like it should be able to handle both types of behaviour. Of course, behaviour #2 would appear to the FA like a "regular" reg request. Siva From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 11:23:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13471 for ; Fri, 8 Feb 2002 11:23:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03214; Fri, 8 Feb 2002 09:22:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13560; Fri, 8 Feb 2002 08:20:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GAZBJ000651 for ; Fri, 8 Feb 2002 08:10:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GAZ8m000650 for mobile-ip-dist; Fri, 8 Feb 2002 08:10:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GADBJ000616 for ; Fri, 8 Feb 2002 08:10:14 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g189IPM12075; Fri, 8 Feb 2002 10:18:25 +0100 (MET) Date: Fri, 8 Feb 2002 10:14:25 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Vijay Devarapalli Cc: Erik Nordmark , Jari Arkko , basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C631BEA.227F75B6@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay, > I would say RR+DH is a better BU Authorization mechanism over RR, > but not as good as RR+CGA. So it is still an option over RR and > an MN should be able to select this mechanism. The design team didn't find significant differences but perhaps we didn't look carefully enough. Do you have threats that RR+DH can handle that RR can not handle? > If a MN's home address ever changes, then it gets a new certificate. > Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a > few domains (eg a corporate network). And this should be the most > preferred BU Authorization mechanism whereever it is available. The details of why I think is unworkable in practise is a bit different depending on the nature of the CA. If you look at the case of a large commercial CA, how could they possibly verify that a Home Address is assigned to box "owned" by Erik.Nordmark@sun.com (where that string is the name in the certificate)? Doing this in order to initially list the Home Address in the cert doesn't seem tractable. Doing it every day when I decide to get an new RFC 3041 address seems even less likely to work. What about the case when my ISP or company renumbers the prefix on my link - how does the CA ever find out so that they can revoke that certificate which now has a stale Home Address? If the case is that there is a more local CA (e.g. a company or an ISP running their own CA) I think there are also hard problems in creating the initial association between the certificate name and the Home Address placed in the certificate. But it might be possible to throw people at the problem (i.e. I would get a phone call asking for verification or somebody would visit me in person). But with a more local CA the question is how the trust is established between a CN using one CA and a MN using another CA. So I think this is a serious case matching the quote In theory there is no difference between theory and practise. In practise there is. > > I don't personally understand AAA-based authorization of binding updates would > > entail and whether it would fit into the architecture of AAA that the AAAwg > > is assuming to comment on that. > > Trust me. It will work. We will soon see AAA-based BU authorization > mechanisms. (again wherever possible, this should be more preferred > than RR, RR+DH, RR+CGA mechanism). I didn't say it could not be built. I'm questioning whether it fits into the architecture of AAA (that architecture is that clients authenticate to the infrastructure - and not that the infrastructure helps clients authenticate eachother. The latter sounds a lot more like a PKI. While it's possible to make the AAA become a PKI as well it might not be the optimal solution). I also have concerns about what it would mean for RFC 3041 temporary style addresses (when a user wants to minimize the relationship between the IP address used at the moment and any longer term name associated with the user). I all fairness, I think all infrastructure-based solutions (e.g. PKI and AAA) raise concerns in this area of enabling anonymity. > Basically the above reinforces, what I had thought. The "1 bit method" > is very specific to RR+CGA mechanism. It does not help in any way > to select the other strong BU Authorization methods. > > I want to emphasize one point again. CGA is good for IPv6 and ND. I am > not against it. And the "1 bit mechanism" is good for distinguishing a > CGA address from another address. But that does not make it the best > mechanism to select from a bunch of BU Authorization mechanisms. I think you are correct on both of those points. Question is whether that is a good thing or a bad thing. If there was e.g. a baked spec on how AAA based authorization would work at an abstract level (no need for packet formats) and with what assumptions it might be possible to see what type of mechanisms would make sense for policy control in that space and how it would interact with the MIP nodes (MNs and CNs) that are not part of that AAA infrastructure. But until then at least me personally feel like I'm stumbling in the dark when it comes to AAA-based authorization of BUs. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 11:23:28 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13485 for ; Fri, 8 Feb 2002 11:23:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00612; Fri, 8 Feb 2002 08:22:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14096; Fri, 8 Feb 2002 08:21:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GANBJ000646 for ; Fri, 8 Feb 2002 08:10:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GAMqM000645 for mobile-ip-dist; Fri, 8 Feb 2002 08:10:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GADBN000616 for ; Fri, 8 Feb 2002 08:10:17 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g188wYM08294; Fri, 8 Feb 2002 09:58:34 +0100 (MET) Date: Fri, 8 Feb 2002 09:53:56 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Vijay Devarapalli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net, basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <3C62FD24.4C8AD26@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > As I said before, my only problem is with this "1 bit method" in > the IPv6 address. when you say "pattern of bits", how many bits can > you reserve in the IPv6 address to take into account all the stronger > BU Authorization metods that could be specified in the future? As > far as I know, I already need 3 bits to select a mechanism among > 5 mechanisms. It would be difficult to justify reserving enough > bits in the IPv6 host id space so that Mobile IPv6 could select > from among several BU Authorization mechanisms. Vijay, Sorry for not being clear. By "pattern of bits" as was just hinting that it might not be possible to get one bit (leaving 63 bits to play with for CGA) but instead get e.g. universal = 0, group = 0 i.e. leaving 62 bits for CGA to play with. I think I responded to the "need more bits because there are more mechanisms" in a later mail my yesterday. > For CGA, maybe the "1 bit method" is the best selection mechanism. > And this should be specified as part of the "CGA for MIPv6" spec. Another mail I sent yesterday points out why the bit needs to be specified now in order to prevent beating down attacks. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 11:23:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13497 for ; Fri, 8 Feb 2002 11:23:31 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09017; Fri, 8 Feb 2002 09:22:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13575; Fri, 8 Feb 2002 08:20:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GAMBJ000644 for ; Fri, 8 Feb 2002 08:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GAMGU000643 for mobile-ip-dist; Fri, 8 Feb 2002 08:10:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GADBL000616 for ; Fri, 8 Feb 2002 08:10:15 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g188wXM08290; Fri, 8 Feb 2002 09:58:33 +0100 (MET) Date: Fri, 8 Feb 2002 09:48:10 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com, Charlie Perkins , Erik Nordmark In-Reply-To: "Your message with ID" <200202071945.g17JjCg80994@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => so my D/Z tunneling and IPsec interaction note can become useful > if the D/Z tunneling receives more interest. > (summary of my note: the important point is the order of the crypto > transform and the D/Z compression, and AH gives more choice because > the two operations can commute). Francis, In your opinion are all open issues with the interaction of D/Z tunneling solved? (And it is just an issue of putting the right words in the D/Z internet-draft.) Or are there additional unsolved issues in this area? Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 11:23:36 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13509 for ; Fri, 8 Feb 2002 11:23:35 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10716; Fri, 8 Feb 2002 09:23:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13838; Fri, 8 Feb 2002 08:21:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GCWBJ000704 for ; Fri, 8 Feb 2002 08:12:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GCWmG000703 for mobile-ip-dist; Fri, 8 Feb 2002 08:12:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GCFBJ000679 for ; Fri, 8 Feb 2002 08:12:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04840 for ; Fri, 8 Feb 2002 07:48:48 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15506 for ; Fri, 8 Feb 2002 08:48:46 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g18FmhB08625; Fri, 8 Feb 2002 17:48:43 +0200 Date: Fri, 8 Feb 2002 17:48:42 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: magma@innovationslab.net, , Subject: [mobile-ip] Re: I-D ACTION:draft-jelger-mssmsv6-00.txt In-Reply-To: <200201231424.JAA09722@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, 23 Jan 2002 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Supporting Mobile SSM Sources for IPv6 (MSSMSv6) > Author(s) : C. Jelger, T. Noel > Filename : draft-jelger-mssmsv6-00.txt > Pages : 11 > Date : 22-Jan-02 A few comments I made on a flight. 2.1.1 Advantages and drawbacks [...]. A failure of the HA would cause multiple multicast delivery disruptions. ==> Failure of the HA would, AFAICS, cause disruptions for MIP traffic too: so nothing new there. Third, the processing task of the HA increases with the number of mobile sources it serves, thus reducing the efficiency of the multicast delivery and increasing the probability of a failure. ==> How many Mobile multicast-sourcing nodes would you expect a random HA will have to serve? ==> In general, this mechanism makes delivery more unstable: moving sources send BU's to recipients. Recipients must authenticate those BU's (e.g. with return routability (with multicast??)). You force the burden on multiple recipients, when the same could be done at one place, mobile source. ==> Also, in multicast I don't think it's that usual that sending latency is that big a problem: communication is mostly one-way. 2.2.1 Source handover When a mobile SSM source moves into a new subnet, it must inform the multicast receivers about its new Care_of-Address (nCoA). ==> inform how? ==> what about recipients not implementing BU processing or not having it enabled? the BU message must be encapsulated towards the old Access Router (oAR) ==> how is oAR known? Note that remembering link-local address from route advertisements is not enough (:-) This notification could be done via the Multicast Source Notification of Interest Protocol (MSNIP) but it is out of the scope of this document. ==> Add a reference to MSNIP draft. ==> I'm a bit curious why exactly this is "out of scope"... ==> Around this place in the draft there seems to be significant duplication of tex with section 2.2.3. SHOULD forward the multicast datagrams sent by the MN from the new subnet onto its local interfaces (e.g. interfaces binded with the ==> s/binded/bound/ 3. Implementation requirements ==> You forget new requirements for oAR's 4. Security Considerations The proposed protocol MSSMSv6 does not introduce new security problems that those already present in MIPv6 and PIM-SSM. ==> A daring thing to say. ==> How is the tunnel between oAR and MN established? Does oAR have to blindly decapsulate the packets from everywhere? This is a huge risk. Remember that oAR doesn't need to know _anything_ about nodes visiting its subnet (it's not IPv4 Foreign Agent)... ==> About BU with optional SSM destination option. Could MN cause recipient that marginally trusts it join new SSM sessions (nothing related to what MN is originating, for example) and possibly subsequently have it kill old ones? ==> BU with multicast destination will need a _lot_ more thorough analysis I think. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:27:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21159 for ; Fri, 8 Feb 2002 14:27:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16536; Fri, 8 Feb 2002 12:27:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08335; Fri, 8 Feb 2002 10:46:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18Gh0BJ001530 for ; Fri, 8 Feb 2002 08:43:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Gh0dZ001529 for mobile-ip-dist; Fri, 8 Feb 2002 08:43:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GgPBJ001520 for ; Fri, 8 Feb 2002 08:42:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25572 for ; Fri, 8 Feb 2002 07:10:39 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26828 for ; Fri, 8 Feb 2002 07:10:37 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g18FAZu08355; Fri, 8 Feb 2002 17:10:36 +0200 Date: Fri, 8 Feb 2002 17:10:35 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: marcelo@it.uc3m.es, Subject: Re: [mobile-ip] draft on random interface identifiers available In-Reply-To: <3C5EAE12.DA5F9400@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 4 Feb 2002, Ignacio Soto Campos wrote: > http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt I'll add my 0.02c even though these have probably been at least partially covered now. General note about methodology: I'd suggest putting the derivation of probabilities into an appendix. 5. Security Considerations. This draft does no introduce new security risks. What's more, random generation of interface identifiers can enable improved anonymity features by allowing interface identifier generation each time a node joins a new link, what can prevents tracing. ==> Heard about privacy extensions? :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:28:51 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21234 for ; Fri, 8 Feb 2002 14:28:50 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17161; Fri, 8 Feb 2002 11:28:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16240; Fri, 8 Feb 2002 11:08:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GxsCD001966 for ; Fri, 8 Feb 2002 09:01:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Gqisb001826 for mobile-ip-dist; Fri, 8 Feb 2002 08:52:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18Gh6BR001532 for ; Fri, 8 Feb 2002 08:52:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26787 for ; Thu, 7 Feb 2002 15:43:38 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11199 for ; Thu, 7 Feb 2002 15:43:37 -0800 (PST) Received: from ipunplugged.com (wormhole.local.ipunplugged.com [213.88.134.210]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id AAA06806 for ; Fri, 8 Feb 2002 00:41:38 +0100 Message-ID: <3C631108.1000406@ipunplugged.com> Date: Fri, 08 Feb 2002 00:43:04 +0100 From: Hans =?ISO-8859-1?Q?Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question References: <8C92E23A3E87FB479988285F9E22BE465ABAC9@ftmail> <3C62C2A7.A0AE46D1@cisco.com> Content-Type: multipart/alternative; boundary="------------020800020304020709030802" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------020800020304020709030802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit - draft-ietf-mobileip-rfc2002-bis-08.txt passed rfc-editor and is in auth48 (even though it's been there for quite some time). It's unlikely to change before publication. I can't remember now if it goes for draft standard or stays proposed. - There seams to be multiple interoperable implementations of of both variants. The above facts indicate that whither we like it or not, things are likely to stay the same. But RFC 2119 is there for a reason. It's unclear from the specs what is required from conforming MN, FA and HA implementations. It's also unclear what requirement level the function have, e.g. if it's a SHOULD or MAY for a FA to accept registration replies with coa set to anything other than advertised coa. I'm quite sure that it from the crowd discussing this is possible to pick a combination of MN, FA and HA that won't interoperate. So, some SHOULD and MAY would have been nice to have. Vagueness is not a good design strategy when writing RFCs. Not a big problem though. Regards /// Hasse kleung wrote: >George Tsirtsis wrote: > >>How does a FA indicate that it doesn't >>support "encaps/decaps services based on CoA"? >> >>GT> This is easy. One way would be to allow an FA advert to have Rbit set >>but does not include a CoA. The Mobile Node would then see that there is no >>CoA so it needs to get a collocated address and since the Rbit is set the >>node will have to register it through the FA. >> > >Since FA supports tunneling, why shouldn't FA advert its CoA? Then >it's up to MNs to decide to use CCoA or FA CoA. > >The R bit is for FA access (or MIP service authorization) control. The >CoA is not meant for tunneling control, but merely advertised service. >But the above scheme use CoA as tunneling control. > >As said, MNs will likely use the FA CoA when advert received. Though >I think the generic properties of existing spec allows flexibility for MN to >choose where it wants tunnel termination. > >The access authentication/authorization scheme may factor in MN's >decision since it may go through 2 levels (802.1x and MIP) when >CCOA is used. Of course, FA may decide to bypass MIP authentication >when it sees RRQ with D bit set and external CoA if it is aware that >802.1x already occurred. > >Flexibility comes complexity. :) But forcing MNs to use FA COA >with R bit advertised is rigid, though simpler for the common scenario. > >So if we leave spec as is, then MNs choose either CCoA or FA CoA >when it sends RRQ to FA, which advert the R bit. Is this ambiguous? > >Seems like the new proposal is to enforce CCOA tunneling by removing >COA in advert. And on the other end, proposal to mandate that MN >must use FA COA. Both cases when R bit set in advert. Both takes >the right to choose from MN. This is what we want, right? > >Kent > > > > >>We have never run into the problem because our MN always switch to FA >>registered if a adverticements comes out, regardless of R-bit. So, an >>interop with us would be pointless. >> >>If someone perceives to run co-located despite our agents >>adverticements, they will be sean as using our simple IP service and not >>mobile IP. The packets will be treated according to the policy >>configured in the FA (not really a FA in that case, more of a ACD >>(Access Control Device)) and if he is authenticated by some other means >>(like web-login or 802.1x). >> >>My private feeling is that there are no advantage for the MN to run >>co-located over registered with FA. And there is no way for a FA to tell >>that he proposes co-located mode. So, in my mind it's already set, adn >>instead the spec could be clarified to disallow registering with >>co-located address to FA. >> >>GT> No, no, now you are totally missing the point of the Rbit. Just because >>some implementers chose to prefer CoAs if they can get them it does not mean >>that CCoAs are not needed and it does not mean that the FA should not be >>able to request registration. The Rbit is useful but it is weakly specified >>which unfortunately allows you to think that is not needed. >> >>George >> > --------------020800020304020709030802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit - draft-ietf-mobileip-rfc2002-bis-08.txt passed rfc-editor and is in auth48 (even though it's been there for quite some time). It's unlikely to change before publication. I can't remember now if it goes for draft standard or stays proposed.
- There seams to be multiple interoperable implementations of of both variants.

The above facts indicate that whither we like it or not, things are likely to stay the same.

But RFC 2119 is there for a reason. It's unclear from the specs what is required from conforming MN, FA and HA implementations. It's also unclear what requirement level the function have, e.g. if it's a SHOULD or  MAY for a FA to accept registration replies with coa set to anything other than advertised coa. I'm quite sure that it from the crowd discussing this is possible to pick a combination of MN, FA and HA that won't interoperate. So, some SHOULD and MAY would have been nice to have. Vagueness is not a good design strategy when writing RFCs. Not a big problem though.  

Regards
/// Hasse

kleung wrote:
George Tsirtsis wrote:

How does a FA indicate that it doesn't
support "encaps/decaps services based on CoA"?

GT> This is easy. One way would be to allow an FA advert to have Rbit set
but does not include a CoA. The Mobile Node would then see that there is no
CoA so it needs to get a collocated address and since the Rbit is set the
node will have to register it through the FA.


Since FA supports tunneling, why shouldn't FA advert its CoA?  Then
it's up to MNs to decide to use CCoA or FA CoA.

The R bit is for FA access (or MIP service authorization) control.   The
CoA is not meant for tunneling control, but merely advertised service.
But the above scheme use CoA as tunneling control.

As said, MNs will likely use the FA CoA when advert received.  Though
I think the generic properties of existing spec allows flexibility for MN to
choose where it wants tunnel termination.

The access authentication/authorization scheme may factor in MN's
decision since it may go through 2 levels (802.1x and MIP) when
CCOA is used.  Of course, FA may decide to bypass MIP authentication
when it sees RRQ with D bit set and external CoA if it is aware that
802.1x already occurred.

Flexibility comes complexity.  :)  But forcing MNs to use FA COA
with R bit advertised is rigid, though simple
r for the common scenario.

So if we leave spec as is, then MNs choose either CCoA or FA CoA
when it sends RRQ to FA, which advert the R bit.  Is this ambiguous?

Seems like the new proposal is to enforce CCOA tunneling by removing
COA in advert.  And on the other end, proposal to mandate that MN
must use FA COA.  Both cases when R bit set in advert.  Both takes
the right to choose from MN.  This is what we want, right?

Kent




We have never run into the problem because our MN always switch to FA
registered if a adverticements comes out, regardless of R-bit. So, an
interop with us would be pointless.

If someone perceives to run co-located despite our agents
adverticements, they will be sean as using our simple IP service and not
mobile IP. The packets will be treated according to the policy
configured in the FA (not really a FA in that case, more of a ACD
(Access Control Device)) and if he is authenticated by some other means
(like web-login or 802.1x).

My private feeling is that there are no advantage for the MN to run
co-located over registered with FA. And there is no way for a FA to tell
that he proposes co-located mode. So, in my mind it's already set, adn
instead the spec could be clarified to disallow registering with
co-located address to FA.

GT> No, no, now you are totally missing the point of the Rbit. Just becaus
e
some implementers chose to prefer CoAs if they can get them it does not mean
that CCoAs are not needed and it does not mean that the FA should not be
able to request registration. The Rbit is useful but it is weakly specified
which unfortunately allows you to think that is not needed.

George


--------------020800020304020709030802-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:33:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21481 for ; Fri, 8 Feb 2002 14:33:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15975; Fri, 8 Feb 2002 12:32:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21367; Fri, 8 Feb 2002 11:22:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18H76BJ002463 for ; Fri, 8 Feb 2002 09:07:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18H766h002462 for mobile-ip-dist; Fri, 8 Feb 2002 09:07:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18H6xBJ002437 for ; Fri, 8 Feb 2002 09:07:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17909 for ; Fri, 8 Feb 2002 09:07:15 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06527 for ; Fri, 8 Feb 2002 10:07:15 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g18H7Dv27187 for ; Fri, 8 Feb 2002 11:07:13 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MB48Y2Z>; Fri, 8 Feb 2002 11:07:13 -0600 Message-ID: From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis in terpretation question Date: Fri, 8 Feb 2002 11:07:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B0C3.0CCBAAF0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B0C3.0CCBAAF0 Content-Type: text/plain; charset="iso-8859-1" I don't think that this is a right approach to handle this issue. Assume that the FA is sending an AA with 0 coa and a MN is trying to get co-located care of address but their is no currently one available. What the MN will do in this case? Also, if some other MNs want to register with the foreign-agent care-of address The choice of the mobile node to use a foreign agent care-of address or/and co-located care-of address is a network policy issue which should not be handled by the current spec. We should speed up the process of letting the current spec to go as standard and then we can handle these minor issues in separate docs. -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: Friday, February 08, 2002 8:20 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis in terpretation question I sent this many hours ago but never came back via the list....apologies if you receive it twice. -----Original Message----- From: George Tsirtsis Sent: Friday, February 08, 2002 11:41 AM To: 'mobile-ip@sunroof.eng.sun.com' Cc: 'Phil Roberts'; 'Basavaraj Patil' Subject: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis interpretation question So my question to this group is still the same. Mobile IPv4 has 3 modes of operation. - 1. using CoAs, registration via FA - 2. using collocated addresses, registration directly to HA - 3. using collocated addresses, registration via FA (Rbit) According to current text an FA can be configured: A. To support case 1 only, while case 2 is transparent to it (FA does not care) B. To support case 1 & 3. Yet, the spec does not allow an FA to support case 3 ONLY; i.e.: send an FA Advertisement with Rbit set and no CoA. This would allow the deployment of lightweght FAs that do not have to do encapsulation/decapsulation but can control access into the network. This is especially useful when the mobiles are either slow moving or when link layer mobility enables Collocated addresses to be valid for long periods of time. If the applicability is not clear I could use 5min in Minneapolis to illustrate the use of this. Regards George -----Original Message----- From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] Sent: Thursday, February 07, 2002 11:25 PM To: Mobile-Ip (E-mail) Subject: Re: [mobile-ip] RFC2002bis interpretation question Hello, On Tue, 5 Feb 2002, George Tsirtsis wrote: > Hi all > > I am trying to figure out how implementers have interpreted the Rbit part of > rfc2002. I have asked a few people privately and I do not get identical > feedback so some discussion here maybe helpful. > > I remind you that if the Rbit is set in a Foreign Agent Advertisement the > MIP client is required to register through the Foreign Agent even if it has > access to a collocated address... > But what does that mean exactly? > 1. Should the client register its Collocated care-of-address (and thus > ignore the advertized CoA) but send the registration request to the FA and > the FA forwards it to the HA? > 2. Should the client register with the care-of-address advertised in the > advertisement? If this is the case, can the mobile now also use a collocated > care of address as source address for some traffic?? > > Is one of the above the "correct" behavior? How does your MIP client > implementation behave and what does your Foreign Agent implementation > expect? > I have not completely following the emails posted in this regard. So please bear with me if this has already been mentioned. section 3.7.2.1 of rfc2002 bis8 indicates (indirectly) that the FA could receive requests in which the D bit is set and the COA is not one of its own, and that it should not reject these requests. This would probably happen when a MN with a co-located COA acknowledges the R bit in the advertisement and registers via the FA. As far as the FA goes, it looks like it should be able to handle both types of behaviour. Of course, behaviour #2 would appear to the FA like a "regular" reg request. Siva ------_=_NextPart_001_01C1B0C3.0CCBAAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis = in terpretation question

I don't think that this is a right approach to handle = this issue. Assume that the FA is sending an AA with 0 coa and a MN is = trying to get co-located care of address but their is no currently one = available. What the MN will do in this case? Also, if some other MNs = want to register with the foreign-agent care-of address

The choice of the mobile node to use a foreign agent = care-of address or/and co-located care-of address is a network policy = issue which should not be handled by the current spec. We should speed = up the process of letting the current spec to go as standard and then = we can handle these minor issues in separate docs.

-----Original Message-----
From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com= ]
Sent: Friday, February 08, 2002 8:20 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: change Proposal for RFC2002bis- RE: = [mobile-ip] RFC2002bis
in terpretation question


I sent this many hours ago but never came back via = the list....apologies if
you receive it twice.

-----Original Message-----
From: George Tsirtsis
Sent: Friday, February 08, 2002 11:41 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Cc: 'Phil Roberts'; 'Basavaraj Patil'
Subject: change Proposal for RFC2002bis- RE: = [mobile-ip] RFC2002bis
interpretation question


So my question to this group is still the = same.

Mobile IPv4 has 3 modes of operation.
- 1. using CoAs, registration via FA
- 2. using collocated addresses, registration = directly to HA
- 3. using collocated addresses, registration via FA = (Rbit)

According to current text an FA can be = configured:

A. To support case 1 only, while case 2 is = transparent to it (FA does not
care)
B. To support case 1 & 3.

Yet, the spec does not allow an FA to support case 3 = ONLY; i.e.: send an FA
Advertisement with Rbit set and no CoA. This would = allow the deployment of
lightweght FAs that do not have to do = encapsulation/decapsulation but can
control access into the network. This is especially = useful when the mobiles
are either slow moving or when link layer mobility = enables Collocated
addresses to be valid for long periods of time. If = the applicability is not
clear I could use 5min in Minneapolis to illustrate = the use of this.

Regards

George


-----Original Message-----
From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com]
Sent: Thursday, February 07, 2002 11:25 PM
To: Mobile-Ip (E-mail)
Subject: Re: [mobile-ip] RFC2002bis interpretation = question



Hello,


On Tue, 5 Feb 2002, George Tsirtsis wrote:

> Hi all
>
> I am trying to figure out how implementers have = interpreted the Rbit part
of
> rfc2002. I have asked a few people privately = and I do not get identical
> feedback so some discussion here maybe helpful. =
>
> I remind you that if the Rbit is set in a = Foreign Agent Advertisement the
> MIP client is required to register through the = Foreign Agent even if it
has
> access to a collocated address...
> But what does that mean exactly?
> 1. Should the client register its Collocated = care-of-address (and thus
> ignore the advertized CoA) but send the = registration request to the FA and
> the FA forwards it to the HA?
> 2. Should the client register with the = care-of-address advertised in the
> advertisement? If this is the case, can the = mobile now also use a
collocated
> care of address as source address for some = traffic??
>
> Is one of the above the "correct" = behavior? How does your MIP client
> implementation behave and what does your = Foreign Agent implementation
> expect?
>

I have not completely following the emails posted in = this regard. So
please bear with me if this has already been = mentioned.

section 3.7.2.1 of rfc2002 bis8 indicates = (indirectly) that the FA
could receive requests in which the D bit is set and = the COA is not
one of its own, and that it should not reject these = requests.

This would probably happen when a MN with a = co-located COA
acknowledges the R bit in the advertisement and = registers via the FA.

As far as the FA goes, it looks like it should be = able to handle
both types of behaviour. Of course, behaviour #2 = would appear to the
FA like a "regular" reg request.


Siva


------_=_NextPart_001_01C1B0C3.0CCBAAF0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:47:36 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22121 for ; Fri, 8 Feb 2002 14:47:35 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22339; Fri, 8 Feb 2002 11:47:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23754; Fri, 8 Feb 2002 11:27:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HO0BJ004003 for ; Fri, 8 Feb 2002 09:24:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18HNxOY004002 for mobile-ip-dist; Fri, 8 Feb 2002 09:23:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HNdBJ003907 for ; Fri, 8 Feb 2002 09:23:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14949 for ; Fri, 8 Feb 2002 01:35:48 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00667 for ; Fri, 8 Feb 2002 02:35:47 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g189Zha19822; Fri, 8 Feb 2002 10:35:43 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA17204; Fri, 8 Feb 2002 10:35:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g189Zhg84695; Fri, 8 Feb 2002 10:35:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202080935.g189Zhg84695@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, Charlie Perkins Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Fri, 08 Feb 2002 09:48:10 +0100. Date: Fri, 08 Feb 2002 10:35:43 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => so my D/Z tunneling and IPsec interaction note can become useful > if the D/Z tunneling receives more interest. > (summary of my note: the important point is the order of the crypto > transform and the D/Z compression, and AH gives more choice because > the two operations can commute). In your opinion are all open issues with the interaction of D/Z tunneling solved? => there are at least no more unknown. I don't know exactly what is the meaning of "solved" in this context (the important point is to know what are the interactions, what are the differences between IPsec and IPsec with D/Z tunneling and what are possible choices if we'd like to go further). (And it is just an issue of putting the right words in the D/Z internet-draft.) => mainly. Or are there additional unsolved issues in this area? => there is nothing really unsolved but there is a possible choice for AH in tunnel mode, i.e. we can define a D/Z tunnel mode for AH (not for ESP or IPcomp) which has the same security properties than the standard tunnel mode for AH but less overhead in bytes. The problem is that AH is not very popular in the IPsec WG and this topics is not really in the IPv6 WG scope (i.e. this is a problem for the IESG :-). In some words, is the game worth the candle? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:48:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22144 for ; Fri, 8 Feb 2002 14:48:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19232; Fri, 8 Feb 2002 12:47:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24196; Fri, 8 Feb 2002 11:28:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HTrEl004646 for ; Fri, 8 Feb 2002 09:31:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18GQqgo001163 for mobile-ip-dist; Fri, 8 Feb 2002 08:26:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18GQiBJ001140 for ; Fri, 8 Feb 2002 08:26:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00182 for ; Fri, 8 Feb 2002 03:41:22 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12822 for ; Fri, 8 Feb 2002 04:41:22 -0700 (MST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1LTW77F7>; Fri, 8 Feb 2002 06:41:21 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABAD1@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Phil Roberts'" , "'Basavaraj Patil'" Subject: change Proposal for RFC2002bis- RE: [mobile-ip] RFC2002bis interp retation question Date: Fri, 8 Feb 2002 06:41:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: So my question to this group is still the same. Mobile IPv4 has 3 modes of operation. - 1. using CoAs, registration via FA - 2. using collocated addresses, registration directly to HA - 3. using collocated addresses, registration via FA (Rbit) According to current text an FA can be configured: A. To support case 1 only, while case 2 is transparent to it (FA does not care) B. To support case 1 & 3. Yet, the spec does not allow an FA to support case 3 ONLY; i.e.: send an FA Advertisement with Rbit set and no CoA. This would allow the deployment of lightweght FAs that do not have to do encapsulation/decapsulation but can control access into the network. This is especially useful when the mobiles are either slow moving or when link layer mobility enables Collocated addresses to be valid for long periods of time. If the applicability is not clear I could use 5min in Minneapolis to illustrate the use of this. Regards George -----Original Message----- From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] Sent: Thursday, February 07, 2002 11:25 PM To: Mobile-Ip (E-mail) Subject: Re: [mobile-ip] RFC2002bis interpretation question Hello, On Tue, 5 Feb 2002, George Tsirtsis wrote: > Hi all > > I am trying to figure out how implementers have interpreted the Rbit part of > rfc2002. I have asked a few people privately and I do not get identical > feedback so some discussion here maybe helpful. > > I remind you that if the Rbit is set in a Foreign Agent Advertisement the > MIP client is required to register through the Foreign Agent even if it has > access to a collocated address... > But what does that mean exactly? > 1. Should the client register its Collocated care-of-address (and thus > ignore the advertized CoA) but send the registration request to the FA and > the FA forwards it to the HA? > 2. Should the client register with the care-of-address advertised in the > advertisement? If this is the case, can the mobile now also use a collocated > care of address as source address for some traffic?? > > Is one of the above the "correct" behavior? How does your MIP client > implementation behave and what does your Foreign Agent implementation > expect? > I have not completely following the emails posted in this regard. So please bear with me if this has already been mentioned. section 3.7.2.1 of rfc2002 bis8 indicates (indirectly) that the FA could receive requests in which the D bit is set and the COA is not one of its own, and that it should not reject these requests. This would probably happen when a MN with a co-located COA acknowledges the R bit in the advertisement and registers via the FA. As far as the FA goes, it looks like it should be able to handle both types of behaviour. Of course, behaviour #2 would appear to the FA like a "regular" reg request. Siva From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:50:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22200 for ; Fri, 8 Feb 2002 14:50:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20356; Fri, 8 Feb 2002 12:49:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27726; Fri, 8 Feb 2002 11:48:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HisG5006339 for ; Fri, 8 Feb 2002 09:46:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18HbnJT005384 for mobile-ip-dist; Fri, 8 Feb 2002 09:37:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HVXBL005039 for ; Fri, 8 Feb 2002 09:37:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22656 for ; Fri, 8 Feb 2002 09:18:59 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04134 for ; Fri, 8 Feb 2002 10:18:58 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 2131443234; Fri, 8 Feb 2002 18:18:57 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id CB96D99E6E; Fri, 8 Feb 2002 18:18:56 +0100 (CET) Received: from varpa.it.uc3m.es (root@varpa.it.uc3m.es [163.117.139.253]) by arpa.it.uc3m.es (8.9.3/8.9.3) with ESMTP id SAA17771; Fri, 8 Feb 2002 18:18:56 +0100 Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by varpa.it.uc3m.es (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id SAA04359; Fri, 8 Feb 2002 18:18:56 +0100 X-Authentication-Warning: varpa.it.uc3m.es: Host avispa.it.uc3m.es [163.117.139.178] claimed to be avispa From: "marcelo bagnulo" To: "Pekka Savola" , Cc: , Subject: RE: [mobile-ip] draft on random interface identifiers available Date: Fri, 8 Feb 2002 18:24:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Mensaje original----- > De: Pekka Savola [mailto:pekkas@netcore.fi] > Enviado el: viernes, 08 de febrero de 2002 16:11 > 5. Security Considerations. > > This draft does no introduce new security risks. What's more, random > generation of interface identifiers can enable improved anonymity > features by allowing interface identifier generation each time a node > joins a new link, what can prevents tracing. > > ==> Heard about privacy extensions? :-) > agreed, a reference to privacy extensions should be included in this section. We should also include a reference to CGA. thanks, m From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:51:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22252 for ; Fri, 8 Feb 2002 14:51:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21469; Fri, 8 Feb 2002 12:51:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04095; Fri, 8 Feb 2002 11:50:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IfkBJ010055 for ; Fri, 8 Feb 2002 10:41:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Ifj4d010052 for mobile-ip-dist; Fri, 8 Feb 2002 10:41:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IfYBJ010030 for ; Fri, 8 Feb 2002 10:41:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16836 for ; Fri, 8 Feb 2002 10:41:50 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23146 for ; Fri, 8 Feb 2002 10:41:49 -0800 (PST) Received: from jariws1 ([62.248.145.160]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020208184148.JPYO24910.fep01-app.kolumbus.fi@jariws1>; Fri, 8 Feb 2002 20:41:48 +0200 Message-ID: <016801c1b0d0$4cd506c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Rajeev Koodli" , Cc: , References: <3C6412FC.EB7AEDD2@iprg.nokia.com> Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Fri, 8 Feb 2002 20:42:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Here is a simple proposal to allow selection of alternative BU authorization > schemes. Perhaps you folks have already thought about it.. In any case, I would > appreciate your feedback. Thanks for your proposal! We should probably include it in a new version of the writeup. Read on for the analysis... > The objective is to securely indicate to the CN the MN's intention to > use a "better BU method". For this, why not include a signed hash covering a > "selector" byte in the RR messages ? For instance, > > - the MN sends Nonce N1, and an 8-bit integer "selector" > set to "better BU" mechanism in 1b. > > - the MN sends Nonce N2, and a signed hash of N1, N2, the > "selector" field and the MN's Public Key in 1a. > > -the CN would verify the hash before accepting the method > outlined in the "selector" field for BU authorization. > > The selector field can take different values including RR only, RR+DH, > RR+CGA etc. This appears to have the following problem: an attacker, if he is capable of defeating RR, must therefore be on the HA - CN path. The attacker sends a spoofed 1a/1b with selector set to "RR". CN believes this, and noone ever needed to break public key hashes, as it would have been necessary in the case of a bit in the address indicating that CGA should be used. Naturally, the attacker would still have to be on the HA - CN path, with all of its implications. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 14:53:50 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22304 for ; Fri, 8 Feb 2002 14:53:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00691; Fri, 8 Feb 2002 12:53:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05732; Fri, 8 Feb 2002 11:52:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JTvTT014541 for ; Fri, 8 Feb 2002 11:33:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18IjFse010511 for mobile-ip-dist; Fri, 8 Feb 2002 10:45:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IiBBZ010241 for ; Fri, 8 Feb 2002 10:44:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14262 for ; Fri, 8 Feb 2002 10:35:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01163 for ; Fri, 8 Feb 2002 11:35:23 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA18579 for ; Fri, 8 Feb 2002 10:35:22 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18IZL310917 for ; Fri, 8 Feb 2002 10:35:21 -0800 X-mProtect:  Fri, 8 Feb 2002 10:35:21 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdURRrpk; Fri, 08 Feb 2002 10:35:08 PST Message-ID: <3C641A3A.DB40F913@iprg.nokia.com> Date: Fri, 08 Feb 2002 10:34:34 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [repost] for some reason, this mail did not make it to the list. Erik has already responded to this mail. Vijay -------- Original Message -------- Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Thu, 07 Feb 2002 16:29:30 -0800 From: Vijay Devarapalli To: Erik Nordmark CC: Jari Arkko ,basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com References: Hi Erik, Jari, Erik Nordmark wrote: > > 3. Assume, I have more than 2 mechanisms for BU authorization > > (RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here? > > For this, (IMO) the obvious thing would be a set of bits > > in the Binding Update. You dont have to specify this now. We > > can do this later using the reserved bits in the BU. > > RR+DH seems to incur close to the same processing overhead as RR+CGA > while not providing much more security that just RR. MiTM is still possible. > Perhaps there is a subtle difference (I don't know for sure) that such a DH > MiTM requires seeing packets in both directions (i.e. that unicast routing > is somewhat symmetric between the CN and HA) whereas a RR MiTM does not require > this. I would say RR+DH is a better BU Authorization mechanism over RR, but not as good as RR+CGA. So it is still an option over RR and an MN should be able to select this mechanism. > Infrastructure-based mechanisms might make sense in some cases. > I have doubts whether a PKI would ever carry accurate information about > what Home Addresses a given certificate has authority to create binding for. > So personally I think that a PKI can be used in addition to whatever BU > authorization mechanism there is (e.g. RR) to be able to provide corse > level distinction between "known friends" and "others". If a MN's home address ever changes, then it gets a new certificate. Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a few domains (eg a corporate network). And this should be the most preferred BU Authorization mechanism whereever it is available. > I don't personally understand AAA-based authorization of binding updates would > entail and whether it would fit into the architecture of AAA that the AAAwg > is assuming to comment on that. Trust me. It will work. We will soon see AAA-based BU authorization mechanisms. (again wherever possible, this should be more preferred than RR, RR+DH, RR+CGA mechanism). > But up-leveling - the property that "the low-order 64 bits of the address > is allocated according to EUI-64" is currently encoded in the IPv6 address - > it is a property of the address. > The fact that "the low-order 64 bits is a of a public key" > is also a property of the address, thus it would make sense to encode this > in the address as well. > The fact that a MN or CN uses AAA (or some other infrastructure) for > pair-wise authentication and authorization is not a property of an IPv6 > address. Basically the above reinforces, what I had thought. The "1 bit method" is very specific to RR+CGA mechanism. It does not help in any way to select the other strong BU Authorization methods. I want to emphasize one point again. CGA is good for IPv6 and ND. I am not against it. And the "1 bit mechanism" is good for distinguishing a CGA address from another address. But that does not make it the best mechanism to select from a bunch of BU Authorization mechanisms. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:00:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22584 for ; Fri, 8 Feb 2002 15:00:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04385; Fri, 8 Feb 2002 13:00:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08658; Fri, 8 Feb 2002 11:59:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JibBJ016025 for ; Fri, 8 Feb 2002 11:44:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Jib5b016022 for mobile-ip-dist; Fri, 8 Feb 2002 11:44:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JiCBJ015896 for ; Fri, 8 Feb 2002 11:44:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21755 for ; Fri, 8 Feb 2002 11:00:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03940 for ; Fri, 8 Feb 2002 12:00:26 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20257; Fri, 8 Feb 2002 11:00:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18J0PK28214; Fri, 8 Feb 2002 11:00:25 -0800 X-mProtect:  Fri, 8 Feb 2002 11:00:25 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMz35yj; Fri, 08 Feb 2002 11:00:22 PST Message-ID: <3C642047.F6818F8@iprg.nokia.com> Date: Fri, 08 Feb 2002 11:00:23 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com, basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <3C6412FC.EB7AEDD2@iprg.nokia.com> <016801c1b0d0$4cd506c0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > > Here is a simple proposal to allow selection of alternative BU authorization > > schemes. Perhaps you folks have already thought about it.. In any case, I would > > appreciate your feedback. > > Thanks for your proposal! We should probably include it in a > new version of the writeup. Read on for the analysis... > > > The objective is to securely indicate to the CN the MN's intention to > > use a "better BU method". For this, why not include a signed hash covering a > > "selector" byte in the RR messages ? For instance, > > > > - the MN sends Nonce N1, and an 8-bit integer "selector" > > set to "better BU" mechanism in 1b. > > > > - the MN sends Nonce N2, and a signed hash of N1, N2, the > > "selector" field and the MN's Public Key in 1a. > > > > -the CN would verify the hash before accepting the method > > outlined in the "selector" field for BU authorization. > > > > The selector field can take different values including RR only, RR+DH, > > RR+CGA etc. > > This appears to have the following problem: an attacker, if he > is capable of defeating RR, must therefore be on the HA - CN > path. The attacker sends a spoofed 1a/1b with selector set where exactly is your attacker? if he is on the HA - CN path he cant see 1b. and the selector goes in 1b. 1b also contains a nonce, which the attacker cannot guess. 1b is MN (CoA) ------------ CN unless the attacker is on the CN's link. I thought that was something we are not trying to solve. Vijay > to "RR". CN believes this, and noone ever needed to break > public key hashes, as it would have been necessary in the case > of a bit in the address indicating that CGA should be used. > > Naturally, the attacker would still have to be on the HA - CN > path, with all of its implications. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:00:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22597 for ; Fri, 8 Feb 2002 15:00:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04370; Fri, 8 Feb 2002 13:00:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08689; Fri, 8 Feb 2002 11:59:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18Jk4BJ016206 for ; Fri, 8 Feb 2002 11:46:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Jk459016205 for mobile-ip-dist; Fri, 8 Feb 2002 11:46:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JjTBJ016173 for ; Fri, 8 Feb 2002 11:45:30 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14444 for ; Fri, 8 Feb 2002 11:02:57 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06585 for ; Fri, 8 Feb 2002 11:02:56 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20476; Fri, 8 Feb 2002 11:02:56 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18J2tk31698; Fri, 8 Feb 2002 11:02:55 -0800 X-mProtect:  Fri, 8 Feb 2002 11:02:55 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd12SDsX; Fri, 08 Feb 2002 11:02:40 PST Message-ID: <3C6420BF.471B0E9B@iprg.nokia.com> Date: Fri, 08 Feb 2002 11:02:23 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <3C6412FC.EB7AEDD2@iprg.nokia.com> <016801c1b0d0$4cd506c0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Jari Arkko wrote: > > Here is a simple proposal to allow selection of alternative BU authorization > > schemes. Perhaps you folks have already thought about it.. In any case, I would > > appreciate your feedback. > > Thanks for your proposal! We should probably include it in a > new version of the writeup. Read on for the analysis... > > > The objective is to securely indicate to the CN the MN's intention to > > use a "better BU method". For this, why not include a signed hash covering a > > "selector" byte in the RR messages ? For instance, > > > > - the MN sends Nonce N1, and an 8-bit integer "selector" > > set to "better BU" mechanism in 1b. > > > > - the MN sends Nonce N2, and a signed hash of N1, N2, the > > "selector" field and the MN's Public Key in 1a. > > > > -the CN would verify the hash before accepting the method > > outlined in the "selector" field for BU authorization. > > > > The selector field can take different values including RR only, RR+DH, > > RR+CGA etc. > > This appears to have the following problem: an attacker, if he > is capable of defeating RR, must therefore be on the HA - CN > path. The attacker sends a spoofed 1a/1b with selector set > to "RR". CN believes this, and noone ever needed to break > public key hashes, as it would have been necessary in the case > of a bit in the address indicating that CGA should be used. > I didn't quite follow you here.. If the attacker changed the selector to "RR" while the MN used RR+X, the hash would not match, right ? Why would the CN believe only the selector (set to RR) ? -Rajeev > > Naturally, the attacker would still have to be on the HA - CN > path, with all of its implications. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:01:15 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22629 for ; Fri, 8 Feb 2002 15:01:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26490; Fri, 8 Feb 2002 12:00:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08664; Fri, 8 Feb 2002 11:59:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JhvBJ015894 for ; Fri, 8 Feb 2002 11:43:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Jhvo9015893 for mobile-ip-dist; Fri, 8 Feb 2002 11:43:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JhJBJ015883 for ; Fri, 8 Feb 2002 11:43:20 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18750 for ; Fri, 8 Feb 2002 11:07:09 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08410 for ; Fri, 8 Feb 2002 11:07:07 -0800 (PST) Received: from jariws1 ([62.248.145.160]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020208190705.JRNJ24910.fep01-app.kolumbus.fi@jariws1>; Fri, 8 Feb 2002 21:07:05 +0200 Message-ID: <019601c1b0d3$d5521940$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Vijay Devarapalli" Cc: "Rajeev Koodli" , , References: <3C6412FC.EB7AEDD2@iprg.nokia.com> <016801c1b0d0$4cd506c0$8a1b6e0a@arenanet.fi> <3C642047.F6818F8@iprg.nokia.com> Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Fri, 8 Feb 2002 21:07:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > where exactly is your attacker? if he is on the HA - CN path > he cant see 1b. and the selector goes in 1b. 1b also contains > a nonce, which the attacker cannot guess. > > 1b is MN (CoA) ------------ CN > > unless the attacker is on the CN's link. I thought that was > something we are not trying to solve. Ah yes, but the attacker does not have to wait for the MN to actually send anything. He can just go ahead and claim CoA is on the HA - CN path, and just create the necessary signaling without ever involving the MN at all. It doesn't even have to be an MN... Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:01:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22641 for ; Fri, 8 Feb 2002 15:01:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26499; Fri, 8 Feb 2002 12:00:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08637; Fri, 8 Feb 2002 11:59:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18Jh7BJ015881 for ; Fri, 8 Feb 2002 11:43:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Jh7CM015880 for mobile-ip-dist; Fri, 8 Feb 2002 11:43:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18Jf0BJ015858 for ; Fri, 8 Feb 2002 11:41:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21545 for ; Thu, 7 Feb 2002 16:29:32 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26588 for ; Thu, 7 Feb 2002 16:29:32 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA03054; Thu, 7 Feb 2002 16:29:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g180TVJ01726; Thu, 7 Feb 2002 16:29:31 -0800 X-mProtect:  Thu, 7 Feb 2002 16:29:31 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdz8FeDB; Thu, 07 Feb 2002 16:29:29 PST Message-ID: <3C631BEA.227F75B6@iprg.nokia.com> Date: Thu, 07 Feb 2002 16:29:30 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Jari Arkko , basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:05:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22928 for ; Fri, 8 Feb 2002 15:05:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29612; Fri, 8 Feb 2002 13:05:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12441; Fri, 8 Feb 2002 12:05:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JTvWn014541 for ; Fri, 8 Feb 2002 12:03:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18INFUL008303 for mobile-ip-dist; Fri, 8 Feb 2002 10:23:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18IE5BJ008202 for ; Fri, 8 Feb 2002 10:17:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22414 for ; Fri, 8 Feb 2002 10:03:59 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08667 for ; Fri, 8 Feb 2002 10:03:52 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA16281; Fri, 8 Feb 2002 10:03:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18I3g927638; Fri, 8 Feb 2002 10:03:42 -0800 X-mProtect:  Fri, 8 Feb 2002 10:03:42 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNnW4Nw; Fri, 08 Feb 2002 10:03:40 PST Message-ID: <3C6412FC.EB7AEDD2@iprg.nokia.com> Date: Fri, 08 Feb 2002 10:03:40 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: vijayd@iprg.nokia.com, Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik and Jari, Erik Nordmark wrote: > > Example: attacker on the path between the CN and the HA. > Attacker can pretend to be the MN since it is on-path. Using the above > mechanism it can get the CN to accept RR-protected BUs even though the MN > actually only wants to allow CGA-protected BUs. > > This is different than the bit being securely retrieved from the secure > DNS before the communication started (and if you don't have DNSSEC you > really don't care if you're communicating with the real peer or not :-) > and the CN refusing RR-protected BUs if the bit is set. > > Here is a simple proposal to allow selection of alternative BU authorization schemes. Perhaps you folks have already thought about it.. In any case, I would appreciate your feedback. The objective is to securely indicate to the CN the MN's intention to use a "better BU method". For this, why not include a signed hash covering a "selector" byte in the RR messages ? For instance, - the MN sends Nonce N1, and an 8-bit integer "selector" set to "better BU" mechanism in 1b. - the MN sends Nonce N2, and a signed hash of N1, N2, the "selector" field and the MN's Public Key in 1a. -the CN would verify the hash before accepting the method outlined in the "selector" field for BU authorization. The selector field can take different values including RR only, RR+DH, RR+CGA etc. Regards, -Rajeev > Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:21:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23523 for ; Fri, 8 Feb 2002 15:21:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11404; Fri, 8 Feb 2002 13:21:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19367; Fri, 8 Feb 2002 12:20:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KEuQt020922 for ; Fri, 8 Feb 2002 12:18:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18Jv30F018995 for mobile-ip-dist; Fri, 8 Feb 2002 11:57:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JjTNB016173 for ; Fri, 8 Feb 2002 11:56:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12019; Fri, 8 Feb 2002 09:39:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15265; Fri, 8 Feb 2002 10:39:13 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA14225; Fri, 8 Feb 2002 09:39:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18HdCY26966; Fri, 8 Feb 2002 09:39:12 -0800 X-mProtect:  Fri, 8 Feb 2002 09:39:12 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKe87PO; Fri, 08 Feb 2002 09:39:09 PST Message-ID: <3C640CE2.271B5264@iprg.nokia.com> Date: Fri, 08 Feb 2002 09:37:38 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, You wrote: > > The care-of address is the routing destination. The home address > > is the endpoint identifier -- i.e., the socket destination. They > > are used differently. The care-of address should be be made > > invisible to the application. The home address should not be > > made visible to the routing infrastructure, very broadly > > speaking. > > I agree that the home address shouldn't be visible to the routing > infrastructure. > But below you talk about the home address being > "interior address in a list of routers" which seems to conflict > with your statement above. There isn't any conflict. In any source route, the nodes which are "farther down" in the list, are "intentionally" made to be "not visible" until it gets to be their turn. But, you are correct that my statement could be misinterpreted. What I should have said is that the "home address should not be made visible to the routing infrastructure _prematurely_" -- i.e., not until it can be conveniently and/or correctly used as a next hop. > > Yes, the routing header does do that. In fact, you > > "could" make the care-of address as the final segment, and > > have a new option that says "use this as your destination > > home address", as has been pointed out elsewhere. Then > > I think you have to offer a solution about what happens when > > that home address was an interior address in a list of routers > > used for some purpose requiring a routing header. Does the > > node formulating the routing header have to condition its > > construction based on knowledge about the care-of address > > of the mobile node? This is the additional complication > > that will certainly become necessary if you mandate more > > restrictive behavior now. Or else in the future we will more > > likely "un-mandate" it. Oh, well! > > We are going around in circles both in the discussion and in your > arguments. > I've asked you many times on the list why you seen the need to > combine explicit routing (using source routing) and mobility > the way you describe. > Your respons has always been something like > its obvious that things should work as RH since this is routing > and using that as the motivation for it needing to work as RH. I _wanted_ my response to be understood as saying that we CAN model it using RH, and if we don't model it as RH, we'll have to eventually say how to put source route segments before and after the newly created thing, and that the new thing will be a lot harder because we didn't model it using RH in the first place. That's a lot different than your characterization. > In order to talk more intelligently about this it seems like we need > to understand: > 1. Mobile routers/networks and how route optimization should work with such > 2. Explicit routing using source routing - will applications do this? > 3. How #1 and #2 should interact > > To me saying whether destination options, routing headers, or Deering/Zill > tunneling fit better in this completely undefined space seems > to be rather unproductive speculation. Here, I basically agree with you. We can't boil the ocean now. I would suggest that we proceed as follows: - Leave RH for now - Replace it if need be in the future. > > Then I would suggest that since RH manifestly "works", and since > > we can not be sure that firewall vendors will be "nice" for any > > alternative proposal especially when that alternative has to be > > extended for the mobile router on my belt that communicates with > > my PDA and laptop and earrings -- that we should go with what > > works. And, after all, this is FAR more validation and analysis > > than seems to go into other Proposed Standards! > > RH works. > Tunneling works. > The fact that HAO works for the source HoA means that we know exactly how to > make a destination HoA work as a destination option as well. Yes, except insofar as one wishes the new thing to work with routing headers. > The point is that the attribute "works" doesn't seem to help > tell them apart. > "Number of lines of code changes in an implementation" can be used to > tell them apart, and that is definitely one factor for the WG to consider > together with other factors. How about "works now" vs. "works eventually"? > > > We seem to agree that the HoA in a HAO sent *from* a MN serves to > > > identify the MN. > > > > Right, as long as we mean "endpoint identification". > > Hmm - but from above it seems like you have a different definition of > this term than I have. I seriously doubt that! We've both been around that mulberry bush more than once, I'd say. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 15:21:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23541 for ; Fri, 8 Feb 2002 15:21:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02673; Fri, 8 Feb 2002 12:21:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19520; Fri, 8 Feb 2002 12:21:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KEuQv020922 for ; Fri, 8 Feb 2002 12:18:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18JpDqf017627 for mobile-ip-dist; Fri, 8 Feb 2002 11:51:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18JjTGR016173 for ; Fri, 8 Feb 2002 11:50:10 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23572 for ; Fri, 8 Feb 2002 10:06:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08581 for ; Fri, 8 Feb 2002 10:06:42 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA16272 for ; Fri, 8 Feb 2002 10:03:33 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18I3Xo27354 for ; Fri, 8 Feb 2002 10:03:33 -0800 X-mProtect:  Fri, 8 Feb 2002 10:03:33 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhimDtf; Fri, 08 Feb 2002 10:03:31 PST Message-ID: <3C6412F3.283B00EB@iprg.nokia.com> Date: Fri, 08 Feb 2002 10:03:31 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [Fwd: Re: [mobile-ip] BU Authorization method: design team recommendation] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [repost] for some reason, this mail did not make it to the list. Erik has already responded to this mail. Vijay -------- Original Message -------- Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Thu, 07 Feb 2002 16:29:30 -0800 From: Vijay Devarapalli To: Erik Nordmark CC: Jari Arkko ,basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com References: Hi Erik, Jari, Erik Nordmark wrote: > > 3. Assume, I have more than 2 mechanisms for BU authorization > > (RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here? > > For this, (IMO) the obvious thing would be a set of bits > > in the Binding Update. You dont have to specify this now. We > > can do this later using the reserved bits in the BU. > > RR+DH seems to incur close to the same processing overhead as RR+CGA > while not providing much more security that just RR. MiTM is still possible. > Perhaps there is a subtle difference (I don't know for sure) that such a DH > MiTM requires seeing packets in both directions (i.e. that unicast routing > is somewhat symmetric between the CN and HA) whereas a RR MiTM does not require > this. I would say RR+DH is a better BU Authorization mechanism over RR, but not as good as RR+CGA. So it is still an option over RR and an MN should be able to select this mechanism. > Infrastructure-based mechanisms might make sense in some cases. > I have doubts whether a PKI would ever carry accurate information about > what Home Addresses a given certificate has authority to create binding for. > So personally I think that a PKI can be used in addition to whatever BU > authorization mechanism there is (e.g. RR) to be able to provide corse > level distinction between "known friends" and "others". If a MN's home address ever changes, then it gets a new certificate. Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a few domains (eg a corporate network). And this should be the most preferred BU Authorization mechanism whereever it is available. > I don't personally understand AAA-based authorization of binding updates would > entail and whether it would fit into the architecture of AAA that the AAAwg > is assuming to comment on that. Trust me. It will work. We will soon see AAA-based BU authorization mechanisms. (again wherever possible, this should be more preferred than RR, RR+DH, RR+CGA mechanism). > But up-leveling - the property that "the low-order 64 bits of the address > is allocated according to EUI-64" is currently encoded in the IPv6 address - > it is a property of the address. > The fact that "the low-order 64 bits is a of a public key" > is also a property of the address, thus it would make sense to encode this > in the address as well. > The fact that a MN or CN uses AAA (or some other infrastructure) for > pair-wise authentication and authorization is not a property of an IPv6 > address. Basically the above reinforces, what I had thought. The "1 bit method" is very specific to RR+CGA mechanism. It does not help in any way to select the other strong BU Authorization methods. I want to emphasize one point again. CGA is good for IPv6 and ND. I am not against it. And the "1 bit mechanism" is good for distinguishing a CGA address from another address. But that does not make it the best mechanism to select from a bunch of BU Authorization mechanisms. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 16:04:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24808 for ; Fri, 8 Feb 2002 16:04:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03337; Fri, 8 Feb 2002 14:04:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04076; Fri, 8 Feb 2002 13:04:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KxuKZ025424 for ; Fri, 8 Feb 2002 13:01:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18KkEb2023314 for mobile-ip-dist; Fri, 8 Feb 2002 12:46:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18KiEE7022494 for ; Fri, 8 Feb 2002 12:45:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26268; Fri, 8 Feb 2002 11:25:56 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22472; Fri, 8 Feb 2002 12:25:54 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22415; Fri, 8 Feb 2002 11:25:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18JPpa27452; Fri, 8 Feb 2002 11:25:51 -0800 X-mProtect:  Fri, 8 Feb 2002 11:25:51 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3TRsF9; Fri, 08 Feb 2002 11:25:49 PST Message-ID: <3C64263E.3CAD8640@iprg.nokia.com> Date: Fri, 08 Feb 2002 11:25:50 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Rajeev Koodli , mobile-ip@sunroof.eng.sun.com, basavaraj.patil@nokia.com, Erik.Nordmark@eng.sun.com, phil.roberts@megisto.com, jmalinen@iprg.nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <3C6412FC.EB7AEDD2@iprg.nokia.com> <016801c1b0d0$4cd506c0$8a1b6e0a@arenanet.fi> <3C642047.F6818F8@iprg.nokia.com> <019601c1b0d3$d5521940$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, Let me reason things a bit. When the MN is active and has a active binding at the CN created through RR+CGA, an attacker cannot bid down. For details, see Jari Malinen's mail that was sent out yesterday. When the MN is active and is initiating RR+CGA as described in Rajeev's mail, an attacker cannot bid down because he cant see 1b. You are saying that the attacker could create a binding at the CN when the MN is not active, right? But I am saying that when the MN comes back alive, it is going to initiate RR+CGA binding at the CN (it WILL because it does not have a corresponding Binding Update List entry for the CN). The binding created by the attacker is invalidated. So the "1 bit method" just prevents the following. It prevents the attacker from creating a binding at the CN when the MN is inactive. Also for this to work the CN has to have obtained the MN's address through DNSSEC. Whats the big deal in this? Not worth modifying two RFCs for this extra protection. Anything wrong in the above reasoning? regards Vijay PS: for some reason, all the mails I have sent since yesterday are not making it to the mailing list. dont know why. could somebody please forward them to the mailing list? Jari Arkko wrote: > > > where exactly is your attacker? if he is on the HA - CN path > > he cant see 1b. and the selector goes in 1b. 1b also contains > > a nonce, which the attacker cannot guess. > > > > 1b is MN (CoA) ------------ CN > > > > unless the attacker is on the CN's link. I thought that was > > something we are not trying to solve. > > Ah yes, but the attacker does not have to wait for the MN to > actually send anything. He can just go ahead and claim CoA > is on the HA - CN path, and just create the necessary signaling > without ever involving the MN at all. It doesn't even have to be > an MN... > > Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 17:11:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26323 for ; Fri, 8 Feb 2002 17:11:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02306; Fri, 8 Feb 2002 15:10:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26125; Fri, 8 Feb 2002 14:10:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18M9UBJ027638 for ; Fri, 8 Feb 2002 14:09:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18M9UF5027637 for mobile-ip-dist; Fri, 8 Feb 2002 14:09:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18M9RBJ027630 for ; Fri, 8 Feb 2002 14:09:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29135 for ; Fri, 8 Feb 2002 14:09:43 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26379 for ; Fri, 8 Feb 2002 15:09:43 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA03010 for ; Fri, 8 Feb 2002 14:09:42 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g18M9fR26741 for ; Fri, 8 Feb 2002 14:09:41 -0800 X-mProtect:  Fri, 8 Feb 2002 14:09:41 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0nfCu8; Fri, 08 Feb 2002 14:09:39 PST Message-ID: <3C644C43.40F51241@iprg.nokia.com> Date: Fri, 08 Feb 2002 14:08:03 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question References: <8C92E23A3E87FB479988285F9E22BE465ABAC3@ftmail> <3C62AD7E.4000406@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, As best I can remember, the 'R' bit was never intended to restrict against operation with a co-located care-of address. > My private feeling is that there are no advantage for the MN to run > co-located over registered with FA. And there is no way for a FA to tell > that he proposes co-located mode. So, in my mind it's already set, adn > instead the spec could be clarified to disallow registering with > co-located address to FA. This would be a change to the specification, and I don't think it would be warranted unless someone can show a problem with it. Also, I do not personally subscribe to the theory that all permissible behaviors have to be explicitly listed in the specification. That would be hard, because then one would get into immeasurable amounts of work, viz: - the mobile node can transmit ICMP - the mobile node can receive ICMP - the mobile node can use UDP port 80 - the mobile node can use SMTP - the mobile node can use ... but none of these are _explicitly_ allowed as a result of any specific enablement (i.e., "MAY") in RFC2002bis. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 17:41:43 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26900 for ; Fri, 8 Feb 2002 17:41:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14401; Fri, 8 Feb 2002 15:40:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05989; Fri, 8 Feb 2002 14:40:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HTrEv004646 for ; Fri, 8 Feb 2002 09:31:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18G3iEE000517 for mobile-ip-dist; Fri, 8 Feb 2002 08:03:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18G3aBN000494 for ; Fri, 8 Feb 2002 08:03:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21450 for ; Fri, 8 Feb 2002 01:20:07 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA25102 for ; Fri, 8 Feb 2002 02:20:06 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4WXM5K>; Fri, 8 Feb 2002 10:20:03 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCF06@lat3721.rd.francetelecom.fr> From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: results and proposal was: RE: [mobile-ip] RFC2002bis interpre tati on question Date: Fri, 8 Feb 2002 10:20:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-961dcf3d-1c69-11d6-ac1f-00508b692753" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-961dcf3d-1c69-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B081.C9AECB30" ------_=_NextPart_001_01C1B081.C9AECB30 Content-Type: text/plain The simplest way is to leave the MN to choose between CoA and Co-CoA, but we may add that the FA can refuse if the MN chooses the Co-CoA. In that case the FA rejects the registration and the MN may reregister with the FA CoA. I think that all of these are implementation issues. Kassi -----Message d'origine----- De : kleung [mailto:kleung@cisco.com] Envoye : jeudi 7 fevrier 2002 19:09 A : mobile-ip@sunroof.eng.sun.com Objet : Re: results and proposal was: RE: [mobile-ip] RFC2002bis interpretati on question George Tsirtsis wrote: > How does a FA indicate that it doesn't > support "encaps/decaps services based on CoA"? > > GT> This is easy. One way would be to allow an FA advert to have Rbit set > but does not include a CoA. The Mobile Node would then see that there is no > CoA so it needs to get a collocated address and since the Rbit is set the > node will have to register it through the FA. > Since FA supports tunneling, why shouldn't FA advert its CoA? Then it's up to MNs to decide to use CCoA or FA CoA. The R bit is for FA access (or MIP service authorization) control. The CoA is not meant for tunneling control, but merely advertised service. But the above scheme use CoA as tunneling control. As said, MNs will likely use the FA CoA when advert received. Though I think the generic properties of existing spec allows flexibility for MN to choose where it wants tunnel termination. The access authentication/authorization scheme may factor in MN's decision since it may go through 2 levels (802.1x and MIP) when CCOA is used. Of course, FA may decide to bypass MIP authentication when it sees RRQ with D bit set and external CoA if it is aware that 802.1x already occurred. Flexibility comes complexity. :) But forcing MNs to use FA COA with R bit advertised is rigid, though simpler for the common scenario. So if we leave spec as is, then MNs choose either CCoA or FA CoA when it sends RRQ to FA, which advert the R bit. Is this ambiguous? Seems like the new proposal is to enforce CCOA tunneling by removing COA in advert. And on the other end, proposal to mandate that MN must use FA COA. Both cases when R bit set in advert. Both takes the right to choose from MN. This is what we want, right? Kent > > We have never run into the problem because our MN always switch to FA > registered if a adverticements comes out, regardless of R-bit. So, an > interop with us would be pointless. > > If someone perceives to run co-located despite our agents > adverticements, they will be sean as using our simple IP service and not > mobile IP. The packets will be treated according to the policy > configured in the FA (not really a FA in that case, more of a ACD > (Access Control Device)) and if he is authenticated by some other means > (like web-login or 802.1x). > > My private feeling is that there are no advantage for the MN to run > co-located over registered with FA. And there is no way for a FA to tell > that he proposes co-located mode. So, in my mind it's already set, adn > instead the spec could be clarified to disallow registering with > co-located address to FA. > > GT> No, no, now you are totally missing the point of the Rbit. Just because > some implementers chose to prefer CoAs if they can get them it does not mean > that CCoAs are not needed and it does not mean that the FA should not be > able to request registration. The Rbit is useful but it is weakly specified > which unfortunately allows you to think that is not needed. > > George ------_=_NextPart_001_01C1B081.C9AECB30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: results and proposal was: RE: [mobile-ip] RFC2002bis = interpretati on question

The simplest way is to leave the MN to choose between = CoA and Co-CoA, but we may add that the FA can refuse if the MN chooses = the Co-CoA. In that case the FA rejects the registration and the MN may = reregister with the FA CoA. I think that all of these are = implementation issues.

Kassi

-----Message d'origine-----
De : kleung [mailto:kleung@cisco.com]
Envoye : jeudi 7 fevrier 2002 19:09
A : mobile-ip@sunroof.eng.sun.com
Objet : Re: results and proposal was: RE: = [mobile-ip] RFC2002bis
interpretati on question



George Tsirtsis wrote:

> How does a FA indicate that it doesn't
> support "encaps/decaps services based on = CoA"?
>
> GT> This is easy. One way would be to allow = an FA advert to have Rbit set
> but does not include a CoA. The Mobile Node = would then see that there is no
> CoA so it needs to get a collocated address and = since the Rbit is set the
> node will have to register it through the = FA.
>

Since FA supports tunneling, why shouldn't FA advert = its CoA?  Then
it's up to MNs to decide to use CCoA or FA = CoA.

The R bit is for FA access (or MIP service = authorization) control.   The
CoA is not meant for tunneling control, but merely = advertised service.
But the above scheme use CoA as tunneling = control.

As said, MNs will likely use the FA CoA when advert = received.  Though
I think the generic properties of existing spec = allows flexibility for MN to
choose where it wants tunnel termination.

The access authentication/authorization scheme may = factor in MN's
decision since it may go through 2 levels (802.1x = and MIP) when
CCOA is used.  Of course, FA may decide to = bypass MIP authentication
when it sees RRQ with D bit set and external CoA if = it is aware that
802.1x already occurred.

Flexibility comes complexity.  :)  But = forcing MNs to use FA COA
with R bit advertised is rigid, though simpler for = the common scenario.

So if we leave spec as is, then MNs choose either = CCoA or FA CoA
when it sends RRQ to FA, which advert the R = bit.  Is this ambiguous?

Seems like the new proposal is to enforce CCOA = tunneling by removing
COA in advert.  And on the other end, proposal = to mandate that MN
must use FA COA.  Both cases when R bit set in = advert.  Both takes
the right to choose from MN.  This is what we = want, right?

Kent




>
> We have never run into the problem because our = MN always switch to FA
> registered if a adverticements comes out, = regardless of R-bit. So, an
> interop with us would be pointless.
>
> If someone perceives to run co-located despite = our agents
> adverticements, they will be sean as using our = simple IP service and not
> mobile IP. The packets will be treated = according to the policy
> configured in the FA (not really a FA in that = case, more of a ACD
> (Access Control Device)) and if he is = authenticated by some other means
> (like web-login or 802.1x).
>
> My private feeling is that there are no = advantage for the MN to run
> co-located over registered with FA. And there = is no way for a FA to tell
> that he proposes co-located mode. So, in my = mind it's already set, adn
> instead the spec could be clarified to disallow = registering with
> co-located address to FA.
>
> GT> No, no, now you are totally missing the = point of the Rbit. Just because
> some implementers chose to prefer CoAs if they = can get them it does not mean
> that CCoAs are not needed and it does not mean = that the FA should not be
> able to request registration. The Rbit is = useful but it is weakly specified
> which unfortunately allows you to think that is = not needed.
>
> George

------_=_NextPart_001_01C1B081.C9AECB30-- ------=_NextPartTM-000-961dcf3d-1c69-11d6-ac1f-00508b692753-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 18:07:34 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27167 for ; Fri, 8 Feb 2002 18:07:34 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06328; Fri, 8 Feb 2002 15:07:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11640; Fri, 8 Feb 2002 15:07:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18N5nFh027935 for ; Fri, 8 Feb 2002 15:05:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g18N5nBi027934 for mobile-ip-dist; Fri, 8 Feb 2002 15:05:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18N5jFh027927 for ; Fri, 8 Feb 2002 15:05:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21303 for ; Fri, 8 Feb 2002 15:06:00 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19227 for ; Fri, 8 Feb 2002 16:06:00 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0D02D2DE6 for ; Fri, 8 Feb 2002 18:06:00 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 699A31749 for ; Fri, 8 Feb 2002 17:05:59 -0600 (CST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g18N5lk12887; Fri, 8 Feb 2002 18:05:47 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA31108; Fri, 8 Feb 2002 18:05:42 -0500 Message-Id: <200202082305.AA31108@dogbert.zk3.dec.com> From: Brian.Haley@compaq.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Fri, 08 Feb 2002 18:05:31 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik Nordmark wrote: > > > Do people see strong arguments for/against handling the "source HoA" and > > > the destination "HoA" using the same mechanism? > > > > One shouldn't impose symmetry on the handling of addresses that > > are to be used for different purposes entirely. > > We seem to agree that the HoA in a HAO sent *from* a MN serves to > identify the MN. > The above statement of "different purpose" seem to say that the HoA in a packet > sent *to* a MN does not identify the MN? I'm confused - either the home > address identifies the MN or it does not - this can't depend on what type of > packet the HoA is contained in. Erik, Maybe I mis-understood your second sentence in this reply: "... the HoA in a packet sent *to* a MN does not identify the MN?" Surely the HoA identifies the sending MN, but it can't identify the receiving MN. There must be a way to specify the Home Source Address and Home Destination Address (aka RH right now) independently, since MN to MN traffic needs this to work (4 addresses in the packet). I think Charlie might have clarified this, but I've been having mail problems with this list recently and couldn't find the replies. -Brian From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 8 19:40:51 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28290 for ; Fri, 8 Feb 2002 19:40:51 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19900; Fri, 8 Feb 2002 16:40:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29607; Fri, 8 Feb 2002 16:40:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g190cuFh028324 for ; Fri, 8 Feb 2002 16:38:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g190ctSv028323 for mobile-ip-dist; Fri, 8 Feb 2002 16:38:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g190cqFh028316 for ; Fri, 8 Feb 2002 16:38:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02663 for ; Fri, 8 Feb 2002 16:39:08 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26739 for ; Fri, 8 Feb 2002 16:39:08 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA12637; Fri, 8 Feb 2002 16:39:07 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g190d3v31647; Fri, 8 Feb 2002 16:39:03 -0800 X-mProtect:  Fri, 8 Feb 2002 16:39:03 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdizPtvw; Fri, 08 Feb 2002 16:39:01 PST Message-ID: <3C646FA5.6E6F28A3@iprg.nokia.com> Date: Fri, 08 Feb 2002 16:39:01 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Jari Arkko , basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Erik, I am not sure if you have taken a look at the following draft. http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt It uses RR+DH to create MN-CN security association. This draft also gives an example where DH method can take advantage of AAA (wherever available) to eliminate MiTM attacks that DH is prone to. Anyway, I dont want to get into a detailed discussion on how PKI, DH or AAA can be used (maybe we can do it offline). But, I believe that there could be more than 2 strong BU Authorization methods. I guess this where we disagree. You are not recognising anything other than RR and RR+CGA for the moment. regards Vijay PS: I agree with you that there is currently no concrete proposal for the "other" BU Authorization mechanisms that I am talking about. But by adopting this "1 bit method" (or 2 bits as described in your mail), I fear there might be no room for selecting these mechanisms later on. Erik Nordmark wrote: > > Vijay, > > > I would say RR+DH is a better BU Authorization mechanism over RR, > > but not as good as RR+CGA. So it is still an option over RR and > > an MN should be able to select this mechanism. > > The design team didn't find significant differences but perhaps we didn't > look carefully enough. > Do you have threats that RR+DH can handle that RR can not handle? > > > If a MN's home address ever changes, then it gets a new certificate. > > Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a > > few domains (eg a corporate network). And this should be the most > > preferred BU Authorization mechanism whereever it is available. > > The details of why I think is unworkable in practise is a bit different > depending on the nature of the CA. > If you look at the case of a large commercial CA, how could they possibly > verify that a Home Address is assigned to box "owned" by Erik.Nordmark@sun.com > (where that string is the name in the certificate)? > Doing this in order to initially list the Home Address in the cert doesn't > seem tractable. Doing it every day when I decide to get an new RFC 3041 > address seems even less likely to work. > What about the case when my ISP or company renumbers the prefix on my link - > how does the CA ever find out so that they can revoke that certificate which > now has a stale Home Address? > > If the case is that there is a more local CA (e.g. a company or an ISP > running their own CA) I think there are also hard problems in creating > the initial association between the certificate name and the Home Address > placed in the certificate. But it might be possible to throw people at the > problem (i.e. I would get a phone call asking for verification or > somebody would visit me in person). > But with a more local CA the question is how the trust is > established between a CN using one CA and a MN using another CA. > > So I think this is a serious case matching the quote > In theory there is no difference between theory and practise. > In practise there is. > > > > I don't personally understand AAA-based authorization of binding updates would > > > entail and whether it would fit into the architecture of AAA that the AAAwg > > > is assuming to comment on that. > > > > Trust me. It will work. We will soon see AAA-based BU authorization > > mechanisms. (again wherever possible, this should be more preferred > > than RR, RR+DH, RR+CGA mechanism). > > I didn't say it could not be built. I'm questioning whether it fits into > the architecture of AAA (that architecture is that clients authenticate > to the infrastructure - and not that the infrastructure helps clients > authenticate eachother. The latter sounds a lot more like a PKI. While it's > possible to make the AAA become a PKI as well it might not be the optimal > solution). > > I also have concerns about what it would mean > for RFC 3041 temporary style addresses (when a user wants to minimize > the relationship between the IP address used at the moment and > any longer term name associated with the user). I all fairness, > I think all infrastructure-based solutions (e.g. PKI and AAA) > raise concerns in this area of enabling anonymity. > > > Basically the above reinforces, what I had thought. The "1 bit method" > > is very specific to RR+CGA mechanism. It does not help in any way > > to select the other strong BU Authorization methods. > > > > I want to emphasize one point again. CGA is good for IPv6 and ND. I am > > not against it. And the "1 bit mechanism" is good for distinguishing a > > CGA address from another address. But that does not make it the best > > mechanism to select from a bunch of BU Authorization mechanisms. > > I think you are correct on both of those points. > > Question is whether that is a good thing or a bad thing. > > If there was e.g. a baked spec on how AAA based authorization would work > at an abstract level (no need for packet formats) and with what assumptions > it might be possible to see what type of mechanisms would make > sense for policy control in that space and how it would interact with > the MIP nodes (MNs and CNs) that are not part of that AAA infrastructure. > But until then at least me personally feel like I'm stumbling in the dark > when it comes to AAA-based authorization of BUs. > > Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 9 12:06:54 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17351 for ; Sat, 9 Feb 2002 12:06:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15939; Sat, 9 Feb 2002 09:06:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06081; Sat, 9 Feb 2002 09:06:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19H5aFh029290 for ; Sat, 9 Feb 2002 09:05:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g19H5a1w029289 for mobile-ip-dist; Sat, 9 Feb 2002 09:05:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19H5XFh029282 for ; Sat, 9 Feb 2002 09:05:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23822 for ; Sat, 9 Feb 2002 09:05:35 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21612 for ; Sat, 9 Feb 2002 10:05:34 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g19H5Wa18156 for ; Sat, 9 Feb 2002 18:05:32 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA07903 for ; Sat, 9 Feb 2002 18:05:32 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g19H5Vg92176 for ; Sat, 9 Feb 2002 18:05:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202091705.g19H5Vg92176@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Mon, 04 Feb 2002 23:00:59 +0200. <3C5EF68B.4060606@piuha.net> Date: Sat, 09 Feb 2002 18:05:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => note there is a point where I DISAGREE with the CONCLUSION, i.e. I believe the design team has missed an important point. 1. INTRODUCTION =============== To date, various BU authorization methods have been proposed. Of the proposals that don't assume a separate infrastructure the properties they rely on are either RR and/or CGA properties. An analysis of the security properties of those general categories of CGA and RR can be found at: http://www.piuha.net/~jarkko/publications/mipv6/Residual_Threats.txt => I have three concerns in general: - the first one is purely philosophical and I wish to be wrong: we have not found the good balance between security and cost (in term of computing resources), I am afraid the market will find the proposals too weak (for RR) or too expensive (for CGAs, cf 2 2nd property). Of course the issue is hard because usually stronger security implied more computational resource consumption. But another detail can become very bad for the future of Routing Optimization (RO): the benefits are only for the MN but a significant part of the cost is for the CN. This is not economically viable in the general case (note that there is an interesting exception). - the second is about the procedure itself, there is a thread model and security requirement (TMRS) document: it is not used here! Both for gratitude for this work and for the clarity of the procedure as defined by the WG chairs, IMHO all details should reference the corresponding point in the TMRS and if something is not in the TMRS it should be added into the TMRS ASAP. [CLARIFICATION, CAN TOLERATE] - the last concern is about the possible use of "external" security, i.e. I can't find here a word about what one can do if one's already got for instance IPsec protection of all communications with proper (i.e. mobility aware) policies. In the same way, there is *nothing* about the MN-HA (aka Home Registration (HR)) security or Binding Acknowledgement (BA) security: something at least is missing in this introduction... [ISSUE, CAN TOLERATE] 2. ALTERNATIVES =============== The main alternatives for the actual address ownership authorization problem are: (a) Return Routability, RR (b) RR enhanced with Cryptographically Generated Addresses, CGA The security properties of these methods have been described in the URL referenced from section 1. In addition, there are a few additional properties we would like to bring to the attention: - CGA requires additional computational power. It is not clear though if this is big enough requirement to be an issue, particularly when very constrained nodes could refuse RO, and given that it has been demonstrated that protocols can be designed where MNs and CNs can offload their expensive computations to their HAs. => [CLARIFICATION, CAN TOLERATE] (in fact I disagree but only with the actual statement, not with the real idea). The last statement is wrong because CNs can't offload computations to HAs of MNs: CNs have no more reason to trust HAs than MNs, this argument applies to any HA-based scheme (cf. Jean-Michel Combes). So the property has no possible improvement for CNs in general. - Several IPR claims have been made regarding CGA. => [ISSUE, DISAGREE] I live in a country where software patents are explicitely excluded by the law but with some pros. and cons. pressures about them, so I can have a distorted view of the IPR problem... My concern is about free softwares: I really want to *never* see a BSD or Linux development stopped because a standard is subject to IPR. In fact the problem is there is no provision for free softwares in RFC 2026 10.3.2 (C) and we rely more and more on free/open source softwares. In addition to the basic mechanism there are a few additional issues that we need to decide: (i) Whether or not Binding Security Associations (BSAs) are used => [CLARIFICATION, CAN TOLERATE] This point should be clearer if BAs (and Binding Requests (BRs)) were taken into account too. Note that I-D 15 has some security requests for BAs, perhaps some of them for BAs of HRs. (ii) What addresses need RR tests (HoA, CoA, or both), and what is the correct time to perform the tests, always at the time the binding is requested? 3. RECOMMENDATIONS ================== 1. The design team recommends a mandatory RR mechanism for IPv6 nodes, but with limitations on how long bindings can stay alive before they need to be refreshed. => [CLARIFICATION, CAN TOLERATE] how long is not enough accurate, i.e. units can be in time or in bytes/packets (cf. RFC 2401 4.4.3). I recommend to use both and to expire on the first. In order to make this as clear as possible, here is the whole reference: > o Lifetime of this Security Association: a time interval after > which an SA must be replaced with a new SA (and new SPI) or > terminated, plus an indication of which of these actions > should occur. This may be expressed as a time or byte count, > or a simultaneous use of both, the first lifetime to expire > taking precedence. A compliant implementation MUST support > both types of lifetimes, and must support a simultaneous use > of both. If time is employed, and if IKE employs X.509 > certificates for SA establishment, the SA lifetime must be > constrained by the validity intervals of the certificates, > and the NextIssueDate of the CRLs used in the IKE exchange > for the SA. Both initiator and responder are responsible for > constraining SA lifetime in this fashion. > [REQUIRED for all implementations] > > NOTE: The details of how to handle the refreshing of keys > when SAs expire is a local matter. However, one reasonable > approach is: > (a) If byte count is used, then the implementation > SHOULD count the number of bytes to which the IPsec > algorithm is applied. For ESP, this is the encryption > algorithm (including Null encryption) and for AH, > this is the authentication algorithm. This includes > pad bytes, etc. Note that implementations SHOULD be > able to handle having the counters at the ends of an > SA get out of synch, e.g., because of packet loss or > because the implementations at each end of the SA > aren't doing things the same way. > (b) There SHOULD be two kinds of lifetime -- a soft > lifetime which warns the implementation to initiate > action such as setting up a replacement SA and a > hard lifetime when the current SA ends. > (c) If the entire packet does not get delivered during > the SAs lifetime, the packet SHOULD be discarded. This recommendation is based on the findings of the security analysis, which point to some deficiences in the RR method below the "do no harm" principle, to which the limitations provide a reasonable answer. The RR mechanism should be placed in the MIPv6 RFC. Given that RR may not be sufficient in all situations or may need to be replaced later with something else, we recommend that a secure mechanism for selecting different BU authorization methods, using the "bit method" described in the URL referenced from section 1, is included in this RFC as well. => [CLARIFICATION, AGREE] The bit method is fine for CGAs because as there is no implementation of the to come specs, the bit method can be implemented before full MIPv6 itself. => [CLARIFICATION, DISAGREE] But the bit method doesn't work for all other (perhaps unknown) mechanisms, so the argument developped in the last statement of (1.) is only valid for CGAs. This should be clearly explained in the MIPv6 RFC. 2. The design team additionally recommends an optional CGA mechanism to be standardized in a separate RFC in the MIPv6 WG, using the above "bit method". => see the previous comment. This recommendation is based on the findings of the security analysis, which point to lesser signaling requirements and improved security properties of CGA, as well as potential for solving additional, IPv6 problems. Due to IPR and CPU consumption concerns it seems problematic to make CGA a mandatory requirement, however. => AGREE 3. Regarding issue (i), the design team recommends that the RR method should not use a BSA since we already recommend both HoA and CoA RR tests to be performed every time a binding is refreshed or updated with RR. => AGREE (but don't forget BAs) For CGA, the design team recommends that a (simplified) BSA can be used to store the => can -> may? Diffie-Hellman value generated as a part of the initial binding, since with CGA, only the CoA test needs to be performed on every binding refresh. => [CLARIFICATION, DISAGREE] This statement makes some assumptions about the used scheme. CGAs provide a kind of authentication by signatures, this is very different from building a shared secret with Diffie-Hellman. The wording can, at least, be improved. 4. Regarding issue (ii), the design team recommends both CoA and HoA tests to be performed every time binding is refreshed or updated with RR. We also recommend additionally that these tests are made using separate requests in order to avoid reflection problems with the authorization protocol itself (a BU authorization request sent from the CoA should not be answered to the HoA). This essentially leads to a five message exchange that lasts 1.5 RTTs since because two pairs of the messages can occur in parallel: 1a. MN(HoA)--->HA--->CN 1b. MN(CoA)--------->CN 2a. CN-------->HA--->MN(HoA) 2b. CN-------------->MN(CoA) 3. MN(CoA)--------->CN => [CONCLUSION, DISAGREE] (this is about 4 and 5 but I put it here) An important case, both likely common in the future and with critical vulnerabilities, is *not* addressed: mobile to mobile. - first argument: there is no reason to have only fixed CNs and RO can be very interesting (i.e. give far better performance) when the CN itself is mobile, for instance in the same network. (this is the important exception of my philosophical/first concern, IMHO this case is worth our consideration). - second argument: the RR (in)security is based on the fact the attacker should be near the CN, ideally on the HA-CN and MN-CN paths. This assumption is reasonnable for fixed CNs (if the attacker is in the core we already are in trouble without MIPv6) but not always for mobile CNs. The situation is symmetrical, if the mobile to mobile case is not specially handled, vulnerabilities are doubled (i.e. both MN1->MN2 and MN2->MN1 BUs can be attacked). So the solution is to make a special case which provides stronger security. Paths from MN1 to MN2 are: MN1->MN2 MN1->HA1->MN2 MN1->HA2->MN2 MN1->HA1->HA2->MN2 The last one is very interesting: it is both the path used in bidirectional tunneling mode (the other mode if triangular routing is dropped) and a very safe path if HAs are near the core (i.e. this cancels possible vulnerabilities from wireless/cellular links where MNs are attached). Of course I assume (5.): MNx<->HAx tunnels are encrypted for RR messages. This is not the place for detailed proposal but I'd like to have a specific statement about this special case with some messages using paths though the two HAs with a (6.)-like stuff. I stop before to imagine how to provide RO^2 (:-). 5. In order to guarantee security of the above exchange, the HA-MN tunnel => [CLARIFICATION, CAN TOLERATE] What about the MN-HA way? Note that in many cases to provide the same protection in both ways is not more expensive (in fact can be simpler) than to provide it only in one way only. should be encrypted for the RR messages (but not necessarily for other messages on this tunnel). => [CLARIFICATION, AGREE] This has an impact about the BU format (i.e. destination options don't make good IPsec selectors). Note that there aren't similar scalability problems with this as there are with MN-CN security, since the home agents and mobile nodes must have an existing relationship anyway. => AGREE This could be done e.g. using IPsec ESP with pre-shared keys. => [CLARIFICATION, DISAGREE] Keys are SA keys (pre-shared is not the right term) or IKE pre-shared key authentication mode? In the second case the pre-shared key mode is known to have *real* problems with mobile nodes. 6. For CGA, the design team recommends that 1a/2a can be omitted for all but the initial exchange and periodic tests every few hours or perhaps once a day. => AGREE Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 9 12:54:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18242 for ; Sat, 9 Feb 2002 12:54:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17235; Sat, 9 Feb 2002 10:53:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12170; Sat, 9 Feb 2002 09:53:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19HqxFh029458 for ; Sat, 9 Feb 2002 09:52:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g19Hqx0G029457 for mobile-ip-dist; Sat, 9 Feb 2002 09:52:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19HqtFh029450 for ; Sat, 9 Feb 2002 09:52:55 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11538 for ; Sat, 9 Feb 2002 09:52:58 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17017 for ; Sat, 9 Feb 2002 09:52:57 -0800 (PST) Received: from jariws1 ([62.248.145.160]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020209175256.MCBW24910.fep01-app.kolumbus.fi@jariws1>; Sat, 9 Feb 2002 19:52:56 +0200 Message-ID: <005801c1b192$9c2fbb80$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" Cc: References: <200202091705.g19H5Vg92176@givry.rennes.enst-bretagne.fr> Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation Date: Sat, 9 Feb 2002 19:52:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thank you Francis for your in-depth response! A couple of quick responses below, I'll get to the rest later... > - the last concern is about the possible use of "external" security, > i.e. I can't find here a word about what one can do if one's already > got for instance IPsec protection of all communications with proper > (i.e. mobility aware) policies. In the same way, there is *nothing* > about the MN-HA (aka Home Registration (HR)) security or Binding > Acknowledgement (BA) security: something at least is missing in > this introduction... I agree. We need to talk about the external security, as well as the MN-HA security. > => [CLARIFICATION, CAN TOLERATE] (in fact I disagree but only > with the actual statement, not with the real idea). > The last statement is wrong because CNs can't offload computations > to HAs of MNs: CNs have no more reason to trust HAs than MNs, > this argument applies to any HA-based scheme (cf. Jean-Michel Combes). > So the property has no possible improvement for CNs in general. True, though there's an important exception: MNs that act as CNs *can* offload their CN-computations as well. I don't remember if we described this in draft-roe, but it's doable at least. >- second argument: the RR (in)security is based on the fact > the attacker should be near the CN, ideally on the HA-CN and MN-CN > paths. This assumption is reasonnable for fixed CNs (if the attacker > is in the core we already are in trouble without MIPv6) but > not always for mobile CNs. You argument seems right. But I need to think about this some more. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 9 13:29:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18670 for ; Sat, 9 Feb 2002 13:29:28 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03905; Sat, 9 Feb 2002 11:29:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16851; Sat, 9 Feb 2002 10:28:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19IS2Fh029593 for ; Sat, 9 Feb 2002 10:28:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g19IS2T2029592 for mobile-ip-dist; Sat, 9 Feb 2002 10:28:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g19IRxFh029585 for ; Sat, 9 Feb 2002 10:27:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16152 for ; Sat, 9 Feb 2002 10:28:00 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21618 for ; Sat, 9 Feb 2002 11:27:59 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g19IRua23095 for ; Sat, 9 Feb 2002 19:27:56 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA08739 for ; Sat, 9 Feb 2002 19:27:56 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g19IRtg92771 for ; Sat, 9 Feb 2002 19:27:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202091827.g19IRtg92771@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendati on In-reply-to: Your message of Tue, 05 Feb 2002 16:20:57 +0100. <4DA6EA82906FD511BE2F00508BCF053802C6A98C@Esealnt861.al.sw.ericsson.se> Date: Sat, 09 Feb 2002 19:27:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > because I still have some concerns about CGA. CGA may not > protect well for IPv4 mapped address, etc. => This is not a good example IMHO. mapped addresses are only used (on the wire) for SIIT. => the example is not good but the concern is real. A standard question in the IPv6 WG mailing list is "may I assume that IID have 64 bits" and the standard answer is no. Cf. draft-ietf-ipngwg-addr-arch-v3-07.txt: For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. So ::/3 unicast addresses may use another format. I don't know if this is a real concern for CGAs (this and the 1 bit stuff should be presented to the IPv6 WG or CGAs won't be available for more than MIPv6...). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 10 08:14:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06176 for ; Sun, 10 Feb 2002 08:14:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13557; Sun, 10 Feb 2002 06:13:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11532; Sun, 10 Feb 2002 05:13:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ADCbFh000425 for ; Sun, 10 Feb 2002 05:12:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1ADCbhr000424 for mobile-ip-dist; Sun, 10 Feb 2002 05:12:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ADCYFh000417 for ; Sun, 10 Feb 2002 05:12:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11402 for ; Sun, 10 Feb 2002 05:12:35 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28940 for ; Sun, 10 Feb 2002 06:12:34 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1ADCVa32140; Sun, 10 Feb 2002 14:12:31 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA13948; Sun, 10 Feb 2002 14:12:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1ADCUg94547; Sun, 10 Feb 2002 14:12:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202101312.g1ADCUg94547@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: vijayd@iprg.nokia.com, Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Thu, 07 Feb 2002 15:32:12 +0100. Date: Sun, 10 Feb 2002 14:12:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: RFC 2373 defines the details of the format when the universal bit is set. => draft-ietf-ipngwg-addr-arch-v3-07.txt is supposed to be better. However, EUI-64 addresses assigned to interfaces never have the group bit set. Thus I think it makes sense to reserve the combination universal = 1, group = 1. => I'd like to get these addresses reserved for universal addresses not-based on IEEE standards (i.e. please wait I've written my IMEI I-D! :-) RFC 2373 also talks about links without global identifiers, and this is used in RFC 2472 (PPP for IPv6) and RFC 3041. => I disagree for RFC 2472 but this is a detail. In order to have some spare space for potential future direction I think it makes sense to also reserve universal = 0, group = 1 even though that means that RFC 2472 and RFC 3041 (and implementations of those?) would need to be modified. => my interpretation of the one bit method is you split u=0 into u=0/g=0 and u=0/g=1, 0-0 becomes manual and RFC 3041, 0-1 becomes CGAs. If the IPv6 WG doesn't raise strong objection, this is fine. > 3. Assume, I have more than 2 mechanisms for BU authorization > (RR, RR+DH, RR+CGA, PKI, AAA). How does "1 bit" help here? > For this, (IMO) the obvious thing would be a set of bits > in the Binding Update. You dont have to specify this now. We > can do this later using the reserved bits in the BU. RR+DH seems to incur close to the same processing overhead as RR+CGA while not providing much more security that just RR. MiTM is still possible. => I agree, the concern is for other schemes. Infrastructure-based mechanisms might make sense in some cases. => so we have to support them. I have doubts whether a PKI would ever carry accurate information about what Home Addresses a given certificate has authority to create binding for. So personally I think that a PKI can be used in addition to whatever BU authorization mechanism there is (e.g. RR) to be able to provide corse level distinction between "known friends" and "others". => I disagree, a good PKI doesn't need RR (i.e. it works without RR or it doesn't work). I don't personally understand AAA-based authorization of binding updates would entail and whether it would fit into the architecture of AAA that the AAAwg is assuming to comment on that. => we are working on this (:-). But up-leveling - the property that "the low-order 64 bits of the address is allocated according to EUI-64" is currently encoded in the IPv6 address - it is a property of the address. The fact that "the low-order 64 bits is a of a public key" is also a property of the address, thus it would make sense to encode this in the address as well. The fact that a MN or CN uses AAA (or some other infrastructure) for pair-wise authentication and authorization is not a property of an IPv6 address. => I agree but be careful in your deductions because the authorization part of AAA can be "authorize to use this address". Another detail, this is not fully true that we don't know the security properties of CGAs because CGAs are related to anonymous Ho of HIP (draft-moskowitz-hip-05.txt). This is different than the bit being securely retrieved from the secure DNS before the communication started (and if you don't have DNSSEC you really don't care if you're communicating with the real peer or not :-) => I agree, DNSSEC seems to be a required step to the secure Internet. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 10 08:44:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06347 for ; Sun, 10 Feb 2002 08:44:22 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02824; Sun, 10 Feb 2002 06:44:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15372; Sun, 10 Feb 2002 05:43:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ADh7Fh000548 for ; Sun, 10 Feb 2002 05:43:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1ADh7uw000547 for mobile-ip-dist; Sun, 10 Feb 2002 05:43:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ADh3Fh000540 for ; Sun, 10 Feb 2002 05:43:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15282 for ; Sun, 10 Feb 2002 05:43:05 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18689 for ; Sun, 10 Feb 2002 06:43:04 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1ADh2a00803; Sun, 10 Feb 2002 14:43:02 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA14214; Sun, 10 Feb 2002 14:43:02 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1ADh2g94605; Sun, 10 Feb 2002 14:43:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202101343.g1ADh2g94605@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Vijay Devarapalli , Erik Nordmark , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Fri, 08 Feb 2002 10:14:25 +0100. Date: Sun, 10 Feb 2002 14:43:02 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > If a MN's home address ever changes, then it gets a new certificate. > Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a > few domains (eg a corporate network). And this should be the most > preferred BU Authorization mechanism whereever it is available. The details of why I think is unworkable in practise is a bit different depending on the nature of the CA. => you may think this is unworkable in practice in the general case but I don't understand why you don't accept this for particular cases. For instance DNSSEC can be used on reverse sub-trees of the DNS (reverse: address to name/properties maps) and can solve the authentication/ authorization problem of Mobile IPv6 on the part of the Internet it applies. If you look at the case of a large commercial CA, how could they possibly verify that a Home Address is assigned to box "owned" by Erik.Nordmark@sun.com (where that string is the name in the certificate)? => easy, put this user_FQDN/RFC-822 address as the (Alternate)SubjectName of the X.509 certificate pointed by the Home Address in DNSSEC. Doing this in order to initially list the Home Address in the cert doesn't seem tractable. Doing it every day when I decide to get an new RFC 3041 address seems even less likely to work. => please play with RFC 3041 too: to ask for both privacy and authentication is a bit unfair in this discussion. What about the case when my ISP or company renumbers the prefix on my link - how does the CA ever find out so that they can revoke that certificate which now has a stale Home Address? => this problem doesn't exist for DNSSEC (i.e. DNS mechanisms deal with it). If the case is that there is a more local CA (e.g. a company or an ISP running their own CA) I think there are also hard problems in creating the initial association between the certificate name and the Home Address placed in the certificate. => not for DNSSEC. My proposal to use the reverse tree is not neutral (this is the good way because obviously we'd like to get properties bound to the address). But it might be possible to throw people at the problem (i.e. I would get a phone call asking for verification or somebody would visit me in person). => the delegation mechanism of DNSSEC takes care of this kind of issue. But with a more local CA the question is how the trust is established between a CN using one CA and a MN using another CA. => Certificates encode trust, a not-technical mechanism is needed for this problem. > Trust me. It will work. We will soon see AAA-based BU authorization > mechanisms. (again wherever possible, this should be more preferred > than RR, RR+DH, RR+CGA mechanism). I didn't say it could not be built. I'm questioning whether it fits into the architecture of AAA (that architecture is that clients authenticate to the infrastructure - and not that the infrastructure helps clients authenticate eachother. The latter sounds a lot more like a PKI. While it's possible to make the AAA become a PKI as well it might not be the optimal solution). => for mobile IPv6, AAA can provide: - local network access control (very standard) - remote network access control (new but this is only the result of the availability of an AAA infrastructure) - trusted-third party (same because the AAA infrastructure is a trust one). AAA is a bit different than a PKI and perhaps more suitable (authorization is builtin in AAA for instance). I also have concerns about what it would mean for RFC 3041 temporary style addresses (when a user wants to minimize the relationship between the IP address used at the moment and any longer term name associated with the user). I all fairness, I think all infrastructure-based solutions (e.g. PKI and AAA) raise concerns in this area of enabling anonymity. => I agree but anonymity is both not required here (as near everywhere in the Internet) and the anonymity provided by RFC 3041 is questionable (to be politically correct :-). > Basically the above reinforces, what I had thought. The "1 bit method" > is very specific to RR+CGA mechanism. It does not help in any way > to select the other strong BU Authorization methods. > > I want to emphasize one point again. CGA is good for IPv6 and ND. I am > not against it. And the "1 bit mechanism" is good for distinguishing a > CGA address from another address. But that does not make it the best > mechanism to select from a bunch of BU Authorization mechanisms. I think you are correct on both of those points. => I share Vijay's concerns about the "1 bit mechanism". Question is whether that is a good thing or a bad thing. => it is not a bad thing if the "1 bit mechanism" is clearly dedicated to further CGA introduction, but it is if the "1 bit mechanism" is described as a general purpose mechanism. If there was e.g. a baked spec on how AAA based authorization would work at an abstract level (no need for packet formats) => there are three (two already published and the last one still been worked on) but they are mainly about MN-HA security (i.e. HR security in place of general BU security). and with what assumptions it might be possible to see what type of mechanisms would make sense for policy control in that space and how it would interact with the MIP nodes (MNs and CNs) that are not part of that AAA infrastructure. But until then at least me personally feel like I'm stumbling in the dark when it comes to AAA-based authorization of BUs. => so my question is that HRs are special BUs, do we develop a full special case or are any solution good for HRs available for BUs too in favourable cases? This seems to be Vijay's concern and I fully agree with him. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 10 09:04:47 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06521 for ; Sun, 10 Feb 2002 09:04:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19511; Sun, 10 Feb 2002 06:03:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18265; Sun, 10 Feb 2002 06:03:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1AE2WFh000679 for ; Sun, 10 Feb 2002 06:02:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1AE2Wrm000678 for mobile-ip-dist; Sun, 10 Feb 2002 06:02:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1AE2TFh000671 for ; Sun, 10 Feb 2002 06:02:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02666 for ; Sun, 10 Feb 2002 06:02:31 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05433 for ; Sun, 10 Feb 2002 07:02:29 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1AE2Ra01614; Sun, 10 Feb 2002 15:02:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA14385; Sun, 10 Feb 2002 15:02:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1AE2Rg94777; Sun, 10 Feb 2002 15:02:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202101402.g1AE2Rg94777@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Sat, 09 Feb 2002 19:52:58 +0200. <005801c1b192$9c2fbb80$8a1b6e0a@arenanet.fi> Date: Sun, 10 Feb 2002 15:02:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I agree. We need to talk about the external security, as well as the MN-HA security. => in an answer to an Erik's message about this, I specified we'd like to get both any kind of external security of the MN-HA/HR case and a way to import this into the general BU case, i.e. I'd like to keep the current "HR is just a special case of BU" style. > => [CLARIFICATION, CAN TOLERATE] (in fact I disagree but only > with the actual statement, not with the real idea). > The last statement is wrong because CNs can't offload computations > to HAs of MNs: CNs have no more reason to trust HAs than MNs, > this argument applies to any HA-based scheme (cf. Jean-Michel Combes). > So the property has no possible improvement for CNs in general. True, though there's an important exception: => I finished by "in general" because I expected your answer. MNs that act as CNs *can* offload their CN-computations as well. I don't remember if we described this in draft-roe, but it's doable at least. => I am in favour to make the MNs that act as CNs a full special case because its incredible number of possible nice specific improvements (i.e. offloading to its own HA is only one among many). >- second argument: the RR (in)security is based on the fact > the attacker should be near the CN, ideally on the HA-CN and MN-CN > paths. This assumption is reasonnable for fixed CNs (if the attacker > is in the core we already are in trouble without MIPv6) but > not always for mobile CNs. You argument seems right. But I need to think about this some more. => I am not in favour of mobile = wireless = cellular but in this context you may not give the same level of trust to core networks and wireless access infrastructures. The only counter argument to my advocacy for HA-HA path is this can be considered as an infrastructure solution (imagine you can encrypt the HA-HA path too). Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 10 23:15:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16497 for ; Sun, 10 Feb 2002 23:15:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17406; Sun, 10 Feb 2002 21:15:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09766; Sun, 10 Feb 2002 20:15:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B4EEFh001663 for ; Sun, 10 Feb 2002 20:14:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1B4EEgb001662 for mobile-ip-dist; Sun, 10 Feb 2002 20:14:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1B4EAFh001655 for ; Sun, 10 Feb 2002 20:14:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09693 for ; Sun, 10 Feb 2002 20:14:13 -0800 (PST) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06639 for ; Sun, 10 Feb 2002 21:14:09 -0700 (MST) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.6/8.11.6) with SMTP id g1B4E6K09830 for ; Mon, 11 Feb 2002 09:44:06 +0530 (IST) Received: from shiva (pcz-shiva.sasken.com [10.1.48.88]) by sunrnd2.sasken.com (8.11.6/8.11.6) with SMTP id g1B4E4Y20156 for ; Mon, 11 Feb 2002 09:44:04 +0530 (IST) Message-ID: <001f01c1b2b2$770ba820$5830010a@shiva> From: "Shiva Raman Pandey" To: Subject: [mobile-ip] New draft Date: Mon, 11 Feb 2002 09:43:31 +0530 Organization: Sasken Communication Technologies Limited MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C1B2E0.90B935C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C1B2E0.90B935C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A new draft in the domain of "Fast Handoff in Mobile IP" is available - Improved Low Latency Handoff in Mobile IPv4 =20 http://search.ietf.org/internet-drafts/draft-shiva-improved-lowlatency-ha= ndoff-v4-01.txt All are welcome to have a discussion over it. Please send your comments to shiva@sasken.com Regards Shiva ------=_NextPart_000_001C_01C1B2E0.90B935C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
A new draft in the domain of "Fast = Handoff in=20 Mobile IP" is available -
 
Improved Low Latency Handoff in Mobile=20 IPv4
           = ;=20
http://search.ietf.org/internet-drafts/draft-shi= va-improved-lowlatency-handoff-v4-01.txt
 
All are welcome to have a discussion = over=20 it.
Please send your comments to shiva@sasken.com
 
Regards
Shiva
------=_NextPart_000_001C_01C1B2E0.90B935C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 07:57:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29793 for ; Mon, 11 Feb 2002 07:57:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00596; Mon, 11 Feb 2002 04:55:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13750; Mon, 11 Feb 2002 04:55:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BCsxFh002233 for ; Mon, 11 Feb 2002 04:54:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BCsxDp002232 for mobile-ip-dist; Mon, 11 Feb 2002 04:54:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BCsuFh002225 for ; Mon, 11 Feb 2002 04:54:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19435 for ; Mon, 11 Feb 2002 04:54:58 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09945 for ; Mon, 11 Feb 2002 05:54:52 -0700 (MST) Received: from PATINET (patinet.u-strasbg.fr [130.79.90.172]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id NAA14871 for ; Mon, 11 Feb 2002 13:54:47 +0100 Message-ID: <00dc01c1b2fb$51d3e060$ac5a4f82@ustrasbg.fr> From: "Christophe Jelger" To: References: Subject: Re: [mobile-ip] Re: I-D ACTION:draft-jelger-mssmsv6-00.txt Date: Mon, 11 Feb 2002 13:55:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Pekka and thanks very much for your comments, I will try to answer your comments, indicating the paragraph number. 2.1.1 - Indeed, failure of the HA would cause disruption with MIP but is this comment very relevant to our draft? (I mean, this is not something we have tried to solve). - It's true that one single HA will not have to serve many mobile sources (statistically), but that does not mean that a solution should not be optimised if this rare event occurs (a HA with many mobile sources to serve). - BU authentication is obviously an important matter. I unfortunatly cannot follow the day-to-day talks about this subject on the mobile ip mailing list, but if the mobile ip wg finds a suitable way to do it for traditional unicast communications, the same solution could also be used in our proposed protocol. However, we currently study different mechanisms that could be used to authenticate the BU in our proposal (not for use in the traditional mobile ip operation). 2.2.1 - Method used to inform receivers about nCoA : this is the whole purpose of our draft. - Obviously receivers must have adequate functionality to process the new BU type (as explained in a latter section of the draft). - The global address (i.e. not the link-local address) of oAR is known as it is the previous AR of the MN (known in MIP) - Adding a reference to MSNIP draft : good comment, I will make sure it will be in the next version of the draft. - About MSNIP being out of the scope of the current draft : we still need time to investigate the proposed method, especially the use of encapsulated messages with MSNIP. 3. I will bare in mind your comment, but as far as I know, oAR does not need modifications (if we don't consider the authentication mechanism). 4. Actually there is no real tunnel establishment between oAR and MN, we just use IP-IP encapsulation. Obviously, this matter needs further investigation to check the behaviour of oAR I am afraid but I do not fully understand your last point about "killing" old sessions. Could you please re-formulate ? And last, you are right when saying that multicast BU needs further in depth investigation. This is something we are currently doing. Thanks again for your comments which are greatly appreciated. There are still many things we need to check and validate before submitting a second version of the draft and we are very opened to suggestions and critical comments from other researchers. Therefore, comments are welcome as they allow us to see problems that we haven't thought about. Best regards, Christophe ----- Original Message ----- From: "Pekka Savola" To: Cc: ; ; Sent: Friday, February 08, 2002 4:48 PM Subject: [mobile-ip] Re: I-D ACTION:draft-jelger-mssmsv6-00.txt > On Wed, 23 Jan 2002 Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : Supporting Mobile SSM Sources for IPv6 (MSSMSv6) > > Author(s) : C. Jelger, T. Noel > > Filename : draft-jelger-mssmsv6-00.txt > > Pages : 11 > > Date : 22-Jan-02 > > A few comments I made on a flight. > > 2.1.1 Advantages and drawbacks > > [...]. A failure of the HA would cause multiple multicast delivery > disruptions. > > ==> Failure of the HA would, AFAICS, cause disruptions for MIP traffic > too: so nothing new there. > > Third, the processing task of the HA increases with the > number of mobile sources it serves, thus reducing the efficiency of > the multicast delivery and increasing the probability of a failure. > > ==> How many Mobile multicast-sourcing nodes would you expect a random HA > will have to serve? > > ==> In general, this mechanism makes delivery more unstable: moving > sources send BU's to recipients. Recipients must authenticate those BU's > (e.g. with return routability (with multicast??)). You force the burden > on multiple recipients, when the same could be done at one place, mobile > source. > > ==> Also, in multicast I don't think it's that usual that sending latency > is that big a problem: communication is mostly one-way. > > 2.2.1 Source handover > When a mobile SSM source moves into a new subnet, it must inform the > multicast receivers about its new Care_of-Address (nCoA). > > ==> inform how? > > ==> what about recipients not implementing BU processing or not having it > enabled? > > the BU message must be encapsulated towards the old > Access Router (oAR) > > ==> how is oAR known? Note that remembering link-local address from route > advertisements is not enough (:-) > > This > notification could be done via the Multicast Source Notification of > Interest Protocol (MSNIP) but it is out of the scope of this > document. > > ==> Add a reference to MSNIP draft. > > ==> I'm a bit curious why exactly this is "out of scope"... > > ==> Around this place in the draft there seems to be significant > duplication of tex with section 2.2.3. > > SHOULD forward the multicast datagrams sent by the MN from the new > subnet onto its local interfaces (e.g. interfaces binded with the > > ==> s/binded/bound/ > > 3. Implementation requirements > > ==> You forget new requirements for oAR's > > 4. Security Considerations > > The proposed protocol MSSMSv6 does not introduce new security > problems that those already present in MIPv6 and PIM-SSM. > > ==> A daring thing to say. > > ==> How is the tunnel between oAR and MN established? Does oAR have to > blindly decapsulate the packets from everywhere? This is a huge risk. > Remember that oAR doesn't need to know _anything_ about nodes visiting its > subnet (it's not IPv4 Foreign Agent)... > > ==> About BU with optional SSM destination option. Could MN cause > recipient that marginally trusts it join new SSM sessions (nothing related > to what MN is originating, for example) and possibly subsequently have it > kill old ones? > > ==> BU with multicast destination will need a _lot_ more thorough analysis > I think. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 08:16:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00549 for ; Mon, 11 Feb 2002 08:16:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24161; Mon, 11 Feb 2002 06:16:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23524; Mon, 11 Feb 2002 05:16:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BDEwFh002310 for ; Mon, 11 Feb 2002 05:14:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BDEwxQ002309 for mobile-ip-dist; Mon, 11 Feb 2002 05:14:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BDEnFh002302 for ; Mon, 11 Feb 2002 05:14:50 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BDEkM12666; Mon, 11 Feb 2002 14:14:47 +0100 (MET) Date: Mon, 11 Feb 2002 14:10:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Erik Nordmark , Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <200202101343.g1ADh2g94605@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > If a MN's home address ever changes, then it gets a new certificate. > > Why wouldnt this work? IMHO, PKI + IKE + IPSec would work for a > > few domains (eg a corporate network). And this should be the most > > preferred BU Authorization mechanism whereever it is available. > > The details of why I think is unworkable in practise is a bit different > depending on the nature of the CA. > > => you may think this is unworkable in practice in the general case > but I don't understand why you don't accept this for particular > cases. For instance DNSSEC can be used on reverse sub-trees of the DNS > (reverse: address to name/properties maps) and can solve the authentication/ > authorization problem of Mobile IPv6 on the part of the Internet it applies. DNSSEC wasn't intended to be a PKI last time I looked :-) I don't claim I understand the issues involved in making DNSSEC for the in6.arpa tree be a PKI providing certificates and implicit authorization for binding updates. If you'd like to run this idea by namedroppers you'd get better feedback than on the mobile-ip mailing list. So I'd urge you to make a proposal there. > Doing this in order to initially list the Home Address in the cert doesn't > seem tractable. Doing it every day when I decide to get an new RFC 3041 > address seems even less likely to work. > > => please play with RFC 3041 too: to ask for both privacy and authentication > is a bit unfair in this discussion. With e.g. CGA you can provide a cryptographically strong proof that you are the same as the Home Address without actually having to say who "you" are. So I don't think it is important to take into account the difference, when proving address ownership, whether the address must or must not be tied to a cerificate. They have very different privacy implications. > => for mobile IPv6, AAA can provide: > - local network access control (very standard) > - remote network access control (new but this is only the result > of the availability of an AAA infrastructure) If I understand what you are saying this is the same as what is already being done with Radius - a remote (home) entity performs the authentication, > - trusted-third party (same because the AAA infrastructure is a trust one). > AAA is a bit different than a PKI and perhaps more suitable (authorization > is builtin in AAA for instance). Authorization of a client to the AAA is built it. But this seems rather different than having the AAA infrastructure be an intermediary between two clients (the MN and CN) of the AAA with the purpose of gettting those to clients to trust eachother. > => I agree but anonymity is both not required here (as near everywhere > in the Internet) and the anonymity provided by RFC 3041 is questionable > (to be politically correct :-). You don't think the ability to be anonymous is important or you don't think the ability to be anonymous at the IPv6 address level is important? > => it is not a bad thing if the "1 bit mechanism" is clearly dedicated > to further CGA introduction, but it is if the "1 bit mechanism" is > described as a general purpose mechanism. > > If there was e.g. a baked spec on how AAA based authorization would work > at an abstract level (no need for packet formats) > > => there are three (two already published and the last one still been > worked on) but they are mainly about MN-HA security (i.e. HR security > in place of general BU security). > > and with what assumptions > it might be possible to see what type of mechanisms would make > sense for policy control in that space and how it would interact with > the MIP nodes (MNs and CNs) that are not part of that AAA infrastructure. > But until then at least me personally feel like I'm stumbling in the dark > when it comes to AAA-based authorization of BUs. > > => so my question is that HRs are special BUs, do we develop a full special > case or are any solution good for HRs available for BUs too in favourable > cases? This seems to be Vijay's concern and I fully agree with him. What is a "HR"? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 09:02:50 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02274 for ; Mon, 11 Feb 2002 09:02:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02272; Mon, 11 Feb 2002 07:02:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07005; Mon, 11 Feb 2002 06:02:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BE1KFh002397 for ; Mon, 11 Feb 2002 06:01:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BE1Kjf002396 for mobile-ip-dist; Mon, 11 Feb 2002 06:01:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BE1GFh002389 for ; Mon, 11 Feb 2002 06:01:16 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BE1FM17767; Mon, 11 Feb 2002 15:01:15 +0100 (MET) Date: Mon, 11 Feb 2002 14:57:09 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: bidding down To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C630BBC.576D0EBC@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, You seem to be making the implicit assumption that a MN would always immediately try to setup RO. I think we want to keep the door open for MNs which e.g. perform some form of flow detection before establishing the RO. That seems to be problematic if the CN might have a BCE created by an attacker using RR. > Suppose we are using a simple rule in CN which > tags BCE telling how it was authorized and refuses > BUs with lower-priority authorizations during the > lifetime of a BCE but any time accepts authorizations > of the same or higher method. Legitimate MN is never > blocked from regaining the BCE nor can it lose it > when it needs the BCE. When legitimate MN is not > communicating, it should be enough for the CN > to expire unused BCEs injected by RR attacker > for the CN to be able to communicate with the > legitimate MN, and/or always start its sessions > with non RO data packet despite BCE. The "starts its session" seems to imply that the IP layer, when choosing whether or not to use a RR BCE, needs to be able to identify a new session indepedently of the transport and application protocol. For TCP and SCTP I can see us doing this, but what about some yet to be invented protocol over (congestion controlled) UDP? Reliable multicast? It seems impossible to make this distinction in general. > When the true MN initiates the RO connection it chooses > a higher method and no RR attacker even from CN-HA path > can change that by RR during the lifetime of the BCE, > since it only accepts CGA or higher. The BCE can only > be refreshed by the higher method run by the original > MN during the time of the BCE being needed. If the attacker > can block those legitimate messages, it can tamper with > forwarding and do more harm even without MIPv6. If the attacker is actually on the CN - HA path it can presumably cause that attempt to establish RO with CGA security fail by dropping the relevant packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 09:08:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02661 for ; Mon, 11 Feb 2002 09:08:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14019; Mon, 11 Feb 2002 07:07:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07973; Mon, 11 Feb 2002 06:07:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BE76Fh002450 for ; Mon, 11 Feb 2002 06:07:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BE76El002449 for mobile-ip-dist; Mon, 11 Feb 2002 06:07:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BE72Fh002442 for ; Mon, 11 Feb 2002 06:07:02 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BE71M18251; Mon, 11 Feb 2002 15:07:01 +0100 (MET) Date: Mon, 11 Feb 2002 15:02:55 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Brian.Haley@compaq.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202082305.AA31108@dogbert.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik Nordmark wrote: > > > > Do people see strong arguments for/against handling the "source HoA" and > > > > the destination "HoA" using the same mechanism? > > > > > > One shouldn't impose symmetry on the handling of addresses that > > > are to be used for different purposes entirely. > > > > We seem to agree that the HoA in a HAO sent *from* a MN serves to > > identify the MN. > > The above statement of "different purpose" seem to say that the HoA in a > packet > > sent *to* a MN does not identify the MN? I'm confused - either the home > > address identifies the MN or it does not - this can't depend on what type of > > packet the HoA is contained in. > > Erik, > > Maybe I mis-understood your second sentence in this reply: > > "... the HoA in a packet sent *to* a MN does not identify the MN?" > > Surely the HoA identifies the sending MN, but it can't identify the > receiving MN. There must be a way to specify the Home Source Address and > Home Destination Address (aka RH right now) independently, since MN to MN > traffic needs this to work (4 addresses in the packet). Perhaps acronym confusion? But HoA I mean Home Address which is different than HAO = Home Address Option. So restating what I said without acronomyns: The above statement of "different purpose" seem to say that the home address in a packet sent *to* a MN does not identify the MN? This home address could be contained in a RH or somewhere else - its location in the packet wasn't the part of this particular issue - but instead the semantics of the Home Address in packets sent from as well as to a MN. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 09:23:43 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03367 for ; Mon, 11 Feb 2002 09:23:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10745; Mon, 11 Feb 2002 07:23:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02104; Mon, 11 Feb 2002 06:23:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BEMGFh002529 for ; Mon, 11 Feb 2002 06:22:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BEMGZ5002528 for mobile-ip-dist; Mon, 11 Feb 2002 06:22:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BEMCFh002521 for ; Mon, 11 Feb 2002 06:22:12 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BEMAM20647; Mon, 11 Feb 2002 15:22:11 +0100 (MET) Date: Mon, 11 Feb 2002 15:18:02 +0100 (CET) From: Erik Nordmark Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202091705.g19H5Vg92176@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > - Several IPR claims have been made regarding CGA. > > => [ISSUE, DISAGREE] I live in a country where software patents > are explicitely excluded by the law but with some pros. and > cons. pressures about them, so I can have a distorted view of > the IPR problem... My concern is about free softwares: I really > want to *never* see a BSD or Linux development stopped because > a standard is subject to IPR. In fact the problem is there is > no provision for free softwares in RFC 2026 10.3.2 (C) and we > rely more and more on free/open source softwares. Francis, I'm trying to understand what you disagree with. You seem to disagree with software patents or at least have concerns in this area, but that seems to be out of scope (we can't change the legal situation for patents in this WG :-) I don't think you disagree with the actual text i.e. that several IPR claims have been made. So do you think that 1) we shouldn't take these IPR claims into account? 2) we should take these IPR claims into account? > => [CONCLUSION, DISAGREE] (this is about 4 and 5 but I put it here) > An important case, both likely common in the future and with > critical vulnerabilities, is *not* addressed: mobile to mobile. > - first argument: there is no reason to have only fixed CNs > and RO can be very interesting (i.e. give far better performance) > when the CN itself is mobile, for instance in the same network. > (this is the important exception of my philosophical/first concern, > IMHO this case is worth our consideration). > - second argument: the RR (in)security is based on the fact > the attacker should be near the CN, ideally on the HA-CN and MN-CN > paths. This assumption is reasonnable for fixed CNs (if the attacker > is in the core we already are in trouble without MIPv6) but > not always for mobile CNs. > The situation is symmetrical, if the mobile to mobile case is not > specially handled, vulnerabilities are doubled (i.e. both MN1->MN2 > and MN2->MN1 BUs can be attacked). So the solution is to make > a special case which provides stronger security. > Paths from MN1 to MN2 are: > MN1->MN2 > MN1->HA1->MN2 > MN1->HA2->MN2 > MN1->HA1->HA2->MN2 > The last one is very interesting: it is both the path used in > bidirectional tunneling mode (the other mode if triangular > routing is dropped) and a very safe path if HAs are near > the core (i.e. this cancels possible vulnerabilities from > wireless/cellular links where MNs are attached). Of course > I assume (5.): MNx<->HAx tunnels are encrypted for RR messages. > This is not the place for detailed proposal but I'd like to > have a specific statement about this special case with some > messages using paths though the two HAs with a (6.)-like stuff. > I stop before to imagine how to provide RO^2 (:-). As far as I can recall the design team hasn't discussed this - at least not in greate detail. I personally hope that we can make MN to MN binding updates more secure by relying on the secure path between each MN and their HA. In fact the BU3WAY spec presents one way to do this without adding any more complexity to the exchanges but instead just making sure that RR control packets sourced with a Home Address get reverse tunneled over the secure tunnel. So I personally agree with you that the design team should make clear recommendations in this space. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 09:30:27 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03633 for ; Mon, 11 Feb 2002 09:30:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13319; Mon, 11 Feb 2002 07:30:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02858; Mon, 11 Feb 2002 06:30:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BETPFh002572 for ; Mon, 11 Feb 2002 06:29:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BETPFS002571 for mobile-ip-dist; Mon, 11 Feb 2002 06:29:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BETKFh002564 for ; Mon, 11 Feb 2002 06:29:21 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BETJM21554; Mon, 11 Feb 2002 15:29:19 +0100 (MET) Date: Mon, 11 Feb 2002 15:25:11 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: rajeev@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <3C6412FC.EB7AEDD2@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Here is a simple proposal to allow selection of alternative BU authorization > schemes. Perhaps you folks have already thought about it.. In any case, I > would appreciate your feedback. > > The objective is to securely indicate to the CN the MN's intention to > use a "better BU method". For this, why not include a signed hash covering a > "selector" byte in the RR messages ? For instance, > > - the MN sends Nonce N1, and an 8-bit integer "selector" > set to "better BU" mechanism in 1b. > > - the MN sends Nonce N2, and a signed hash of N1, N2, the > "selector" field and the MN's Public Key in 1a. > > -the CN would verify the hash before accepting the method > outlined in the "selector" field for BU authorization. > > The selector field can take different values including RR only, RR+DH, > RR+CGA etc. Imagine an attacker between the CN and the MN. Such an attacker can send packets to the CN claiming to want to use RR for BU security and can claim that the CoA is either itself, another address for which it is also on the path for, or a co-conspirator. It can then do the above exchange without any problems. Since the attacker is on the path(s) it can presumably also prevent the packets from being delivered to the MN, thus the MN wouldn't be aware of this. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 09:39:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03814 for ; Mon, 11 Feb 2002 09:39:34 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23763; Mon, 11 Feb 2002 07:39:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04276; Mon, 11 Feb 2002 06:39:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BEaPFh002625 for ; Mon, 11 Feb 2002 06:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BEaOLl002624 for mobile-ip-dist; Mon, 11 Feb 2002 06:36:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BEaKFh002617 for ; Mon, 11 Feb 2002 06:36:21 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BEaFM22418; Mon, 11 Feb 2002 15:36:15 +0100 (MET) Date: Mon, 11 Feb 2002 15:32:07 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Vijay Devarapalli Cc: Jari Arkko , Rajeev Koodli , mobile-ip@sunroof.eng.sun.com, basavaraj.patil@nokia.com, Erik.Nordmark@eng.sun.com, phil.roberts@megisto.com, jmalinen@iprg.nokia.com In-Reply-To: "Your message with ID" <3C64263E.3CAD8640@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > When the MN is active and has a active binding at the CN > created through RR+CGA, an attacker cannot bid down. For > details, see Jari Malinen's mail that was sent out yesterday. I expressed some concerns with Jari Malinen's proposal earlier today having to do with two assumptions: - that the IP layer on the CN know what is "start of a new session" - that RO will always be setup immediatly at the start of a new session (as opposed to the possibility of deferring RO until there appears to be a "flow" of packets that would benefit from the optimization) > When the MN is active and is initiating RR+CGA as described > in Rajeev's mail, an attacker cannot bid down because > he cant see 1b. Is this the case when the CN already has a BCE for the real MN? > You are saying that the attacker could create a binding > at the CN when the MN is not active, right? But I am saying > that when the MN comes back alive, it is going to initiate > RR+CGA binding at the CN (it WILL because it does not have > a corresponding Binding Update List entry for the CN). The > binding created by the attacker is invalidated. You are assuming that the MN will immediately setup RO. When sending e.g. queries to a DNS server (a single request response) it might not make sense to setup RO before the exchange. What if the DNS servers (the resolvers) that the MN is configured to use have bogus BCEs for the MN? > So the "1 bit method" just prevents the following. It > prevents the attacker from creating a binding at the CN > when the MN is inactive. Also for this to work the CN has > to have obtained the MN's address through DNSSEC. Whats > the big deal in this? Not worth modifying two RFCs for > this extra protection. Not only. If the MN is active and reachable, but has not setup a BCE on a particular CN then the attack could still succeed since the attacker is on the path between the CN and HA (in order to attack RR) and it can thus prevent packets from reaching the MN through its Home Address. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 09:50:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04197 for ; Mon, 11 Feb 2002 09:50:33 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27874; Mon, 11 Feb 2002 07:50:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05611; Mon, 11 Feb 2002 06:50:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BEmoFh002707 for ; Mon, 11 Feb 2002 06:48:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BEmog0002706 for mobile-ip-dist; Mon, 11 Feb 2002 06:48:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BEmiFh002699 for ; Mon, 11 Feb 2002 06:48:45 -0800 (PST) Received: from lillen (vpn-129-156-96-39.EMEA.Sun.COM [129.156.96.39]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BEmcM23793; Mon, 11 Feb 2002 15:48:38 +0100 (MET) Date: Mon, 11 Feb 2002 15:44:26 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Vijay Devarapalli Cc: Erik Nordmark , Jari Arkko , basavaraj.patil@nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C646FA5.6E6F28A3@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I am not sure if you have taken a look at the following draft. > > http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt > > It uses RR+DH to create MN-CN security association. This draft > also gives an example where DH method can take advantage of > AAA (wherever available) to eliminate MiTM attacks that DH is > prone to. > Yes, but I think this draft departs from the tradional model of AAA in that it makes the AAA infrstructure a "pass through" as examplified by the AAA sending out packets to the CN: * Then CN's AAAh: - forwards DH(CN), MAC(Ki) to CN - verfies MAC(K1) and if valid, computes DH(MN), MAC(Kj) The AAA was architected around the AAA being a service that could perform authentication of clients on a global scale and pass back configuration information that carries no semantics in the AAA itself. What draft-le-mobileip-dh is proposing is to make the AAA aware of the semantics of these extensions which means that the AAA code needs to be modified on the servers. I'm not convinced this is the right path. It might be better to just make the AAA servers an explicit PKI with cross-certificates etc. Also, it wasn't clear from the draft how the AAA does the authorization of an address. Imagine I (NAI=erik.nordmark@sun.com) appear at some random ISP and get authenticated. The ISP assigned me a CoA (e.g. using RC 2462 stateless addrconf) and I communicate with the AAA. Is the assumption that my AAAh has a pre-configured list mapping NAI->home address for all nodes in sun.com? What if my home network renumbers (mipv6 allows for this) - how does this mapping get updated? What if my MN wants to use a RFC 3041 home address - how does the mapping in my home AAA get updated? > PS: I agree with you that there is currently no concrete > proposal for the "other" BU Authorization mechanisms that I > am talking about. But by adopting this "1 bit method" (or > 2 bits as described in your mail), I fear there might be no > room for selecting these mechanisms later on. I just think that they need to be selected using other means, but since I clueless enough to not understand the big picture for infracstrcuture-based BU authorization I can't speculate on how. But a larger question which nobody has asked is whether the better CGA defense against future attacks and less frequent HoA RR checks warrant the additional complexity of CGA. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 11:22:17 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07984 for ; Mon, 11 Feb 2002 11:22:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04448; Mon, 11 Feb 2002 09:21:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08203; Mon, 11 Feb 2002 08:21:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BGKmFh002899 for ; Mon, 11 Feb 2002 08:20:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BGKmb7002898 for mobile-ip-dist; Mon, 11 Feb 2002 08:20:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BGKjFh002891 for ; Mon, 11 Feb 2002 08:20:45 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06971 for ; Mon, 11 Feb 2002 08:20:47 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26964 for ; Mon, 11 Feb 2002 08:20:44 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1BGKhB03909 for ; Mon, 11 Feb 2002 17:20:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Feb 11 17:20:42 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Feb 2002 17:20:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A9D7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Vijay Devarapalli Cc: Jari Arkko , basavaraj.patil@nokia.com Subject: RE: [mobile-ip] BU Authorization method: design team recommendati on Date: Mon, 11 Feb 2002 17:20:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik, > > Also, it wasn't clear from the draft how the AAA does the > authorization > of an address. > Imagine I (NAI=erik.nordmark@sun.com) appear at some random ISP > and get authenticated. > The ISP assigned me a CoA (e.g. using RC 2462 stateless addrconf) > and I communicate with the AAA. > Is the assumption that my AAAh has a pre-configured list > mapping NAI->home > address for all nodes in sun.com? => Yes, also see : http://search.ietf.org/internet-drafts/draft-soliman-mobileip-routeopt-mipv6-02.txt But before that please see below. > What if my home network renumbers (mipv6 allows for this) - > how does this > mapping get updated? => In a very difficult way ! > What if my MN wants to use a RFC 3041 home address - how > does the mapping > in my home AAA get updated? => Same as above :) Our (the authorsof this draft) conclusion was that this solution was needed in the absence of an e2e infrastructureless solution, and assuming that AAA will be deployed widely. Also this solution would need extensive standardisation between PANA and AAA. Since now we saw that there is a more secure (*) infrastructureless way of doing things (RR or RR+CGA), I don't see any technical advantage for pursuing the AAA approach. Previously the main advantage was that it can be used to authorise addresses (assuming AAA servers trusted each other). Hesham (*) RR + CGA is more secure since the AAA servers will not know the keys. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 12:37:42 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12130 for ; Mon, 11 Feb 2002 12:37:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01485; Mon, 11 Feb 2002 09:34:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00410; Mon, 11 Feb 2002 09:34:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BHX6Fh003032 for ; Mon, 11 Feb 2002 09:33:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BHX5E3003031 for mobile-ip-dist; Mon, 11 Feb 2002 09:33:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BHX2Fh003024 for ; Mon, 11 Feb 2002 09:33:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29998 for ; Mon, 11 Feb 2002 09:33:05 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18258 for ; Mon, 11 Feb 2002 10:33:04 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1BHWta04259; Mon, 11 Feb 2002 18:32:55 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA13396; Mon, 11 Feb 2002 18:32:56 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1BHWsg99079; Mon, 11 Feb 2002 18:32:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202111732.g1BHWsg99079@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Mon, 11 Feb 2002 14:10:40 +0100. Date: Mon, 11 Feb 2002 18:32:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: DNSSEC wasn't intended to be a PKI last time I looked :-) => RFC 2538... DNSSEC is not a real PKI but is enough for this purpose. If you'd like to run this idea by namedroppers you'd get better feedback than on the mobile-ip mailing list. So I'd urge you to make a proposal there. => there are many messages about this in the IPsec mailing list (DNSSEC was proposed in an opportunistic IPsec document). And the new DNSSEC key distribution mailing list is both the best forum and well known by namedroppers... If I understand what you are saying this is the same as what is already being done with Radius - a remote (home) entity performs the authentication, => yes. But this seems rather different than having the AAA infrastructure be an intermediary between two clients (the MN and CN) of the AAA with the purpose of gettting those to clients to trust eachother. => no, third trust-party: the MN and the CN trust the AAA so they can trust each other (of course we have to explain what they trust about). > => I agree but anonymity is both not required here (as near everywhere > in the Internet) and the anonymity provided by RFC 3041 is questionable > (to be politically correct :-). You don't think the ability to be anonymous is important or you don't think the ability to be anonymous at the IPv6 address level is important? => I believe the ability to be anonymous was never a concern for the Internet architects and if it becomes a concern something better than RFC 3041 will be needed. BTW only location privacy is listed in the mobile-ip WG charter. > => so my question is that HRs are special BUs, do we develop a full special > case or are any solution good for HRs available for BUs too in favourable > cases? This seems to be Vijay's concern and I fully agree with him. What is a "HR"? => Home Registrations. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 13:02:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12728 for ; Mon, 11 Feb 2002 13:02:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04624; Mon, 11 Feb 2002 11:02:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11120; Mon, 11 Feb 2002 10:02:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BI15Fh003205 for ; Mon, 11 Feb 2002 10:01:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BI15oa003204 for mobile-ip-dist; Mon, 11 Feb 2002 10:01:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BI12Fh003197 for ; Mon, 11 Feb 2002 10:01:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12240; Mon, 11 Feb 2002 10:01:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03733; Mon, 11 Feb 2002 11:01:03 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1BI11a07612; Mon, 11 Feb 2002 19:01:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA14028; Mon, 11 Feb 2002 19:01:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1BI11g99234; Mon, 11 Feb 2002 19:01:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202111801.g1BI11g99234@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Mon, 11 Feb 2002 15:18:02 +0100. Date: Mon, 11 Feb 2002 19:01:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I don't think you disagree with the actual text i.e. that several IPR claims have been made. => I disagree about the consequences of this fact, not about the fact. So do you think that 1) we shouldn't take these IPR claims into account? 2) we should take these IPR claims into account? <- this one of course => we shouldn't take the proposal (CGAs) into account until the IPR issue is at least clarified, or we stand a good chance of losing our time. I believe we are doing a dangerous bet about CGAs... Of course this is out of our scope as technical persons. As far as I can recall the design team hasn't discussed this - at least not in great detail. => this is exactly my concern. I personally hope that we can make MN to MN binding updates more secure by relying on the secure path between each MN and their HA. In fact the BU3WAY spec presents one way to do this without adding any more complexity to the exchanges but instead just making sure that RR control packets sourced with a Home Address get reverse tunneled over the secure tunnel. So I personally agree with you that the design team should make clear recommendations in this space. => so I'll switch for an agreement soon, shan't I? Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 13:03:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12777 for ; Mon, 11 Feb 2002 13:03:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13149; Mon, 11 Feb 2002 11:02:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11415; Mon, 11 Feb 2002 10:02:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BI1nFh003222 for ; Mon, 11 Feb 2002 10:01:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BI1naR003221 for mobile-ip-dist; Mon, 11 Feb 2002 10:01:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BI1jFh003207 for ; Mon, 11 Feb 2002 10:01:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10784 for ; Mon, 11 Feb 2002 10:01:48 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04230 for ; Mon, 11 Feb 2002 11:01:47 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1BI1jh14875 for ; Mon, 11 Feb 2002 10:01:46 -0800 (PST) Received: from cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABR79055; Mon, 11 Feb 2002 10:01:20 -0800 (PST) Message-ID: <3C680703.8FF2D174@cisco.com> Date: Mon, 11 Feb 2002 10:01:39 -0800 From: Alpesh Patel X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <3C631BEA.227F75B6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, Scott responded that this has been fixed and I should not file a ddts. I am a DE and not DT. Guess, you have fixed this issue. Wondering if you still want me to load the image :) thx -a Peter Xie wrote: > Can you try this image and see if it still crashes? > > /tftpboot/ppxie/c3640-ik9s-mz.0110-pi4.dw15572sf > > Thanks, > --Peter > > On Thu, 7 Feb 2002, Alpesh S. Patel wrote: > > > Team, > > > > In one of the images built off itd_flo_t_pi4, I used the local-address > > keyword and associated with a loopback interface which did not exist. > > This > > crashed the box. I could reproduce this twice; am pretty sure nothing > > else > > was responsible. Can someone from your devtest try this out real quick. > > > > Thanks > > Alpesh > > From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 14:49:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15246 for ; Mon, 11 Feb 2002 14:49:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22471; Mon, 11 Feb 2002 12:49:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21456; Mon, 11 Feb 2002 11:48:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BJlvFh003647 for ; Mon, 11 Feb 2002 11:47:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BJlv8o003646 for mobile-ip-dist; Mon, 11 Feb 2002 11:47:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BJlqFh003639 for ; Mon, 11 Feb 2002 11:47:53 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BJlgM29130; Mon, 11 Feb 2002 20:47:43 +0100 (MET) Date: Mon, 11 Feb 2002 20:43:33 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <200202111732.g1BHWsg99079@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => there are many messages about this in the IPsec mailing list > (DNSSEC was proposed in an opportunistic IPsec document). > And the new DNSSEC key distribution mailing list is both the best forum > and well known by namedroppers... namedroppers or keydist - either one works for me. > But this seems rather different than having the AAA infrastructure be an > intermediary between two clients (the MN and CN) of the AAA with the > purpose > of gettting those to clients to trust eachother. > > => no, third trust-party: the MN and the CN trust the AAA so they can trust > each other (of course we have to explain what they trust about). From a trust perspective, yes, but that wasn't my point. What I was trying to refer to is some abstract notion of information flow where the model using AAA seems to make information flow from MN -> AAAh1 -> AAAh2 -> CN Which is very different that the traditional model of MN -> AAAl -> AAAh and a reply AAAh -> AAAl -> MN In the former case the AAA needs to know that it needs to contact the CN at the other end, whereas in the latter case it is just the AAA returning attributes. Something that fits the traditional model better is to do more of a PIC-like architecture where - CN is configured to accept certificates signed by AAAh2 for the purposes of BU authorization - MN -> AAAh1 -> AAAh2 returns such a short-lived certificate to MN - MN presents this to CN e.g. using IKE > You don't think the ability to be anonymous is important or > you don't think the ability to be anonymous at the IPv6 address level > is important? > > => I believe the ability to be anonymous was never a concern for > the Internet architects and if it becomes a concern something better > than RFC 3041 will be needed. BTW only location privacy is listed > in the mobile-ip WG charter. Times change. Back in the 1980 Internet security wasn't much of a concern either. > > => so my question is that HRs are special BUs, do we develop a full > special > > case or are any solution good for HRs available for BUs too in > favourable > > cases? This seems to be Vijay's concern and I fully agree with him. > > What is a "HR"? > > => Home Registrations. I don't know exactly what is desirable for HR. An "easy" approach would just be to use IKE + ESP for those, but that means that MNs need to implement IKE. Just using ESP with manual keys means that IPsec can't provide replay protection but a simple sequence number in the HRs (or a cookie exchange - but that adds a round-trip) would handle the replay protection for HRs. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:10:44 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15854 for ; Mon, 11 Feb 2002 15:10:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08029; Mon, 11 Feb 2002 12:07:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15135; Mon, 11 Feb 2002 12:07:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BK6cFh003768 for ; Mon, 11 Feb 2002 12:06:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BK6cIU003767 for mobile-ip-dist; Mon, 11 Feb 2002 12:06:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BK6ZFh003760 for ; Mon, 11 Feb 2002 12:06:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14825 for ; Mon, 11 Feb 2002 12:06:37 -0800 (PST) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17543 for ; Mon, 11 Feb 2002 13:06:36 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BK8TQ00055 for ; Mon, 11 Feb 2002 14:08:29 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 11 Feb 2002 14:06:36 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 14:06:18 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Mon, 11 Feb 2002 14:06:18 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8118761E3@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGzC64MQr2szZnaQ3i65IskGUAsJwAKkBTQ To: X-OriginalArrivalTime: 11 Feb 2002 20:06:18.0745 (UTC) FILETIME=[916C4690:01C1B337] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1BK6ZFh003761 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Erik, Thanks for your comments, Please find some below: > > I am not sure if you have taken a look at the following draft. > > > > http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt > > > > It uses RR+DH to create MN-CN security association. This draft > > also gives an example where DH method can take advantage of > > AAA (wherever available) to eliminate MiTM attacks that DH is > > prone to. > > > > Yes, but I think this draft departs from the tradional model of AAA > in that it makes the AAA infrstructure a "pass through" as examplified > by the AAA sending out packets to the CN: Yes that is correct > * Then CN's AAAh: > > - forwards DH(CN), MAC(Ki) to CN > > - verfies MAC(K1) and if valid, computes DH(MN), MAC(Kj) > > The AAA was architected around the AAA being a service that > could perform > authentication of clients on a global scale and pass back > configuration > information that carries no semantics in the AAA itself. > What draft-le-mobileip-dh is proposing is to make the AAA aware of the > semantics of these extensions which means that the AAA code > needs to be > modified on the servers. I'm not convinced this is the right path. I do not see the issue: there will be a new application for this service and the AAA servers will process the messages in the same way they have been specified to behave in the Diameter Mobile IPv4 application and in the AAA Registration keys drafts. > It might be better to just make the AAA servers an explicit PKI with > cross-certificates etc. AAA server acting as a PKI is another possibility but in such case, the AAA servers need more functionnalities: they do not only need to act as Certicate Authority but msut also maintain all other PKI services such as Key Revocation, Key history, etc. which is heavier. The method described in the http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-01.txt draft, when used with the AAA infrastrucure allows an authenticated key distribution mechanism without the need of signatures which are usually considered heavy from a computational point of view. > Also, it wasn't clear from the draft how the AAA does the > authorization > of an address. > Imagine I (NAI=erik.nordmark@sun.com) appear at some random ISP > and get authenticated. > The ISP assigned me a CoA (e.g. using RC 2462 stateless addrconf) > and I communicate with the AAA. > Is the assumption that my AAAh has a pre-configured list > mapping NAI->home > address for all nodes in sun.com? > What if my home network renumbers (mipv6 allows for this) - > how does this > mapping get updated? > What if my MN wants to use a RFC 3041 home address - how does > the mapping > in my home AAA get updated? I don't get the point. How is it relevant ? But to answer your question, a pre-configured list mapping NAI->home address for all nodes in sun.com could be maintained; or dynamic home agent assignement could be performed. > > > PS: I agree with you that there is currently no concrete > > proposal for the "other" BU Authorization mechanisms that I > > am talking about. But by adopting this "1 bit method" (or > > 2 bits as described in your mail), I fear there might be no > > room for selecting these mechanisms later on. > > I just think that they need to be selected using other means, > but since I > clueless enough to not understand the big picture for > infracstrcuture-based > BU authorization I can't speculate on how. > > > But a larger question which nobody has asked is whether the > better CGA defense > against future attacks and less frequent HoA RR checks warrant the > additional complexity of CGA. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:11:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15909 for ; Mon, 11 Feb 2002 15:11:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08575; Mon, 11 Feb 2002 13:11:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15849; Mon, 11 Feb 2002 12:11:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKAhFh003817 for ; Mon, 11 Feb 2002 12:10:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKAhaa003816 for mobile-ip-dist; Mon, 11 Feb 2002 12:10:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKAeFh003809 for ; Mon, 11 Feb 2002 12:10:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00341 for ; Mon, 11 Feb 2002 12:10:43 -0800 (PST) From: Franck.Le@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19428 for ; Mon, 11 Feb 2002 12:10:42 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BKAtQ03757 for ; Mon, 11 Feb 2002 14:10:55 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 14:10:40 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 14:10:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Mon, 11 Feb 2002 14:10:29 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8119AD20E@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGzGDkdcp2sQah3S3Cm6pCNJc5ziQAH0wHw To: , Cc: , X-OriginalArrivalTime: 11 Feb 2002 20:10:30.0295 (UTC) FILETIME=[275BC270:01C1B338] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1BKAfFh003810 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > (*) RR + CGA is more secure since the AAA servers > will not know the keys. If you use the AAA servers just to authenticate the Diffie Hellman values, the AAA servers will not have knowledge of the keys neither; so I don't think RR+CGA is more secure. In addition, using AAA servers for key distribution avoids the use of signatures. Franck From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:26:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16247 for ; Mon, 11 Feb 2002 15:26:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08994; Mon, 11 Feb 2002 13:25:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18800; Mon, 11 Feb 2002 12:25:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKOVFh004079 for ; Mon, 11 Feb 2002 12:24:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKOVNf004078 for mobile-ip-dist; Mon, 11 Feb 2002 12:24:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKOSFh004071 for ; Mon, 11 Feb 2002 12:24:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14261; Mon, 11 Feb 2002 12:24:30 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24167; Mon, 11 Feb 2002 12:24:30 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1BKOTh17195; Mon, 11 Feb 2002 12:24:29 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW15884; Mon, 11 Feb 2002 12:24:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26517; Mon, 11 Feb 2002 12:24:29 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15464.10364.920431.762488@thomasm-u1.cisco.com> Date: Mon, 11 Feb 2002 12:24:28 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Francis Dupont , Erik Nordmark , Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: References: <200202111732.g1BHWsg99079@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > Just using ESP with manual keys means that IPsec can't provide replay > protection but a simple sequence number in the HRs (or a cookie exchange - but > that adds a round-trip) would handle the replay protection for HRs. This _could_ be provided by the MIP protocol itself. Indeed, if you don't use IPsec and do something specific to MIP, you'll have to provide replay protection anyway. If you simply require the replay protection provisions for app-level security when you use manually keyed IPsec, you'd have equivalent security. That said, its arguable that manually keyed ESP should have some sort of replay protection scheme too since this is a common criticism of IPsec (eg, wanting the base protections, not wanting to require IKE too). This would be IPsec wg's baliwick though. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:28:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16319 for ; Mon, 11 Feb 2002 15:28:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16077; Mon, 11 Feb 2002 13:27:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19412; Mon, 11 Feb 2002 12:27:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKR5Fh004122 for ; Mon, 11 Feb 2002 12:27:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKR57P004121 for mobile-ip-dist; Mon, 11 Feb 2002 12:27:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKR1Fh004114 for ; Mon, 11 Feb 2002 12:27:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19182 for ; Mon, 11 Feb 2002 12:27:04 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23570 for ; Mon, 11 Feb 2002 12:27:02 -0800 (PST) Received: from jariws1 ([62.248.153.155]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020211202620.SNPD6990.fep07-app.kolumbus.fi@jariws1>; Mon, 11 Feb 2002 22:26:20 +0200 Message-ID: <008d01c1b33a$78ef2c60$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , , Cc: References: <57A26D272F67A743952F6B4371B8F8119AD20E@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Mon, 11 Feb 2002 22:27:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > (*) RR + CGA is more secure since the AAA servers > > will not know the keys. > > If you use the AAA servers just to authenticate the Diffie Hellman values, the AAA servers will not have > knowledge of the keys neither; so I don't think RR+CGA is more secure. > > In addition, using AAA servers for key distribution avoids the use of signatures. I think the original point about 'more secure' wasn't quite correctly formulated. The point about CGA is that it is more secure because it proves address and key relationship, and does so without any sort of configuration or trust that could go wrong. The point about using AAA for key distribution is a correct one: this probably does avoid the use of signatures. However, we can't use AAA in isolation, it always needs to be complemented with the Authentication part --- and that may involve different kinds of cryptographic operations. True, those don't necessarily have to be based on signatures. But there has to be something. And it has to be done to the *CN* also, and this might not have been necessary otherwise. I'm very much in favor of the AAA schemes for building infrastructure to allow access or authenticate a particular service. However, I'm concerned that its application for MIPv6 Route Optimization would create a situation where an extremely large global infrastructure would have to be built. Much larger than would be necessary to e.g. just authenticate everyone on a cellular terminal - and even that is big enough. More seriously, everyone outside this global infrastructure would not get the same kind of service as the ones inside. For instance, my home web server might not be able to offer Route Optimization while the operator owned commercial service could. I think this would be bad for MIPv6, and bad for Internet in general if we could have avoided it. Finally, as Erik pointed out all of the infrastructure-based methods have serious trouble with dynamically changing things such as RFC 3041. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:32:07 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16406 for ; Mon, 11 Feb 2002 15:32:06 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11938; Mon, 11 Feb 2002 13:31:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20659; Mon, 11 Feb 2002 12:31:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKV3Fh004231 for ; Mon, 11 Feb 2002 12:31:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKV3iH004230 for mobile-ip-dist; Mon, 11 Feb 2002 12:31:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKUwFh004220 for ; Mon, 11 Feb 2002 12:30:59 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BKUkM02082; Mon, 11 Feb 2002 21:30:50 +0100 (MET) Date: Mon, 11 Feb 2002 21:26:35 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, Francis Dupont , Erik Nordmark , Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <15464.10364.920431.762488@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Just using ESP with manual keys means that IPsec can't provide replay > > protection but a simple sequence number in the HRs (or a cookie exchange > - but > > that adds a round-trip) would handle the replay protection for HRs. > > This _could_ be provided by the MIP protocol itself. Correct. That was what the reference to "a simple sequence number in the home registrations" tried to say. Erik > Indeed, if you don't use IPsec and do something > specific to MIP, you'll have to provide replay > protection anyway. If you simply require the > replay protection provisions for app-level > security when you use manually keyed IPsec, > you'd have equivalent security. > > That said, its arguable that manually keyed ESP > should have some sort of replay protection > scheme too since this is a common criticism of > IPsec (eg, wanting the base protections, not > wanting to require IKE too). This would be > IPsec wg's baliwick though. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:37:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16528 for ; Mon, 11 Feb 2002 15:37:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02040; Mon, 11 Feb 2002 13:37:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22117; Mon, 11 Feb 2002 12:37:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKZUFh004304 for ; Mon, 11 Feb 2002 12:35:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKZUCP004303 for mobile-ip-dist; Mon, 11 Feb 2002 12:35:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKZRFh004296 for ; Mon, 11 Feb 2002 12:35:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21638 for ; Mon, 11 Feb 2002 12:35:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28246 for ; Mon, 11 Feb 2002 12:35:28 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA13025; Mon, 11 Feb 2002 12:35:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1BKZRS23202; Mon, 11 Feb 2002 12:35:27 -0800 X-mProtect:  Mon, 11 Feb 2002 12:35:27 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXhlluF; Mon, 11 Feb 2002 12:35:25 PST Message-ID: <3C682B0D.6803D9FF@iprg.nokia.com> Date: Mon, 11 Feb 2002 12:35:25 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >> What is a "HR"? >> >> => Home Registrations. > > I don't know exactly what is desirable for HR. > An "easy" approach would just be to use IKE + ESP for those, but that > means that MNs need to implement IKE. > Just using ESP with manual keys means that IPsec can't provide replay > protection but a simple sequence number in the HRs (or a cookie exchange - but > that adds a round-trip) would handle the replay protection for HRs. To my understanding, we don't have to solve the problem of establishing security associations between home agent and mobile node. We never were given that problem, and I hope it doesn't become an issue before we go to Proposed. It will be hard enough to solve the problems we have to solve already. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:41:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16635 for ; Mon, 11 Feb 2002 15:41:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03991; Mon, 11 Feb 2002 13:41:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23525; Mon, 11 Feb 2002 12:41:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKeBFh004416 for ; Mon, 11 Feb 2002 12:40:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKeARc004415 for mobile-ip-dist; Mon, 11 Feb 2002 12:40:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKe6Fh004406 for ; Mon, 11 Feb 2002 12:40:07 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BKe3M02671; Mon, 11 Feb 2002 21:40:04 +0100 (MET) Date: Mon, 11 Feb 2002 21:35:52 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15456.2942.530001.275674@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik Nordmark writes: > > > So, what I don't see here is any specific > > > recommendation about HA/MN security. I guess that > > > what the following is recommending is that it use > > > strong authentication (and not CGA), but it's > > > still not entirely what the specific proposal is. > > > > Where you looking for something more specific in recommendation #5? > > There wasn't consensus on the "eg" part > below. To be useful, I think the DT needs to > actually recommend something here. This is the > single security thing that an operating network > mipv6 MUST implement and use. Mind you, I'm > happy with the example. Mike, I just realized I never responded to the above. I agree that we need to come to consensus on the HA/MN part of security. The design team was instructed by the chairs to work on 4 things and we've focused on those. Once those can be nailed down it is easier to talk about the HA/MN part due to the dependencies between different pieces. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:48:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16740 for ; Mon, 11 Feb 2002 15:48:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19541; Mon, 11 Feb 2002 13:47:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25035; Mon, 11 Feb 2002 12:47:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKkkFh004484 for ; Mon, 11 Feb 2002 12:46:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKkjjA004483 for mobile-ip-dist; Mon, 11 Feb 2002 12:46:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKkfFh004476 for ; Mon, 11 Feb 2002 12:46:42 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BKkUM03086; Mon, 11 Feb 2002 21:46:31 +0100 (MET) Date: Mon, 11 Feb 2002 21:42:19 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C682B0D.6803D9FF@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > To my understanding, we don't have to solve the problem of establishing > security associations between home agent and mobile node. We never were > given that problem, and I hope it doesn't become an issue before we go > to Proposed. It will be hard enough to solve the problems we have to > solve already. Well, I think IETF specifications should allow for independently developped interoperable implementations. To do this it seems like the mechanism used to secure binding updates between MNs and HAs need to be specified. But perhaps your use of the term "security association" is a more abstract notion of establishing the trust relationship between MN and HA (e.g. at subscription time) whereas I'm thinking of a "security association" as the actual keying material, IVs, and algorithms used to secure the traffic. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 15:50:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16818 for ; Mon, 11 Feb 2002 15:50:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20701; Mon, 11 Feb 2002 13:50:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25520; Mon, 11 Feb 2002 12:50:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKnVFh004519 for ; Mon, 11 Feb 2002 12:49:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKnVT5004516 for mobile-ip-dist; Mon, 11 Feb 2002 12:49:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKnRFh004505 for ; Mon, 11 Feb 2002 12:49:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25348 for ; Mon, 11 Feb 2002 12:49:29 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07444 for ; Mon, 11 Feb 2002 13:49:29 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1BKnSt08869; Mon, 11 Feb 2002 12:49:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW16496; Mon, 11 Feb 2002 12:48:58 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26521; Mon, 11 Feb 2002 12:49:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15464.11862.657810.67822@thomasm-u1.cisco.com> Date: Mon, 11 Feb 2002 12:49:26 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Michael Thomas , Francis Dupont , Erik Nordmark , Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: References: <15464.10364.920431.762488@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > > Just using ESP with manual keys means that IPsec can't provide replay > > > protection but a simple sequence number in the HRs (or a cookie exchange > > - but > > > that adds a round-trip) would handle the replay protection for HRs. > > > > This _could_ be provided by the MIP protocol itself. > > Correct. That was what the reference to "a simple sequence number in the > home registrations" tried to say. OK. If it's not obvious, I've been having a hard time keeping up with the list lately :-) Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 16:00:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17022 for ; Mon, 11 Feb 2002 16:00:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25400; Mon, 11 Feb 2002 14:00:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22391; Mon, 11 Feb 2002 13:00:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKwZFh004642 for ; Mon, 11 Feb 2002 12:58:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BKwZNK004641 for mobile-ip-dist; Mon, 11 Feb 2002 12:58:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BKwVFh004622 for ; Mon, 11 Feb 2002 12:58:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27736 for ; Mon, 11 Feb 2002 12:58:33 -0800 (PST) From: Franck.Le@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08811 for ; Mon, 11 Feb 2002 13:58:33 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BL0OQ06161 for ; Mon, 11 Feb 2002 15:00:24 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 11 Feb 2002 14:58:31 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 14:58:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Mon, 11 Feb 2002 14:58:31 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F8118761E5@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGzOp7EUmW21t1PT8K0NxxeJH8G4QAAwDdg To: , Cc: X-OriginalArrivalTime: 11 Feb 2002 20:58:31.0301 (UTC) FILETIME=[DC926350:01C1B33E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1BKwVFh004625 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello Jari, Thank you for the clarification: Seen the previous comments, I was thinking that the knowledge of the value of the keys was the issue. As for your other comment, I agree with your concerns. But I just wanted to say that there could be other mechanisms than RR, and CGA. We need to have solutions that do not require any infrastructure (such as RR and CGA) but if the network has a AAA infrastructure deployed, it could also take advantage of it to perform authenticated key distribution. Franck > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 11 February, 2002 2:27 PM > To: Le Franck (NRC/Dallas); mobile-ip@sunroof.eng.sun.com; > vijayd@iprg.nokia.com > Cc: Patil Basavaraj (NET/Dallas) > Subject: Re: [mobile-ip] BU Authorization method: design team > recommendation > > > > > (*) RR + CGA is more secure since the AAA servers > > > will not know the keys. > > > > If you use the AAA servers just to authenticate the Diffie > Hellman values, the AAA servers will not have > > knowledge of the keys neither; so I don't think RR+CGA is > more secure. > > > > In addition, using AAA servers for key distribution avoids > the use of signatures. > > I think the original point about 'more secure' wasn't quite correctly > formulated. The point about CGA is that it is more secure because > it proves address and key relationship, and does so without > any sort of > configuration or trust that could go wrong. > > The point about using AAA for key distribution is a correct one: > this probably does avoid the use of signatures. However, we can't > use AAA in isolation, it always needs to be complemented with > the Authentication part --- and that may involve different kinds of > cryptographic operations. True, those don't necessarily have to > be based on signatures. But there has to be something. And it > has to be done to the *CN* also, and this might not have been > necessary otherwise. > > I'm very much in favor of the AAA schemes for building infrastructure > to allow access or authenticate a particular service. However, I'm > concerned that its application for MIPv6 Route Optimization would > create a situation where an extremely large global > infrastructure would > have to be built. Much larger than would be necessary to e.g. just > authenticate everyone on a cellular terminal - and even that is big > enough. More seriously, everyone outside this global infrastructure > would not get the same kind of service as the ones inside. > For instance, > my home web server might not be able to offer Route Optimization > while the operator owned commercial service could. I think this would > be bad for MIPv6, and bad for Internet in general if we could have > avoided it. Finally, as Erik pointed out all of the > infrastructure-based > methods have serious trouble with dynamically changing things such > as RFC 3041. > > Jari > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 16:38:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18139 for ; Mon, 11 Feb 2002 16:38:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01885; Mon, 11 Feb 2002 14:37:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26726; Mon, 11 Feb 2002 13:37:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BLaiFh005110 for ; Mon, 11 Feb 2002 13:36:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BLaik5005109 for mobile-ip-dist; Mon, 11 Feb 2002 13:36:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BLaeFh005102 for ; Mon, 11 Feb 2002 13:36:40 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1BLaYM06939 for ; Mon, 11 Feb 2002 22:36:35 +0100 (MET) Date: Mon, 11 Feb 2002 22:32:24 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Routing headers - part 2 To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The MIPv6 security design team is trying to resolve the issues around routing headers as used by MIPv6. Now we've come to the part about what the packet format should be. This note specifies the design teams' motivation and current position. In order to move forward in an efficient manner it would be beneficial if responses could make it clear whether it is - a clarification (by putting CLARIFICATION: in the subject field), - an issue with a particular point (by putting ISSUE: in the subject field), - disagreement with the conclusion (by putting CONCLUSION: in the subject field) INTRODUCTION ============ The co-chairs have stated that there is consensus to switch from using Routing Header type 0 to some other "packet format" that is less likely to cause confusion e.g. in firewalls with RH type 0. The purpose of changing it from RH type 0 is to make mobile-ip less vulnerable to the attacks described in draft-savola-ipv6-rh-ha-security-01.txt by making it possible for firewalls to tell the difference between MIPv6 and general source routing, and making it less likely to cause confusion. The basis for comparing these alternatives does not take into account issues relating to Mobile Routers or Mobile Networks because it isn't clear what the architecture will be for such things, to what extent they will use route optimization, and how such optimizations would be effected by the choices made for Mobile IPv6. The evaluation of the proposals takes into account short term issues like the ease at which existing implementations can be modified but also tries to look at longer term issues like the architecture and the complexity of the complete system. ALTERNATIVES ============ The previous email suggested 4 different ways to carry the HoA towards the mobile node: 1. Use a new destination option 2. Use a new routing header type 3. Use IPv6_NO_SRC from draft-deering-ipv6-encap-addr-deletion-00.txt 4. Use a new extension header type New destination option ---------------------- The idea is that a new destination option, perhaps named Alternate Destination Address, would be defined. That option would contain the IPv6 HoA for packets destined towards a mobile. The specification would need to ensure that processing the HAO doesn't cause the destination address field to be rewritten and later the packet be forwarded out of the node. The size of the option would be 18 bytes including type and length and the size of the destination options header containing such an option would be 24 bytes. The destination options header would appear before any ESP or AH headers but after any routing headers. The effect of processing it would be that the IPsec SA lookup gets done on the Home Address. The specification would need to state exactly what values are in what fields when AH and ESP is run on the sender and receiver (which is the same issue as with the HAO today). If both a HAO and an ADA needs to be sent (for communication between two MNs) it makes sense to require that both be present in the same Destination Options header. There does not seem to be any benefit of constraining the order of the HAO and ADA in that extension header. Pros: 1. For route optimized packets between two MNs the senders and receivers HoA would be contained in the same destinations options header - as a HAO and a ADA option respectively. This might make it easier to implement. 2. No dependency on another WG. Cons: 1. This would not interoperate with existing MIPv6 implementations. Depending on setting of the high-order bits in the option type an ICMP error could me made to appear at the sender which will aid in diagnosing when talking to an old implementation. 2. Path MTU - an implementation needs to be aware of the local issue when the IP layer adds stuff to the packet without the transport layer being aware of it. Making the transport layer aware solves this. Neutral: 1. An CN implementation needs to add a different bag of bits when it finds a BCE for the destination, but this is a fixed bit pattern followed by the HoA so it shouldn't be hard. 2. IPsec interaction the same as for HAO. 3. The ADA option does not nest e.g. when there are nested route optimizations. But the HAO does not nest either. Unknown: 1. The option is not removable before the packet reached the endpoint. While this seems to be potentially useful for Mobile Routers/Networks there isn't enough understanding of nested route optimization in the Monet space to make any determination. 2. A MN sending presumably needs to do the "should I add HAO" and "should I add ADA" close to each other in the code so that it can determine the size of the necessary Destinations options header. This might effect the implementations. Today implementations can decide whether a RH needs to be added separately from deciding whether a HAO needs to be added, even if the total size needs to be taken into account for PMTU adjustments. Summary: Well-understood and relatively small change. New routing header type ----------------------- The idea is to define Routing Header type 1 to be a constrained routing header than can only contain exactly one IP address. Nodes that receive packets with such a RH MUST NOT forward the packet outside the node as a result of processing the RH. And nodes receiving the RH MUST verify that the address on the RH is the Home Address (or one of potentially multiple Home Addresses) assigned to the node. When both a RH type 0 and a RH type 1 header is present in the packet the type 0 header must be before the type 1 header. The intent is that firewalls that block Routing Header type 0 due to perceived security issues not block Routing Header type 1 due to its much more constrained specification. Pros: 1. Small and easy change to MIPv6 implementations. 2. No dependency on another WG. Cons: 1. A sender implementing RH type 1 can't interoperate with a MIPv6 receiver using the current RH type 0. The packets will be dropped and ICMP parameter problem message will be sent packet which helps diagnose such a problem. 2. Path MTU - an implementation needs to be aware of the local issue when the IP layer adds stuff to the packet without the transport layer being aware of it. Making the transport layer aware solves this. Neutral: 1. Does "nest" i.e. can be applied recursively. But the HAO does not nest hence there doesn't seem to be any benefit. Unknowns: 1. There might be some concern that the "be conservative what you accept" firewall default configurations and/or firewall administrators will fail to understand that RH type 0 and RH type 1 are conceptually different things. Hence all RH independent of type might get tossed. 2. The assumption is that the IPv6 WG will not object to defining a new routing header type with the above semantics. Summary: Well-understood and minimal change to implementations. Predicting the behavior of firewall implementors and administrators is very hard. Use IPv6_NO_SRC --------------- The idea is to specify that instead of RH the IPv6_NO_SRC Deering/Zill tunneling header specified in draft-deering-ipv6-encap-addr-deletion-00.txt should be used. There might not be any benefit to do this unless HAO is also replaced by IPv6_NO_DST tunneling and that the case of traffic between two MNs (where logically 4 addresses need to be in the packets) is handled using IPv6-in-IPv6 tunneling (RFC 2473). Thus the IPv6_NO_SRC and IPv6_NO_DST can conceptually be viewed as an optimization saying 16 bytes in the packets when only 3 IP addresses need to be communicated. Pros: 1. Fits well with existing practise for tunneling e.g. between HA and MN as well as IPsec tunneling. But the benefit of this are probably limited unless HAO is also replaced by IPv6_NO_DST tunneling. Thus the total complexity might be the smallest (least amount of code) if this is used instead of RH and HAO. 2. Nests i.e. can be applied recursively for both source and destination, but it isn't known if nesting will ever be needed or required. Cons: 1. A sender implementing this can't interoperate with a MIPv6 receiver using the current RH type 0. The packets will be dropped and ICMP payload type unknown messages will be sent packet which helps diagnose such a problem. Neutral: 1. Path MTU - an implementation needs to be aware of the local issue when the IP layer does tunneling. But current IP-in-IP tunneling software (e.g. for MIPv4 and IPsec) already handle this. Unknowns: 1. Adds a dependency on the IPv6 WG finishing and advancing the specification of IPv6_NO_SRC in a timely manner. If the MobileIP WG thinks this is critical presumably this can help speed up the process. 2. Exact IPsec interaction needs to be specified. (There were some open issues on this discussed in IPv6 WG in SLC.) 3. Implementations often do tunneling as a pseudo-device driver, in which case there are some unknowns in terms of the effect on the structure of an implementation. While the transmission of these headers based on BCE entries can be done without any relationship with existing tunneling code in an implementation, encapsulated packets that are received are likely to end up in such a tunneling device driver piece of code. (At least for MN to MN communication where the RFC 2473 would be used.) Thus any such tunneling pseudo-device driver would need to interact with the Mobile IP code in order to verify whether it is ok to decapsulate a given packet. Summary: It might very well be that this approach would lead to the least amount of code in an implementation and conceptually the cleanest. But there are unknowns in terms of the actual impact on actual implementations as well as open issues about the specification which would make this a risky approach. New extension header type ------------------------- The idea is to define a new extension header that will just contain the ADA (if the new extension header would be capable of carrying both the ADA and the HAO this proposal would be identical to using Deering/Zill tunneling.) The order between this extension header and a destination options header with a HAO need some care in an implementation. Pros: 1. Unlike IPv6_NO_SRC this could be done without a dependency on any other WG. Cons: 1. Lots Summary: All the pain and little gain - this doesn't seem to make any sense. RECOMMENDATION ============== The use of D/Z tunneling seems to be the best long-term answer. However, there are significant unknowns both in terms of finishing the specification as well as understanding the impact on implementations. Also, the potential for D/Z tunneling to be used for other purposes than MIPv6 creates some potential concerns for firewalls. The design team recommends that future work, e.g. in the area of Mobile Networks, look into D/Z tunneling (after they've decided what problems need to be solved of course). If a new destination option is chosen it seems like the "Home Address Option" would be the ideal name for such an option, but that name is already taken. Thus in this case the DT recommends that instead of definiting a new option called ADA (alternative destination address) instead the existing HAO option *code* should be renamed to SHAO (for "Source HAO") and a new option *code* be allocated for a DHAO ("Destination HAO) both using the existing HAO option *format* specified in the mipv6 draft. The tradeoff between RH type 1 and a new destination option is far from obvious. The summary of this is that a new RH type is a trivial code change but that there are some concerns in the area of firewall interaction, while a new DO causes some more code changes but can be clearly labeled as "MIPv6" i.e. should not be accidentally filtered by firewalls. The design team recommends using a new destination option instead of a new routing header type. The WG chairs would like to obtain WG views and consensus on the following two choices: Please respond with motivation for the ones you don't AGREE with: 1. New Destination Option (AGREE/DISAGREE/CAN LIVE WITH) 2. New RH Type 1 (AGREE/DISAGREE/CAN LIVE WITH) ACKNOWLEDGEMENTS ================ The MIPv6 working group and its many members have contributed to this writeup. In particular discussions with Francis Dupont, Pekka Savola, Charlie Perkins, and Jari T. Malinen have helped clarify the issues. --- From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 16:54:32 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18761 for ; Mon, 11 Feb 2002 16:54:32 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27645; Mon, 11 Feb 2002 14:54:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02610; Mon, 11 Feb 2002 13:54:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BLrFFh005178 for ; Mon, 11 Feb 2002 13:53:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BLrEHT005177 for mobile-ip-dist; Mon, 11 Feb 2002 13:53:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BLrBFh005170 for ; Mon, 11 Feb 2002 13:53:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02371 for ; Mon, 11 Feb 2002 13:53:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09517 for ; Mon, 11 Feb 2002 14:53:14 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA18400 for ; Mon, 11 Feb 2002 13:53:13 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1BLrCI05106 for ; Mon, 11 Feb 2002 13:53:12 -0800 X-mProtect:  Mon, 11 Feb 2002 13:53:12 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdllXLUC; Mon, 11 Feb 2002 13:53:05 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA78872 for ; Mon, 11 Feb 2002 13:53:05 -0800 (PST) Message-ID: <3C683D40.3E3E0CF8@iprg.nokia.com> Date: Mon, 11 Feb 2002 13:53:05 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: bidding down References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, - First, it might be good to motivate this discussion. It would be to see if an alternative method for the 1-bit method is possible. This because there are some problems with the 1-bit method mentioned by others including - the bit method locks us to one method, no much alternatives in the future nor room for replacement (even a chosen CGA method may need change, e.g. for better security or optimization, then the bit encoding needs to change again, so it may be not too good for even CGA) - the requirement for change is extensive for the bit alone, while also the CGA method itself is not standardized, requiring several yet not existing normative references to base MIPv6 and changes in RFCs. > You seem to be making the implicit assumption that a MN would always > immediately try to setup RO. > I think we want to keep the door open for MNs which e.g. perform some form > of flow detection before establishing the RO. > That seems to be problematic if the CN might have a BCE created by > an attacker using RR. The brief idea was formulated so that it looks like this but looking closer it is not exactly so. It considers issues in one particular idea of doing on-line signaling, but is here for the case of illustration on-line signaling might be possible. - There is no need to actually establish RO, just to do some signaling, to be precise, immediately after receiving the first non-RO packet with subsequent rate limiting not to do that for every non-RO packet. This could be a de-registration establishing the level of authorization and that MN wishes to do no RO, but e.g. bidir. tunneling, if desired. - Or, one could add offline tag to support this case (an extension to DNS) which gives the minimum condition for the BCE making CN garbage collect too low priority BCEs and would be much more flexible for future change than address bit encoding and would require change to 1 place beyond base MIPv6 instead of many, just to give an example of an alternative to 1-bit which is a more "offline" method. - Since it is not clear your example really is a relevant "present attack" against bidding down, (see my comment at end) one might consider what about "future attacks" (victim is not around when bidding down happens), leaving the CN-initiated traffic the relevant one to discuss. As with RR, garbage-collecting unused BCEs frequently (which would happen anyway in the case of "lower" method being RR). This limits the scope of the attack to something that could be considered insignificant enough, as one possible alternative. > > Suppose we are using a simple rule in CN which > > tags BCE telling how it was authorized and refuses > > BUs with lower-priority authorizations during the > > lifetime of a BCE but any time accepts authorizations > > of the same or higher method. Legitimate MN is never > > blocked from regaining the BCE nor can it lose it > > when it needs the BCE. When legitimate MN is not > > communicating, it should be enough for the CN > > to expire unused BCEs injected by RR attacker > > for the CN to be able to communicate with the > > legitimate MN, and/or always start its sessions > > with non RO data packet despite BCE. > > The "starts its session" seems to imply that the IP layer, when choosing > whether or not to use a RR BCE, needs to be able to identify a new session > indepedently of the transport and application protocol. > > For TCP and SCTP I can see us doing this, but what about some yet to > be invented protocol over (congestion controlled) UDP? Reliable multicast? > It seems impossible to make this distinction in general. The "start session" option should be generalized as the ability by CN to check whether a BCE was not set up by a too "low" method. It could be based on recognizing sessions (setting new flows could be one way), or also to periodically send non-RO packets and a condition that MN needs to respond to those with a BU (which can be deregistration if one does not want to start RO now or at all). This to invoke discussion looking more deeply to generic locally standardizable on-line signaling alternatives. > > When the true MN initiates the RO connection it chooses > > a higher method and no RR attacker even from CN-HA path > > can change that by RR during the lifetime of the BCE, > > since it only accepts CGA or higher. The BCE can only > > be refreshed by the higher method run by the original > > MN during the time of the BCE being needed. If the attacker > > can block those legitimate messages, it can tamper with > > forwarding and do more harm even without MIPv6. > > If the attacker is actually on the CN - HA path it can presumably cause > that attempt to establish RO with CGA security fail by dropping > the relevant packets. But this means that the CN - HA path is not essentially different securitywise for RR from RR+CGA, hence making it irrelevant whether bidding down signaling is dropped since _no_ online signaling can then really work. This actually includes the bit method. A CGA address cannot then be delivered to CN (even DNSSEC can be then disturbed amounting at least to a DoS attack against CN-initiated connections). That's why tampering with forwarding is not a very fruitful case for the analysis, you can most likely kill any bidding down mechanism or signaling that such mechanism guards when CN does not statically know the lowest method acceptable. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 17:12:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19331 for ; Mon, 11 Feb 2002 17:12:03 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29836; Mon, 11 Feb 2002 15:11:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08612; Mon, 11 Feb 2002 14:11:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BMAPFh005427 for ; Mon, 11 Feb 2002 14:10:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BMAPXD005426 for mobile-ip-dist; Mon, 11 Feb 2002 14:10:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BMAMFh005419 for ; Mon, 11 Feb 2002 14:10:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15229 for ; Mon, 11 Feb 2002 14:10:23 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05709 for ; Mon, 11 Feb 2002 14:10:23 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1BMANe00511 for ; Mon, 11 Feb 2002 14:10:23 -0800 (PST) Message-ID: <076001c1b348$adad0860$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <200202011054.g11Aslg49745@givry.rennes.enst-bretagne.fr> <3C5EF68B.4060606@piuha.net> Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Mon, 11 Feb 2002 14:08:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have read through some of the traffic on this last week while I was on vacation, but here are my opinions and some additional comments. > 3. RECOMMENDATIONS > ================== > > 1. The design team recommends a mandatory RR mechanism for > IPv6 nodes, but with limitations on how long bindings can stay > alive before they need to be refreshed. This recommendation is > based on the findings of the security analysis, which point to > some deficiences in the RR method below the "do no harm" > principle, to which the limitations provide a reasonable > answer. The RR mechanism should be placed in the MIPv6 > RFC. Given that RR may not be sufficient in all situations or > may need to be replaced later with something else, we > recommend that a secure mechanism for selecting different BU > authorization methods, using the "bit method" described in the > URL referenced from section 1, is included in this RFC as > well. > CAN TOLERATE Given the seeming urgency of the need for a decision, and the lack of clarity about CGAs, this seems like the best solution for the time being. However, RR depends on the security of the routing infrastructure, and given that it is easy for an attacker to mount an attack on the last hop and pose as a router on multi-access links, I view RR as a stopgap solution until a more general solution is available for securing IP signaling. CGAs are a possibility. One comment: in the discussion there seemed to be some confusion about the "bit method" of reserving an address class for addresses that are not secured via RR. I assume that what is meant here is exactly that, and that the bit combination to be specified will not be used to specify that CGAs must be used but some future, to-be-decided IP signaling security protocol which *might* be CGAs. Is that correct? Also, I support the idea (which came up in the discussion), of having the BU security RFC be separate from the base MIPv6 RFC. This is more modular, and will simplify introducing a more powerful IP signaling security technology like CGAs when the IETF gets around to specifying it. > 2. The design team additionally recommends an optional CGA > mechanism to be standardized in a separate RFC in the MIPv6 > WG, using the above "bit method". This recommendation is based > on the findings of the security analysis, which point to > lesser signaling requirements and improved security properties > of CGA, as well as potential for solving additional, IPv6 > problems. Due to IPR and CPU consumption concerns it seems > problematic to make CGA a mandatory requirement, however. > DISAGREE I think there needs to be some discussion on how to secure IP signaling in general. I think CGAs are one possiblity, but they have some disadvantages, including the aformentioned IPR restrictions. I would like to see a method of securing IP signaling be developed that has wide applicability (BUs, securing IPv6 ND, paging, etc.), and not something that is restricted just to MIP. Otherwise, every working group is going to have to go through the same process the MIP group went through, and will come up with their own solution. The expense and complexity of implementing one off solutions for securing every IP signaling protocol will far outweight the expense and complexity of CGAs, IHMO. Also, though the design team hasn't yet specified exactly which method will be used for securing BUs, I have a difficult time seeing RR as a widely applicable method. So I would oppose having a separate RFC at this time strictly for BU security using CGAs. That said, I do believe that a more powerful mechanism is required for securing IP signaling and I believe that when such a mechanism is developed (if it ever is), the RR spec should be obsoleted and an RFC written which describes how to use that mechanism for MIP. > 3. Regarding issue (i), the design team recommends that the RR > method should not use a BSA since we already recommend both > HoA and CoA RR tests to be performed every time a binding is > refreshed or updated with RR. AGREE, with the proviso that if an IPSEC SA already exists, it should be possible to use it. > For CGA, the design team > recommends that a (simplified) BSA can be used to store the > Diffie-Hellman value generated as a part of the initial > binding, since with CGA, only the CoA test needs to be > performed on every binding refresh. > DISAGREE I don't believe anything should be said about CGAs until a specification is complete about securing IP signaling in general. > 4. Regarding issue (ii), the design team recommends both CoA > and HoA tests to be performed every time binding is refreshed > or updated with RR. We also recommend additionally that these > tests are made using separate requests in order to avoid > reflection problems with the authorization protocol itself (a > BU authorization request sent from the CoA should not be > answered to the HoA). This essentially leads to a five message > exchange that lasts 1.5 RTTs since because two pairs of the > messages can occur in parallel: > > 1a. MN(HoA)--->HA--->CN > 1b. MN(CoA)--------->CN > 2a. CN-------->HA--->MN(HoA) > 2b. CN-------------->MN(CoA) > 3. MN(CoA)--------->CN > CLARIFICATION I can't claim to have examined this in detail, but this seems like an aweful lot of signaling potentially going over the Internet, and runs the risk of congestion control dropping the packets. What about the transport protocol? UDP is clearly at risk. UDP with some reliability mechanism? TCP? SCTP? This looks like an aweful lot of signaling, every one of these is an opportunity for something to go wrong. If either 1a or 1b is dropped, then recovery may take a long time. In any event, this is going to slow down MIP handover by orders of magnitude. A scalable LMM solution becomes even more critical. > 5. In order to guarantee security of the above exchange, the > HA-MN tunnel should be encrypted for the RR messages (but not > necessarily for other messages on this tunnel). Note that > there aren't similar scalability problems with this as there > are with MN-CN security, since the home agents and mobile > nodes must have an existing relationship anyway. This could be > done e.g. using IPsec ESP with pre-shared keys. > AGREE > 6. For CGA, the design team recommends that 1a/2a can be > omitted for all but the initial exchange and periodic tests > every few hours or perhaps once a day. > DISAGREE Again, a generalized IP signaling security protocol is better, IMHO. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 17:43:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19817 for ; Mon, 11 Feb 2002 17:43:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11564; Mon, 11 Feb 2002 14:42:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17256; Mon, 11 Feb 2002 14:42:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BMf4Fh005570 for ; Mon, 11 Feb 2002 14:41:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BMf4s2005569 for mobile-ip-dist; Mon, 11 Feb 2002 14:41:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BMf1Fh005562 for ; Mon, 11 Feb 2002 14:41:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20855 for ; Mon, 11 Feb 2002 14:41:03 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02294 for ; Mon, 11 Feb 2002 15:41:02 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id B0AAB6A907 for ; Tue, 12 Feb 2002 00:40:59 +0200 (EET) Message-ID: <3C6848BA.7040503@piuha.net> Date: Tue, 12 Feb 2002 00:42:02 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: bidding down References: <3C683D40.3E3E0CF8@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari T. Malinen wrote: > - the bit method locks us to one method, no much alternatives in the > future nor room for replacement (even a chosen CGA method may need > change, e.g. for better security or optimization, then the bit > encoding needs to change again, so it may be not too good for even CGA) It has been suggested that including the algorithm/key type/cga type in the hash that generates the CGA address would suffice to distinguish between all different types of CGA-like schemes. That is, interface id part = hash(public key + ADDRMETH_CGA_CGA1 + RSA + MD5) or similar. In addition, I believe all infrastructure-based BU authorization solutions can be made to work with the selection being done by the infrastructure, not a bit in the address. For instance, assuming you protected BUs with PKI-driven IPsec, your policy data base (possibly distributed from a central point) would dictate for which addresses you require the IPsec protection. Jari A From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 18:06:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20096 for ; Mon, 11 Feb 2002 18:06:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25327; Mon, 11 Feb 2002 16:05:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22537; Mon, 11 Feb 2002 15:05:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BN4cFh005700 for ; Mon, 11 Feb 2002 15:04:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BN4bnm005698 for mobile-ip-dist; Mon, 11 Feb 2002 15:04:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BN4XFh005689 for ; Mon, 11 Feb 2002 15:04:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26930 for ; Mon, 11 Feb 2002 15:04:34 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00880 for ; Mon, 11 Feb 2002 15:04:33 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 338796A907 for ; Tue, 12 Feb 2002 01:04:26 +0200 (EET) Message-ID: <3C684E38.9070406@piuha.net> Date: Tue, 12 Feb 2002 01:05:28 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Home Address Option: design team recommendation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The MIPv6 security design team is trying to resolve the issues around potential Denial-of-Service vulnerabilities regarding the Home Address Option. This note specifies the design team's motivation and current position. In order to move forward in an efficient manner it would be beneficial if responses could make it clear they are - a clarification (by putting CLARIFICATION: in the Subject field) - an issue with a particular point (by ISSUE:) - disagreement with the conclusion (by CONCLUSION:) We would also like folks to state for each of our three separate recommendations whether they AGREE, CAN TOLERATE, or DISAGREE with them. In case of DISAGREE, please explain why. 1. INTRODUCTION =============== The main problem with the Home Address Option (HAO) is its potential to be used as a part of Denial-of-Service attacks. More precisely, the Home Address Option helps the attacker to conceal his or hers location. 1.1. BASIC ATTACK The basic attack can be performed as follows: 1. Pick a victim host or network. 2. Pick any large set of other IPv6 nodes. There are no other requirements for the selection of these nodes beyond them having to be reachable from the Internet. 3. Send IPv6 packets with Src=attacker, Dst=reflector, HOA=victim. Here reflector is one of the chosen IPv6 nodes, possibly a different one for every sent packet. The source address can be the attacker's own address. The attack can be launched from a single host, or be performed as a distributed attack. 4. Each reflector will process the IPv6 packet and respond. The responses would typically be ICMP errors, ICMP responses, UDP responses, or answers to TCP SYNs. Typically at most a single packet is sent as as a response. (In a variation of this attack, a reflector whose TCP sequence numbers can be guessed some amplification can be achieved.) 5. Since the MIPv6 rules require CNs to use the Home Address in return traffic towards the MN, the responses are sent to the victim's address. The victim sees packets that have Src=reflector, Dst=victim, and there is no indication of the original source address. 1.2. SERIOUSNESS OF THE ATTACK The effect to the victim is that the hosts or the networks Internet connection is filled with traffic. Since a reflector is used, only replies can be sent and hence it may not be possible to cause any much more trouble than the consumption of communication resources. There is also no amplification involved. On the other hand, the attacker can pick any protocol to perform the attack, and the number of possible reflectors is not limited to some special set of nodes such as the DNS or web servers. In particular, the reflector nodes can be private PCs and equipment without e.g. easy administrative contacts, network monitoring, or logging of the used source addresses. The main problem, however, comes from our (in)ability to prevent these attacks. The two basic approaches to dealing with Denial-of-Service attacks include ingress filtering, which prevents the use of wrong addresses, and tracing schemes such as itrace that can be used in post-mortem analysis of the attack. Ingress filtering is partially deployed in today's IPv4 world, and this can be expected to continue in the IPv6 side. Tracing schemes are not yet deployed, at least not widely. Normal, stateless and filter-based ingress filtering can't deal with these attacks. This is because by definition of the HAO, its value can't be expected to be local to the network where it is being sent from. Tracing schemes as defined today can't deal with these attacks either. Regular forward itrace, for instance, would only send ICMP trace packets to the reflector on the first leg of the path, and to the victim on the second leg of the path. But the victim would not learn of the attacker's location due to the existence of the reflector in between. A reverse itrace helps trace back reflector attacks where the attacker has spoofed the source address, but in this case this would not work as the source field is not the victim. A hypothetical extension to itrace, "3-way itrace", could though be defined to send ICMP trace packets to (a) destination, (b) claimed source, and (d) claimed home address. It seems therefore that ingress filtering is not sufficient here, but a 3-way itrace might be. This is, however, just the start of the hard part: allowing attacks that bypass ingress filtering but are still caught with 3-way itrace could be considered dangerous. Ingress filtering is by nature a prevention mechanism while tracing is an analysis tool. There's also three substantial differences between them: - Ingress filtering is partially deployed while itrace is not. - Victim needs to wait more in itrace to figure out what's going on. - Most importantly, since itrace doesn't force you to use a specific IP address, it will not be possible for the victim to act quickly by e.g. installing a filter in his network or his ISP's network to block the offending IP address. Instead, the victim must wait until the ISP or the policy on the other side of the globe acts and installs a filter on their site to block the attacker's link or computers. This could be time consuming. There are other concerns around IPPT, a new technique similar to itrace and a soon to be WG in the IETF. IPPT works by hashing each individual packet so that an authorized user (e.g. the NOC or a customer calling the NOC) can ask questions about a single recent packet. The hash takes into account such things as the TCP sequence numbers, the length of the packet, etc. (but ttl is excluded since it changes in the network). This means that any "transformation" needs additional state. Example of transformations are IPv4 fragmentation by routers, encapsulation and decapsulation. The entities that perform the transformations need to be part of the IPPT system and collect this information to prevent packets from disappearing. Thus a host processing a HAO and then reflecting e.g. a TCP SYN would need to be part of the IPPT in order to be able to use IPPT to traceback through that reflector. Of course, we don't do this for normal reflectors but they are more predicable since they don't loose the IP source address. In conclusion, the crux of the matter is the impact on ingress filtering. The design team would be hesitant to "bid down" our ingress filtering protection and settle for itrace, even if trace was deployed now. It also seems unlikely that HAO support can be built for other methods such as IPPT. The design team recognizes that ingress filtering is not fully deployed and probably never will be. Still, we feel that the possibility to use ingress filtering in an effective manner should be retained even in IPv6 networks. 1.3. PRACTICAL EFFECT The practical effect of the introduction of the HAO to the Internet is that attackers can launch DoS attacks where the victims have no practical ways to quickly disable the attack. Even tracing of the attacker becomes hard; the tracing is possible but can be slow and would require widespread introduction of a technology which is just in its development phase. Existing and future ingress filtering tools are rendered largely useless, at least as far as protocol responses are considered. Compared to some other existing DoS attacks, the HAO reflection attack compares as follows: - This is a smaller problem than publicly open IP-in-IP tunneling, since through HAO we can only run responses. - This is a bigger problem than regular source address spoofing attacks, because they can be prevented with ingress filtering (and are also detectable with current itrace mechanisms). 1.4. FURTHER BACKGROUND INFORMATION Further background information on the security issues around MIPv6's use of the Home Address Option can be found from draft-savola-ipv6-rh-ha-security-01.txt, draft-dupont-ipv6- ingress-filtering-00.txt, as well as in the mailing list discussions. Reflection attacks in general are treated extensively in http://www.aciri.org/vern/papers/reflectors.CCR.01 2. ALTERNATIVES =============== The alternative decisions we can arrive at are the following: (a) Decide that the threat is not significant. (b) Apply infrastructure-based ingress filtering (c) Apply infrastructure-less ingress filtering (d) Allow HAOs only in conjunction of existing bindings (or IPsec SAs) (e) Additional information copied to the reflected packet 2.1. THREAT IS NOT SIGNIFICANT While the exact nature and seriousness of the threat may be discussed, it seems that the "do no harm" principle is not fulfilled. This is because the threat appears harder than the one caused by regular source address spoofing. 2.2. INFRASTRUCTURE-BASED INGRESS FILTERING Intermediate routers and firewalls could be made more intelligent in order to still be able to continue to perform the ingress filtering task. The question is how? In infrastructure-based ingress filtering this is done this with the help of a global infrastructure such as AAA. Upon requesting access from a challenging router, a node authenticates itself, the router uses the global infrastructure to get the node's home organization to verify the authentication. In doing so, the home network supplies also a correct Home Address to the visited network. This information is used to open a "hole" to the ingress filtering system at the visited network. It may not be obvious why a global infrastructure is needed, and to what extent. First, the global infrastructure is needed in order for the authentication of the MN to be verified. Otherwise, anybody could claim to be the rightful owner of some legitimate Home Address somewhere else. Second, both the visited and the home domains must be under the same infrastructure. This implies a SOHO user could not get access when he is visiting a big ISP, unless the SOHO user was also a member of the roaming association of the ISPs. Obviously, the SOHO user could be served by an ISP and perhaps the ISP authentication procedures could be applied here. It turns out that this isn't always possible. For instance, DSL providers may rely on authentication procedures which require nodes to be reachable at given fixed locations in their topology. This would preclude authentication of any node or user away from its usual location. Providers may also have no authentication at all. With the advent of grass roots, self-organizing or impromptu networking (typically using wireless LAN technology to produce a patchwork of network connectivity), many users will not be serviced by traditional ISP's. These users would not be able to use such an infrastructure-based ingress filtering. As a result, only a subset of all users in the world would be able to use this improved ingress filtering. What would be done with the others? It seems that where ingress filtering is deployed, it would be necessary to prevent the use of MIPv6 altogether for users who do not belong to the infrastructure. This is because it may not be possible to differentiate between the dangerous use of HAO and its safe use in conjunction with Route Optimization (see 2.4). Ingress filtering should also be as deployable as it is IPv4, which means multiple places as well as higher up in the hierarchy than a single Access Router or local firewall. This sets additional requirements on the challenging router can authentication the user; it may not be under the same administration as the Access Router that gave access to the MN. The main benefit of this scheme is the level of control it allows. The drawbacks include the introduction of a large global infrastructure, the elimination of certain user groups from being able to benefit from MIPv6, and the inability of the global infrastructure to deal with e.g. RFC 3041 addresses. 2.3. INFRASTRUCTURE-LESS INGRESS FILTERING A better way would be to come up with an ingress filtering scheme that does not require a global infrastructure. We note that such schemes appear to have to be based on similar principles as the Route Optimization is based on. This is because the infrastructure and the RR/CGA methods are the only known ways to have some assurance of address ownership. While rate limitation and other mechanisms can reduce the problems associated with HAO reflection, they don't appear to be able to solve them altogether. The hard problems in rate limiting are determining what is reasonable rate a the location of the limiter, and the attacker's ability to use a large number of different reflectors. Without going to the detailed signaling involved in the use of RR or CGA to prove address ownership to a challenging router, the basic scheme is as follows: 1. Send a message to the CN 2. The message is intercepted by the challenging router, and an authentication request is sent to the MN 3. MN uses an RR or CGA method to prove ownership to the AR, just as if challenging router was a CN 4. A filter is installed in the challenging router so that packets from the MN can not get past that router. 5. The MN retransmits the packet that the challenging router dropped in Step 2. Benefits of this scheme include keeping the current ingress filtering model but extending it to do more. Theoretically, this scheme would also allow the elimination of the HAO from packets altogether (by simply using the HoA as the source, and expecting routers to challenge this if necessary), which would reduce the size of the packets in MIPv6. The drawback of this scheme include the following. - Deployment: it expects increased network support, which may delay introduction of MIPv6. - Scaling: Instead of having a single ingress filter rule per prefix, the routers need to have per MN information to track which HAO each MN can use. New DoS attacks are opened against the routers because of this. - Delay: There is delay due to the router's challenge. Multiple challenging routers in the path create additional delay. There might also be potential DoS issues around bogus challenges injected by random off-path nodes - the MN has no idea what nodes are routers on the path. - Architectural: Should we select end-to-end or network centric approaches? Generally the network centric approaches do not scale as well as end-to-end mechanisms, and may be deployed slower. 2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS If all CNs ensure first the validity of the Home Address claim using e.g. RR techniques, HAOs can be accepted. The result of this is that in order to send packets directly from a MN to a CN the CN needs to have state about the MN. Thus in effect the choices are either RO (packets in both direction take the direct path between MN and CN) and bidirectional tunneling (packets in both directions go through the HA). Thus it would not be possible, without creating some authenticated state on the CN, to send packets directly from the MN to the CN. The benefit of this scheme is its zero need for network support, and its end-to-end nature. The main drawbacks are the elimination of triangular routing, and the change in the nature of the BCE state (discussed below in 2.4.1). A variation of this approach is that HAOs could additionally be accepted also if there's an IPsec SA between the MN and the CN. (In this case, however, the SA must be established using traditional means such as local PKIs and newer research results on self-signed certificates or opportunistic IPsec would not suffice here.) 2.4.1. NATURE OF BCE STATE The nature of the BCE changes a bit if alternative 2.4 is adopted. An expired BCE changes more than the routing of the packets. In the current MIPv6 specifications, the expiration forces the return packets to take the route via the HA. But if alternative 2.4 is adopted, an expired BCE causes any traffic with a HAO to be dropped upon reception, causing packets to be blackholed until the MN notices this condition. A few observations of the effects can be made: - The traffic does not get dropped if the MN and CN have the same understanding of the length of the expiration period. - A CN that has to throw away BCE entries due to lack of memory or some other reason might cause this. Perhaps one could argue, though, that it would make more sense to allocate a fixed size memory pool for Route Optimization, making it possible for the CN to guarantee a BCE entry lifetime and refuse new RO requests. However, this would limit the ability of the CN to dynamically decide that a new BCE entry is more important than an existing one, and to throw away the existing before it has expired. - However, a CN that reboots can still cause this. The effect is significant naturally only if the CN can get back to operational status soon enough to even be able to drop packets. (Note that RR protected BUs are expected to have lifetimes of at most few minutes, which limits the duration of the resulting condition.) In conclusion it is necessary to deal with the situation in some manner. There are different ways of dealing with this but the design team proposes the following scheme. A HAO with no matching BCE entry generates an ICMP error message. The message is sent to the source of the packet, i.e. the CoA. This guarantees that there will be no additional reflection problems because of this. It may be possible for attackers to spoof these messages from the path, or possibly also off-path (it isn't clear that implementations are expected or even can check for TCP sequence numbers inside the ICMP packet). This would have the effect of forcing an unnecessary new RR exchange, or possibly disabling RO altogether. Like all ICMP spoofing this requires that the attackers can lie about their source addresses. However, this attack does not appear to be any more severe than MIPv6 offers in any case for RO. For instance, an a spoofed ICMP Destination Unreachable would cause a CN to revert back to using the HA path. 2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS In this alternative, a traceback of the attacker is performed by having the CN include additional information in the reflected packets. In particular, the CN could include the claimed source address of the original packet in the response, e.g. in the "OAH Destination Option". This approach is an easy one to provide within the MIPv6 specifications. A disadvantage is that it helps mainly for traceback, and does not help as much prevention -- for instance the victim's ISP could not filter the attacker's packets using IP source address, but would have to look at the option. (Prevention may still be possible, but could require additional functionality in e.g. routers and filtering firewalls.) A larger drawback of this scheme is that there are IPv6 socket API implications, at least for UDP applications, in order to ensure that the response sent due to a request containing a HAO always contains a OAH option. 3. DISCUSSION ============= The design team feels that the a great danger for MIPv6 deployment is that it is perceived as insecure. This is particularly true after the widely known events that have taken place in the IETF for MIPv6 since December 2000. Any special conditions regarding what service providers need to get in order to allow MIPv6 securely in their networks is likely going to reduce the number of MIPv6 users. Therefore, we feel that potential dangers in HAO should be considered. The design team does not feel IFB solutions are acceptable as a condition for MIPv6's use. MIPv6 will have the largest user base if it doesn't require additional infrastructure in the visited locations or in the home networks. We'd also like the Internet to use end-to-end mechanisms rather than network assistance, especially if there are scalability concerns in the kind of assistance required. The end-to-end principle isn't just an architectural rule, it will also ensure that we can deploy our things without waiting for providers to catch up. 4. RECOMMENDATION ================= The design team notes that the resolution to this seemingly small issue has major ramifications to the MIPv6 architecture. It affects the topology of the routes the packets take; it has a node vs. router functionality decision; it has an IFB vs. IFL decision. The design team recommends alternative d to be applied (R1). We expect MIPv6 deployment to be soonest and largest if we choose d. The design team recognizes that moving non-RO traffic to bidirectional tunneling has consequences. We do not believe the technical consequences to delays etc. are significant. It may be in fact be a cleaner approach to have a 2-level solution and the RO deployment may grow because of this. However, there are non-technical consequences. In particular, the MIPv4 experience indicates that pure bidirectional tunneling may result in leaving the Route Optimization functionality behind in the standardization process, and become less widely if at all implemented. Due to these considerations, the design team additionally recommends that (R2) MIPv6 bidir and RO parts be kept in the same RFC and advanced at the same time, and (R3) RO should be required to implement in all IPv6 nodes, as implied by RFC 1726. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 18:06:41 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20118 for ; Mon, 11 Feb 2002 18:06:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16215; Mon, 11 Feb 2002 15:06:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22544; Mon, 11 Feb 2002 15:05:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BN4bFh005697 for ; Mon, 11 Feb 2002 15:04:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1BN4aeJ005696 for mobile-ip-dist; Mon, 11 Feb 2002 15:04:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1BN4VFh005682 for ; Mon, 11 Feb 2002 15:04:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25247 for ; Mon, 11 Feb 2002 15:04:33 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00699 for ; Mon, 11 Feb 2002 16:04:32 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1BN4We02903 for ; Mon, 11 Feb 2002 15:04:32 -0800 (PST) Message-ID: <07e401c1b350$3e291580$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <3C683D40.3E3E0CF8@iprg.nokia.com> <3C6848BA.7040503@piuha.net> Subject: Re: [mobile-ip] BU Authorization method: bidding down Date: Mon, 11 Feb 2002 15:02:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > - the bit method locks us to one method, no much alternatives in the > > future nor room for replacement (even a chosen CGA method may need > > change, e.g. for better security or optimization, then the bit > > encoding needs to change again, so it may be not too good for even CGA) > > It has been suggested that including the algorithm/key type/cga type > in the hash that generates the CGA address would suffice to distinguish > between all different types of CGA-like schemes. That is, > > interface id part = hash(public key + ADDRMETH_CGA_CGA1 + RSA + MD5) > > or similar. In addition, I believe all infrastructure-based BU authorization > solutions can be made to work with the selection being done by the > infrastructure, not a bit in the address. For instance, assuming you > protected BUs with PKI-driven IPsec, your policy data base (possibly > distributed from a central point) would dictate for which addresses > you require the IPsec protection. > I don't see how this would allow the CN to determine what the algorithm is if the hash is irreversable. Also, this assumes precisely the currently proposed, IPR-protected CGA algorithms. It is possible that the another type of algorithm which provides cryptographic security on addresses might have different requirements on the interface id part, that would be incompatible with using this kind of scheme. I don't claim to have any solutions to the problem of identifying the algorithm. I can see how the bit method would work to identify whether or not RR should be used, though I think it is limited and weak for that purpose. Is it really necessary now to figure out how to identify the cryptographic algorithm, or do we just need to know whether RR should be used or not? If the latter, then maybe we can figure out some other way rather than using the bits. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 19:42:19 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21061 for ; Mon, 11 Feb 2002 19:42:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03153; Mon, 11 Feb 2002 16:41:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28176; Mon, 11 Feb 2002 16:41:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C0eZFh005904 for ; Mon, 11 Feb 2002 16:40:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C0eZcp005903 for mobile-ip-dist; Mon, 11 Feb 2002 16:40:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C0eWFh005896 for ; Mon, 11 Feb 2002 16:40:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27488 for ; Mon, 11 Feb 2002 16:40:34 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA06911 for ; Mon, 11 Feb 2002 17:40:32 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA29679; Mon, 11 Feb 2002 16:40:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1C0eRA20972; Mon, 11 Feb 2002 16:40:27 -0800 X-mProtect:  Mon, 11 Feb 2002 16:40:27 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9JzI7f; Mon, 11 Feb 2002 16:40:24 PST Message-ID: <3C686477.3A22E5C9@iprg.nokia.com> Date: Mon, 11 Feb 2002 16:40:23 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > Here is a simple proposal to allow selection of alternative BU authorization > > schemes. Perhaps you folks have already thought about it.. In any case, I > > would appreciate your feedback. > > > > The objective is to securely indicate to the CN the MN's intention to > > use a "better BU method". For this, why not include a signed hash covering a > > "selector" byte in the RR messages ? For instance, > > > > - the MN sends Nonce N1, and an 8-bit integer "selector" > > set to "better BU" mechanism in 1b. > > > > - the MN sends Nonce N2, and a signed hash of N1, N2, the > > "selector" field and the MN's Public Key in 1a. > > > > -the CN would verify the hash before accepting the method > > outlined in the "selector" field for BU authorization. > > > > The selector field can take different values including RR only, RR+DH, > > RR+CGA etc. > > Imagine an attacker between the CN and the MN. > Such an attacker can send packets to the CN claiming to want to use RR > for BU security and can claim that the CoA is either itself, > another address for which it is also on the path for, or a co-conspirator. > > It can then do the above exchange without any problems. How does the attacker see N2 in 1a ? > > > Since the attacker is on the path(s) it can presumably also prevent the > packets from being delivered to the MN, thus the MN wouldn't be aware of > this. Isn't this a different problem ? The attacker could also drop plain RR packets.. -Rajeev > > > Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 11 21:10:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21960 for ; Mon, 11 Feb 2002 21:10:21 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08067; Mon, 11 Feb 2002 19:10:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16956; Mon, 11 Feb 2002 18:09:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C294Fh006031 for ; Mon, 11 Feb 2002 18:09:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C294sS006030 for mobile-ip-dist; Mon, 11 Feb 2002 18:09:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C290Fh006023 for ; Mon, 11 Feb 2002 18:09:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03640 for ; Mon, 11 Feb 2002 18:09:02 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06225 for ; Mon, 11 Feb 2002 18:09:02 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA05138; Mon, 11 Feb 2002 18:09:01 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1C290Q15646; Mon, 11 Feb 2002 18:09:00 -0800 X-mProtect:  Mon, 11 Feb 2002 18:09:00 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRfPhQw; Mon, 11 Feb 2002 18:08:59 PST Message-ID: <3C68793C.18FEAC62@iprg.nokia.com> Date: Mon, 11 Feb 2002 18:09:00 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Erik, Erik Nordmark wrote: > > > When the MN is active and has a active binding at the CN > > created through RR+CGA, an attacker cannot bid down. For > > details, see Jari Malinen's mail that was sent out yesterday. > > I expressed some concerns with Jari Malinen's proposal earlier today > having to do with two assumptions: > - that the IP layer on the CN know what is "start of a new session" > - that RO will always be setup immediatly at the start of a new session > (as opposed to the possibility of deferring RO until there appears > to be a "flow" of packets that would benefit from the optimization) I guess Jari has replied to those concerns. > > > When the MN is active and is initiating RR+CGA as described > > in Rajeev's mail, an attacker cannot bid down because > > he cant see 1b. > > Is this the case when the CN already has a BCE for the real MN? it does not matter. Just follow this simple rule. If there is an existing binding created by RR and the CN gets a new RR message from MN saying that the MN wants to do RR+CGA, it deletes the existing binding (the attacker cant see the two nonces N1 and N2, unless the attacker is on the CN link, which we dont consider). The CN then does RR+CGA with the MN. Nonce N1 and selector go in one message. Nonce N2 and the hash (N1 + N2 + selector) goes in another message. An attacker cant see both these messages unless he is on the CN's link or the MN's link. Please, for a moment, see this mechanism as a generic mechanism to select any BU authorization methods based on RR. > > You are saying that the attacker could create a binding > > at the CN when the MN is not active, right? But I am saying > > that when the MN comes back alive, it is going to initiate > > RR+CGA binding at the CN (it WILL because it does not have > > a corresponding Binding Update List entry for the CN). The > > binding created by the attacker is invalidated. > > You are assuming that the MN will immediately setup RO. > When sending e.g. queries to a DNS server (a single request response) it > might not make sense to setup RO before the exchange. > What if the DNS servers (the resolvers) that the MN is configured to > use have bogus BCEs for the MN? I could also argue, that a mobile node does not have to use the home address option for a DNS query. It could send a normal packet with the source address being CoA. this was always an option in the mobile node. You are actually basing your argument on the assumption that the attacker could somehow figure out that a particular mobile node is about to set up a very short lived session with a particular correspondent node. And the attacker gets "into position" (basically figure out the route that packets will take) to launch the RR attack. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 02:10:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05287 for ; Tue, 12 Feb 2002 02:10:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08579; Tue, 12 Feb 2002 00:09:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03537; Mon, 11 Feb 2002 23:09:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C785Fh006658 for ; Mon, 11 Feb 2002 23:08:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C785su006657 for mobile-ip-dist; Mon, 11 Feb 2002 23:08:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C781Fh006650 for ; Mon, 11 Feb 2002 23:08:02 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1C77vM12899; Tue, 12 Feb 2002 08:07:58 +0100 (MET) Date: Mon, 11 Feb 2002 23:26:15 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] BU Authorization method: design team recommendation To: Franck.Le@nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <57A26D272F67A743952F6B4371B8F8118761E3@daebe007.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Frank, > I do not see the issue: there will be a new application for this service and > the AAA servers will process the messages in the same way they have been > specified to behave in the Diameter Mobile IPv4 application and in the AAA > Registration keys drafts. Yes, and several people have expressed concern that we didn't look carefully at the implications when RFC 2799 was approved - that seems to have been the point when we for better or worse chose to make the AAA servers into application layer routers of any message that needs security. So just becuase the Diameter moble IPv4 stuff takes this approach doesn't mean that it is the best approach. Could be quite the opposite IMHO. > > It might be better to just make the AAA servers an explicit PKI with > > cross-certificates etc. > > AAA server acting as a PKI is another possibility but in such case, the AAA > servers need more functionnalities: they do not only need to act as > Certicate Authority but msut also maintain all other PKI services such as > Key Revocation, Key history, etc. which is heavier. I don't think the PIC servers do this - they just hand out very short lived certificates as one of the options. See draft-ietf-ipsra-pic > I don't get the point. How is it relevant ? > But to answer your question, a pre-configured list mapping NAI->home address > for all nodes in sun.com could be maintained; or dynamic home agent > assignement could be performed. My point wasn't about the home agents addresses changing - it was about how to handle the updates to the home addresses changing e.g. due to a site renumbering or due to the MNs using RFC 3041 and picking a new home address occasionally. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 02:51:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05624 for ; Tue, 12 Feb 2002 02:51:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26606; Tue, 12 Feb 2002 00:50:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11764; Mon, 11 Feb 2002 23:49:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C7n2Fh006766 for ; Mon, 11 Feb 2002 23:49:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C7n20a006765 for mobile-ip-dist; Mon, 11 Feb 2002 23:49:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C7mxFh006758 for ; Mon, 11 Feb 2002 23:48:59 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07339 for ; Mon, 11 Feb 2002 23:49:00 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07018 for ; Mon, 11 Feb 2002 23:48:59 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1C7mvQ20027 for ; Tue, 12 Feb 2002 09:48:58 +0200 Date: Tue, 12 Feb 2002 09:48:57 +0200 (EET) From: Pekka Savola To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] [CLARIFICATION] Home Address Option: design team recommendation In-Reply-To: <3C684E38.9070406@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 12 Feb 2002, Jari Arkko wrote: > 1. INTRODUCTION > =============== > > The main problem with the Home Address Option (HAO) is its > potential to be used as a part of Denial-of-Service > attacks. More precisely, the Home Address Option helps > the attacker to conceal his or hers location. Note: this can also be used for spoofing attacks (e.g. exploits in stateless protocols like UDP (unless TCP sequence numbers are guessed)) unless destination site implements a firewall policy that examines HAO of the packet and rejects it if it belongs to the site provided that it isn't a Home Address of a roaming local node. I don't think all that many firewalls will implement checks like this. > 2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS > > In this alternative, a traceback of the attacker is performed > by having the CN include additional information in the > reflected packets. In particular, the CN could include the > claimed source address of the original packet in the response, > e.g. in the "OAH Destination Option". > > This approach is an easy one to provide within the MIPv6 > specifications. A disadvantage is that it helps mainly for > traceback, and does not help as much prevention -- for > instance the victim's ISP could not filter the attacker's > packets using IP source address, but would have to look at the > option. (Prevention may still be possible, but could require > additional functionality in e.g. routers and filtering > firewalls.) A larger drawback of this scheme is that there are > IPv6 socket API implications, at least for UDP applications, > in order to ensure that the response sent due to a request > containing a HAO always contains a OAH option. Note: this could be implemented in a similar fashion as routing header: "segments left" decremented and if it reaches 0, the option would no longer be processed. However, as it seems ADA will be preferred over RH#1, these kind of semantics probably don't make sense. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 04:09:44 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06450 for ; Tue, 12 Feb 2002 04:09:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26571; Tue, 12 Feb 2002 01:07:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20098; Tue, 12 Feb 2002 01:07:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C95SFh006890 for ; Tue, 12 Feb 2002 01:05:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C95Sud006889 for mobile-ip-dist; Tue, 12 Feb 2002 01:05:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C95OFh006882 for ; Tue, 12 Feb 2002 01:05:24 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08576 for ; Tue, 12 Feb 2002 01:05:26 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00100 for ; Tue, 12 Feb 2002 01:05:20 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1C95Fa12407; Tue, 12 Feb 2002 10:05:15 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA25453; Tue, 12 Feb 2002 10:05:15 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1C95Eg01845; Tue, 12 Feb 2002 10:05:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202120905.g1C95Eg01845@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Mon, 11 Feb 2002 20:43:33 +0100. Date: Tue, 12 Feb 2002 10:05:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > But this seems rather different than having the AAA infrastructure be an > intermediary between two clients (the MN and CN) of the AAA with the > purpose > of gettting those to clients to trust eachother. > > => no, third trust-party: the MN and the CN trust the AAA so they can trust > each other (of course we have to explain what they trust about). >From a trust perspective, yes, but that wasn't my point. What I was trying to refer to is some abstract notion of information flow where the model using AAA seems to make information flow from MN -> AAAh1 -> AAAh2 -> CN => in my mind AAA is mainly usable when the CN is the HA (so the HRs (Home Registrations) as a special of BUs discussion). I don't believe in AAA for general CNs, this should be even harder than a global PKI... But if I understand your model there is a second interesting case: CN is mobile and/or in the same home domain/domain cluster. Which is very different that the traditional model of MN -> AAAl -> AAAh and a reply AAAh -> AAAl -> MN => this is the model I am working on (MN-AAAl-AAAh-HA). In the former case the AAA needs to know that it needs to contact the CN at the other end, whereas in the latter case it is just the AAA returning attributes. => I agree, the h1/h2 model needs more work if we'd like to try it. Something that fits the traditional model better is to do more of a PIC-like architecture where - CN is configured to accept certificates signed by AAAh2 for the purposes of BU authorization - MN -> AAAh1 -> AAAh2 returns such a short-lived certificate to MN - MN presents this to CN e.g. using IKE => yes, a credential based approach seems to be good (the credential is the short-lived certificate). > > => so my question is that HRs are special BUs, do we develop a full > special > > case or are any solution good for HRs available for BUs too in > favourable > > cases? This seems to be Vijay's concern and I fully agree with him. > > What is a "HR"? > > => Home Registrations. I don't know exactly what is desirable for HR. => at least to get a open door in the BU stuff? An "easy" approach would just be to use IKE + ESP for those, but that means that MNs need to implement IKE. => I've tried this (with AH which is a bit easier than ESP as discussed in a zillion of messages in lists). It works but it is terribly heavy and slow: IKE configuration is a nightmare, certificates are lost in first exchanges because of the path MTU discovery and UDP transport, IKE does *not* like message lost, etc. It takes many seconds to get the SA pair when the MN boots in visit. In fact the only good point is this works and was tested between independent implementations. This is why I work on AAA based solutions as an alternative (AAA is far better but is not a candidate for a general solution). BTW IKE is available on very small boxes, Palm Pilots and Psions for instance. Just using ESP with manual keys means that IPsec can't provide replay protection but a simple sequence number in the HRs (or a cookie exchange - but that adds a round-trip) would handle the replay protection for HRs. => there is a fine but subtle text in the MIPv6 I-D explaining the difference between anti-replay protection and sequencing... My concern about ESP with manual keys should be this is simply near unusable in practice. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 04:15:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06596 for ; Tue, 12 Feb 2002 04:15:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21844; Tue, 12 Feb 2002 02:15:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16530; Tue, 12 Feb 2002 01:14:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C9E4Fh006963 for ; Tue, 12 Feb 2002 01:14:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1C9E4aJ006962 for mobile-ip-dist; Tue, 12 Feb 2002 01:14:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1C9E1Fh006955 for ; Tue, 12 Feb 2002 01:14:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01011 for ; Tue, 12 Feb 2002 01:14:03 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17350 for ; Tue, 12 Feb 2002 02:14:02 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1C9Dma13499; Tue, 12 Feb 2002 10:13:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA25669; Tue, 12 Feb 2002 10:13:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1C9Dlg01948; Tue, 12 Feb 2002 10:13:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202120913.g1C9Dlg01948@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Mon, 11 Feb 2002 12:35:25 PST. <3C682B0D.6803D9FF@iprg.nokia.com> Date: Tue, 12 Feb 2002 10:13:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: To my understanding, we don't have to solve the problem of establishing security associations between home agent and mobile node. => I agree but today the BU recommendation makes no provision for something not based on RR [+ CGA] for this. IMHO this issue is only a problem of the scope of the recommendation (this should be in the introduction but is not). It will be hard enough to solve the problems we have to solve already. => the first step to a solution is an accurate definition of the problem, isn't it? Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 05:05:38 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07126 for ; Tue, 12 Feb 2002 05:05:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07823; Tue, 12 Feb 2002 03:05:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21602; Tue, 12 Feb 2002 02:05:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CA47Fh007170 for ; Tue, 12 Feb 2002 02:04:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CA47x3007169 for mobile-ip-dist; Tue, 12 Feb 2002 02:04:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CA43Fh007162 for ; Tue, 12 Feb 2002 02:04:03 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CA3xM00181; Tue, 12 Feb 2002 11:03:59 +0100 (MET) Date: Tue, 12 Feb 2002 10:59:50 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <3C686477.3A22E5C9@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev, > How does the attacker see N2 in 1a ? In one case because the attacker is the entity sending 1a and 1b specifying the real HoA of the MN. It could do this every second or so so that even if the real MN was doing BUs they would be overridden in less than 1 second. Also, an attacker on the same link as the CN would see both 1a and 1b. Assuming that the "leaf" links are the least secure (imagine a CN in the IETF WLAN/terminal room) this would be a likely source of attacks. > > Since the attacker is on the path(s) it can presumably also prevent the > > packets from being delivered to the MN, thus the MN wouldn't be aware of > > this. > > Isn't this a different problem ? The attacker could also drop plain RR > packets.. I was jumping ahead - I thought the issue about the real MN being able to "veto" the on-path attacker claiming to be that MN was one of the underlying points. My point is that such a "veto" assumes a bunch of things including that the on-path attacker can't prevent packets from being delivered. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 05:55:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07522 for ; Tue, 12 Feb 2002 05:55:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20382; Tue, 12 Feb 2002 03:53:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22826; Tue, 12 Feb 2002 02:53:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CAqlFh007285 for ; Tue, 12 Feb 2002 02:52:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CAql8Y007284 for mobile-ip-dist; Tue, 12 Feb 2002 02:52:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CAqiFh007277 for ; Tue, 12 Feb 2002 02:52:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27211 for ; Tue, 12 Feb 2002 02:52:47 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02617 for ; Tue, 12 Feb 2002 03:52:46 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id DAA00108 for ; Tue, 12 Feb 2002 03:52:46 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA01803 for ; Tue, 12 Feb 2002 03:52:46 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Tue, 12 Feb 2002 04:52:35 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id AD50E2EC83; Tue, 12 Feb 2002 11:47:39 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation References: <200202111801.g1BI11g99234@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 12 Feb 2002 11:52:42 +0100 In-Reply-To: <200202111801.g1BI11g99234@givry.rennes.enst-bretagne.fr> Message-Id: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis Dupont writes: > I don't think you disagree with the actual text i.e. that several IPR > claims have been made. What are the IPR claims that have been made? What patents? What yet-to-be-filed disclosures? > => I disagree about the consequences of this fact, not about the > fact. I guess the consequences are proportional to the breadth of the claims in the respective patent(s). If there's a pile of them covering every aspect of CGA's and all posible methods for implementing then there'll be trouble in getting CGA's standardized. If however the claims are limited to certain aspects then it's always possible to "design around", right? Also, the conditions under which those patents are licensed matter a lot. If one company has all patents in this area and licenses all of them for no charge, then it's fine, I believe. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 06:04:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07598 for ; Tue, 12 Feb 2002 06:04:43 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27130; Tue, 12 Feb 2002 04:03:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25077; Tue, 12 Feb 2002 03:03:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CB2eFh007543 for ; Tue, 12 Feb 2002 03:02:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CB2eOw007541 for mobile-ip-dist; Tue, 12 Feb 2002 03:02:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CB2bFh007534 for ; Tue, 12 Feb 2002 03:02:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28612 for ; Tue, 12 Feb 2002 03:02:39 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23352 for ; Tue, 12 Feb 2002 04:02:38 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1CB2b43002963 for ; Tue, 12 Feb 2002 12:02:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Feb 12 12:02:35 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 11:53:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4DAA6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] BU Authorization method: design team recommendati on Date: Tue, 12 Feb 2002 12:01:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > because I still have some concerns about CGA. CGA may not > > protect well for IPv4 mapped address, etc. > > => This is not a good example IMHO. mapped addresses > are only used (on the wire) for SIIT. > > => the example is not good but the concern is real. > A standard question in the IPv6 WG mailing list is "may I > assume that IID have 64 bits" and the standard answer is no. > Cf. draft-ietf-ipngwg-addr-arch-v3-07.txt: > > For all unicast addresses, except those that start with > binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > So ::/3 unicast addresses may use another format. => But the point is, these addresses are irrelevant to this discussion: - IPv4-compatible - IPv4-mapped - IPv4-translated None of them will be used for MIPv6. What am I missing? Are you saying new addresses might be defined in that space? > I don't know if this is a real concern for CGAs (this and > the 1 bit stuff should be presented to the IPv6 WG or > CGAs won't be available for more than MIPv6...). => CGAs are probably useful for more than MIPv6, but I don't think the concern about 000 addresses is relevant. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 06:06:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07676 for ; Tue, 12 Feb 2002 06:06:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA26213; Tue, 12 Feb 2002 04:00:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24282; Tue, 12 Feb 2002 03:00:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CAxVFh007508 for ; Tue, 12 Feb 2002 02:59:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CAxVM8007507 for mobile-ip-dist; Tue, 12 Feb 2002 02:59:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CAxSFh007500 for ; Tue, 12 Feb 2002 02:59:28 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26598 for ; Tue, 12 Feb 2002 02:59:31 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10043 for ; Tue, 12 Feb 2002 02:59:23 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 72BEC6A908; Tue, 12 Feb 2002 12:58:50 +0200 (EET) Message-ID: <3C68F3D8.9050606@piuha.net> Date: Tue, 12 Feb 2002 12:52:08 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: bidding down References: <3C683D40.3E3E0CF8@iprg.nokia.com> <3C6848BA.7040503@piuha.net> <07e401c1b350$3e291580$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > I don't see how this would allow the CN to determine what the algorithm > is if the hash is irreversable. The point was that if the algorithm is included in the hash, then the MN can provide the algorithm in its request, and the CN can verify the algorithm by verifying the hash. (And no, I'm not sure we need anything to be able to change algorithms, but I just used "algorithm" as an example.) > Also, this assumes precisely the currently proposed, IPR-protected > CGA algorithms. It is possible that the another type of algorithm > which provides cryptographic security on addresses might have > different requirements on the interface id part, that would be > incompatible with using this kind of scheme. Maybe. But -- if you have a cryptographic security on addresses, wouldn't it be reasonable to assume that such a non-CGA mechanism would also allow similar hashing? For instance, a symmetric-key based CGA-like scheme would allow this as well. I'm not sure a symmetric key scheme would be useful, but again this is just an example. > I don't claim to have any solutions to the problem of identifying > the algorithm. I can see how the bit method would work to > identify whether or not RR should be used, though > I think it is limited and weak for that purpose. Is it really necessary > now > to figure out how to identify the cryptographic algorithm, > or do we just need to know whether RR should be used > or not? > > If the latter, then maybe we can figure out some other way > rather than using the bits. I think the latter is precisely what the intention is: these addresses are set aside for RR in a manner that we can later, without fear of bidding down, use something else later. (Henrik Petander also proposed that the bits would be selected so that stationary nodes could not be claimed as mobile.) I eager to hear if you have another solution than using the bits. I'm just not sure there can be much else, given that all the information we have in the RR case is (a) the request and (b) the address. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 06:47:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08144 for ; Tue, 12 Feb 2002 06:47:09 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10086; Tue, 12 Feb 2002 04:46:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01904; Tue, 12 Feb 2002 03:46:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CBk0Fh007652 for ; Tue, 12 Feb 2002 03:46:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CBk0rT007651 for mobile-ip-dist; Tue, 12 Feb 2002 03:46:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CBjuFh007644 for ; Tue, 12 Feb 2002 03:45:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04947 for ; Tue, 12 Feb 2002 03:45:58 -0800 (PST) Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA09793 for ; Tue, 12 Feb 2002 04:45:57 -0700 (MST) Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for pheriche.sun.com [192.18.98.34]) with SMTP; 12 Feb 2002 11:45:20 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id GAA04342 for ; Tue, 12 Feb 2002 06:45:53 -0500 (EST) Received: from spirit.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with SMTP id g1CBjpa02320 for ; Tue, 12 Feb 2002 06:45:52 -0500 (EST) Received: (qmail 21832 invoked from network); 12 Feb 2002 11:45:51 -0000 Received: from sjosefsson-pc.d.dynas.se (172.16.13.115) by spirit.dynas.se with SMTP; 12 Feb 2002 11:45:51 -0000 To: Ignacio Soto Campos Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: draft on random interface identifiers available References: <3C5EAE12.DA5F9400@it.uc3m.es> From: Simon Josefsson Date: Tue, 12 Feb 2002 12:45:49 +0100 In-Reply-To: <3C5EAE12.DA5F9400@it.uc3m.es> (Ignacio Soto Campos's message of "Mon, 04 Feb 2002 15:51:46 GMT") Message-ID: Lines: 15 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Ignacio Soto Campos writes: > Hi all, > > We have submitted the draft "Random generation of interface > identifiers" that is available from: > > http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt > > The abstract is included below. Comments are welcomed. To describe how "random generation" of interface identifiers can be done properly, you might want to cite RFC 1750. Due to the nature of this, using only network traffic as a source of randomness might not be perfect, I'm not sure if it is worth making a note of this. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 09:13:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12296 for ; Tue, 12 Feb 2002 09:12:58 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26845; Tue, 12 Feb 2002 07:12:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01744; Tue, 12 Feb 2002 06:12:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEBZFh008063 for ; Tue, 12 Feb 2002 06:11:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CEBZXC008062 for mobile-ip-dist; Tue, 12 Feb 2002 06:11:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEBVFh008055 for ; Tue, 12 Feb 2002 06:11:32 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CEBPM25090; Tue, 12 Feb 2002 15:11:26 +0100 (MET) Date: Tue, 12 Feb 2002 15:07:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: bidding down To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C683D40.3E3E0CF8@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > - First, it might be good to motivate this discussion. It would > be to see if an alternative method for the 1-bit method is possible. > This because there are some problems with the 1-bit method mentioned > by others including I do agree it makes sense exploring other methods here. > - the bit method locks us to one method, no much alternatives in the > future nor room for replacement (even a chosen CGA method may need > change, e.g. for better security or optimization, then the bit > encoding needs to change again, so it may be not too good for even CGA) For CGA itself I don't know how significant the problem - requires more understanding of the evolution of crypto algorithms than I have. One could take two different approaches for defining the semantics of the bit: - An address with the CGA bit set has an interface ID which is the bottom 64 bits of a hash of a public key (with the universal and group bits set to indicate the CGA property) - Same as above but instead of "hash" say SHA-1. One question is what the tradeoffs are between the two descriptions. If the hash is not specified how would a peer know which hash to apply to verify the public key - interface ID relationship and what are the security issues in communicating that insecurely to the peer? If the hash is specified what is the likelyhood that there will be a new more secure hash (when truncated to 62 or 63 bits) in the future thus there will be a need to move to using that hash. Note that more secure hash functions will appear e.g. hashes producing longer results - the question is whether the fact that the result must be truncated change the likely evolution. What has history tell us about the latter question? > - the requirement for change is extensive for the bit alone, while also > the CGA method itself is not standardized, requiring several yet not > existing normative references to base MIPv6 and changes in RFCs. I think the change to reserve the bit might be as small as one sentence in each of RFC 2373, RFC 3041 and RFC 2472. Having MIPv6 not allow RR when the bit is set is presumably a short paragraph in the mipv6 spec. So I don't know what you mean by "extensive" - the amount of time to complete the above? [AD hat on: I think reserving a bit in the interface ID makes sense independently of CGA - there might be some great new idea in the future that could benefit from a bit even if CGA doesn't need one.] > The brief idea was formulated so that it looks like this but > looking closer it is not exactly so. It considers issues in > one particular idea of doing on-line signaling, but is here > for the case of illustration on-line signaling might be possible. > > - There is no need to actually establish RO, just to do some signaling, > to be precise, immediately after receiving the first non-RO packet > with subsequent rate limiting not to do that for every non-RO packet. > This could be a de-registration establishing the level of authorization > and that MN wishes to do no RO, but e.g. bidir. tunneling, if desired. Hmm - that would seem to imply that the CN would need to keep state oer MN even when RO is not used. That state might be just one bit (e.g. don't accept RR BUs) but it would still require separate state maintenance. > - Or, one could add offline tag to support this case (an extension to DNS) > which gives the minimum condition for the BCE making CN garbage collect > too low priority BCEs and would be much more flexible for future > change than address bit encoding and would require change to 1 place > beyond base MIPv6 instead of many, just to give an example of > an alternative to 1-bit which is a more "offline" method. Yes, but since applications today sit between the DNS (i.e. getaddrinfo()) and the protocol stack (socket interface) in many systems this would require changes to the APIs to be able to pass this information. Also, today typically only the initiating end of communication does a DNS lookup. The above would require the accepting end of communication to also do a DNS lookup - since that end can't securely know the DNS name of the peer it presumably needs to do a reverse lookup to find the hostname and then look for the "tag" record in the forward DNS tree. > - Since it is not clear your example really is a relevant "present > attack" against bidding down, (see my comment at end) one might > consider what about "future attacks" (victim is not around when > bidding down happens), leaving the CN-initiated traffic the relevant > one to discuss. As with RR, garbage-collecting unused BCEs > frequently (which would happen anyway in the case of "lower" > method being RR). This limits the scope of the attack to something > that could be considered insignificant enough, as one possible > alternative. I think there are present bidding down attacks. (See below). > > > Suppose we are using a simple rule in CN which > > > tags BCE telling how it was authorized and refuses > > > BUs with lower-priority authorizations during the > > > lifetime of a BCE but any time accepts authorizations > > > of the same or higher method. Legitimate MN is never > > > blocked from regaining the BCE nor can it lose it > > > when it needs the BCE. When legitimate MN is not > > > communicating, it should be enough for the CN > > > to expire unused BCEs injected by RR attacker > > > for the CN to be able to communicate with the > > > legitimate MN, and/or always start its sessions > > > with non RO data packet despite BCE. > > > > The "starts its session" seems to imply that the IP layer, when choosing > > whether or not to use a RR BCE, needs to be able to identify a new session > > indepedently of the transport and application protocol. > > > > For TCP and SCTP I can see us doing this, but what about some yet to > > be invented protocol over (congestion controlled) UDP? Reliable multicast? > > It seems impossible to make this distinction in general. > > The "start session" option should be generalized as > the ability by CN to check whether a BCE was not set > up by a too "low" method. It could be based on recognizing > sessions (setting new flows could be one way), or also > to periodically send non-RO packets and a condition that > MN needs to respond to those with a BU (which can be > deregistration if one does not want to start RO now > or at all). This to invoke discussion looking more deeply > to generic locally standardizable on-line signaling > alternatives. Sure sounds complex. The periodic recheck is basically saying that you allow DoS blackhole attacks for a time less than the period. If this period is longer than the time for upper layer protocols (be it transport or application protocols) to give up the DoS attack has been successful. If that causes the recheck to happen every 10 seconds this might be a lot of background chatter on the wire. > > If the attacker is actually on the CN - HA path it can presumably cause > > that attempt to establish RO with CGA security fail by dropping > > the relevant packets. > > But this means that the CN - HA path is not essentially different > securitywise for RR from RR+CGA, hence making it irrelevant whether > bidding down signaling is dropped since _no_ online signaling > can then really work. This actually includes the bit method. A > CGA address cannot then be delivered to CN (even DNSSEC can be > then disturbed amounting at least to a DoS attack against > CN-initiated connections). That's why tampering with forwarding > is not a very fruitful case for the analysis, you can most > likely kill any bidding down mechanism or signaling that such > mechanism guards when CN does not statically know the lowest > method acceptable. An on-path attacker can of course drop all the data packets and accomplish DoS that way. I don't understand your point about DNSSEC - if DNSSEC is used by the CN to find the MN's HoA then the CN will know for sure the setting of the bit. But I think it would be useful to pop up a level when analysing the residual threats. Per the DT document CGA protected BU's are strictly more secure than RR protected BU's when it comes to e.g. future attacks and the need for RR checks against the HoA in the context of attackers that are on the path. Question is whether this matters in the large scheme of things for MIPv6. Such an attacker can just drop data packets as a DoS attack and can already (by virtue of being on the path and thereby being able to prevent RO) see all the data packets (and modify them unless they are protected by higher layer security like IPsec or TLS). So does CGA, as we understand it today, really make a significant enough difference for MIPv6? (I continue to believe that CGA would be a useful tool in authrizing e.g. MLD joins for anycast groups, preventing DAD and address resolution spoofing on a link, but those approaches might not need a bit in the address - to early to tell.) Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 09:26:35 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12912 for ; Tue, 12 Feb 2002 09:26:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13699; Tue, 12 Feb 2002 06:26:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04401; Tue, 12 Feb 2002 06:26:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEPNFh008144 for ; Tue, 12 Feb 2002 06:25:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CEPM3P008143 for mobile-ip-dist; Tue, 12 Feb 2002 06:25:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEPEFh008134 for ; Tue, 12 Feb 2002 06:25:19 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CEP3M26553; Tue, 12 Feb 2002 15:25:03 +0100 (MET) Date: Tue, 12 Feb 2002 15:20:46 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Vijay Devarapalli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C68793C.18FEAC62@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay, > Nonce N1 and selector go in one message. Nonce N2 and the hash > (N1 + N2 + selector) goes in another message. An attacker cant > see both these messages unless he is on the CN's link or the MN's > link. Please, for a moment, see this mechanism as a generic > mechanism to select any BU authorization methods based on RR. Yes, but I suspect an attacker on the CN's link is a common high-level threat today with 802.11 and other multi-access links. (Using spoofed router advertisements or neighbor advertisements, if the L2 can't be spoofed, in order to see all packets.) > > You are assuming that the MN will immediately setup RO. > > When sending e.g. queries to a DNS server (a single request response) it > > might not make sense to setup RO before the exchange. > > What if the DNS servers (the resolvers) that the MN is configured to > > use have bogus BCEs for the MN? > > I could also argue, that a mobile node does not have to use > the home address option for a DNS query. It could send a > normal packet with the source address being CoA. this was > always an option in the mobile node. I don't think my arguement assumed that CoAs couldn't be used for such short-lived connections. If I made that implicit assumption please point it out to me. In general the tradeoffs whether to use a CoA for short lived communication vs. the HoA depends on lots of factors like predicting the length of communication and the likely time of the next move. There are likely to be cases where using a HoA makes sense due to unknown in the above time factors even though the number of packets exchanged might not be sufficient to warrant a RO. > You are actually basing your argument on the assumption > that the attacker could somehow figure out that a particular > mobile node is about to set up a very short lived session > with a particular correspondent node. And the attacker gets > "into position" (basically figure out the route that packets > will take) to launch the RR attack. No. The session doesn't have to be short lived. It is the fact that I don't think we should assume that all sessions immediately go to RO (due to short-lived or few-packet sessions existing) that makes the attack possible. If the CN can't know when a new session has started and for how long during the start of a new session it should ignore RR-protected BUs (because the MN might want to use a CGA-protected BU) then the attack is possible. And hardcoding the policy for what is a "new session" and "how long" wouldn't be good for interoperability. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 09:54:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13801 for ; Tue, 12 Feb 2002 09:54:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14812; Tue, 12 Feb 2002 07:53:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10483; Tue, 12 Feb 2002 06:53:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEpsFh008213 for ; Tue, 12 Feb 2002 06:51:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CEpsaV008212 for mobile-ip-dist; Tue, 12 Feb 2002 06:51:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEpXFh008205 for ; Tue, 12 Feb 2002 06:51:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12868 for ; Tue, 12 Feb 2002 06:51:32 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09982 for ; Tue, 12 Feb 2002 07:51:30 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CEpSa11406; Tue, 12 Feb 2002 15:51:28 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA03601; Tue, 12 Feb 2002 15:51:28 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CEpSg03619; Tue, 12 Feb 2002 15:51:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121451.g1CEpSg03619@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Cc: Alexandru Petrescu Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of 12 Feb 2002 11:52:42 +0100. Date: Tue, 12 Feb 2002 15:51:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: What are the IPR claims that have been made? What patents? What yet-to-be-filed disclosures? => oh! What want details? The only concrete fact is Christian Huitema's declaration at the last meeting (IPR stuff is sent to the IESG) > => I disagree about the consequences of this fact, not about the > fact. I guess the consequences are proportional to the breadth of the claims in the respective patent(s). If there's a pile of them covering every aspect of CGA's and all posible methods for implementing then there'll be trouble in getting CGA's standardized. If however the claims are limited to certain aspects then it's always possible to "design around", right? => I do *not* want to become a lawyer! Also, the conditions under which those patents are licensed matter a lot. If one company has all patents in this area and licenses all of them for no charge, then it's fine, I believe. => perhaps the patents are only for protection, i.e. in order to avoid a patent from someone else with licenses, etc. I have not the answer. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 09:58:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13958 for ; Tue, 12 Feb 2002 09:58:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16822; Tue, 12 Feb 2002 07:58:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11461; Tue, 12 Feb 2002 06:58:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEvTFh008279 for ; Tue, 12 Feb 2002 06:57:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CEvT5B008278 for mobile-ip-dist; Tue, 12 Feb 2002 06:57:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CEvQFh008271 for ; Tue, 12 Feb 2002 06:57:26 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13979 for ; Tue, 12 Feb 2002 06:57:28 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29585 for ; Tue, 12 Feb 2002 06:57:27 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CEvPa12155 for ; Tue, 12 Feb 2002 15:57:25 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA03744 for ; Tue, 12 Feb 2002 15:57:25 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CEvPg03724 for ; Tue, 12 Feb 2002 15:57:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121457.g1CEvPg03724@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendati on In-reply-to: Your message of Tue, 12 Feb 2002 12:01:59 +0100. <4DA6EA82906FD511BE2F00508BCF053802D4DAA6@Esealnt861.al.sw.ericsson.se> Date: Tue, 12 Feb 2002 15:57:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Are you saying new addresses might be defined in that space? => exactly! > I don't know if this is a real concern for CGAs (this and > the 1 bit stuff should be presented to the IPv6 WG or > CGAs won't be available for more than MIPv6...). => CGAs are probably useful for more than MIPv6, but I don't think the concern about 000 addresses is relevant. => the question is really to know if CGAs will be useful in a future format of 000 addresses... You believe no, I don't know, and this is *not* in the scope of this WG. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 10:20:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14856 for ; Tue, 12 Feb 2002 10:20:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22688; Tue, 12 Feb 2002 08:19:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27135; Tue, 12 Feb 2002 07:19:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CFIOFh008422 for ; Tue, 12 Feb 2002 07:18:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CFIOA2008421 for mobile-ip-dist; Tue, 12 Feb 2002 07:18:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CFIKFh008414 for ; Tue, 12 Feb 2002 07:18:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CFIGM05461; Tue, 12 Feb 2002 16:18:16 +0100 (MET) Date: Tue, 12 Feb 2002 16:14:06 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <200202120905.g1C95Eg01845@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Which is very different that the traditional model of > MN -> AAAl -> AAAh and a reply AAAh -> AAAl -> MN > > => this is the model I am working on (MN-AAAl-AAAh-HA). By "this" you couldn't mean the same as mine above, because they are very different. In mine the path stops at AAAh and in yours the HA is the end. Thus yours is the same as the yet-to-be-standardized diameter-mobileip model, which I think is less than ideal. Some while your idea is different than involving the CN as in draft-le-mobileip-dh-01.txt it still doesn't match the traditional architecture for AAA as implemented by Radius today. > In the former case the AAA needs to know that it needs to contact the CN > at the other end, whereas in the latter case it is just the AAA returning > attributes. > > => I agree, the h1/h2 model needs more work if we'd like to try it. But same for your model - the AAAh needs to contact the HA. > Something that fits the traditional model better is to do more > of a PIC-like architecture where > - CN is configured to accept certificates signed by AAAh2 > for the purposes of BU authorization > - MN -> AAAh1 -> AAAh2 returns such a short-lived certificate to MN > - MN presents this to CN e.g. using IKE > > => yes, a credential based approach seems to be good (the credential is > the short-lived certificate). Good. In that case do you see a need for AAAh to invoke the HA? > => at least to get a open door in the BU stuff? Do you see a closed door anywhere? I don't. The protocol would need to get worked out, and follow the normal standards track criteria. (clear, useful, etc) > An "easy" approach would just be to use IKE + ESP for those, but that > means that MNs need to implement IKE. > > => I've tried this (with AH which is a bit easier than ESP as discussed > in a zillion of messages in lists). It works but it is terribly heavy > and slow: IKE configuration is a nightmare, certificates are lost > in first exchanges because of the path MTU discovery and UDP transport, > IKE does *not* like message lost, etc. It takes many seconds to get the > SA pair when the MN boots in visit. In fact the only good point is > this works and was tested between independent implementations. > This is why I work on AAA based solutions as an alternative (AAA is > far better but is not a candidate for a general solution). > BTW IKE is available on very small boxes, Palm Pilots and Psions > for instance. Would AAA be better because diameter runs over SCTP instead of IKE over UDP? Others have claimed in the past that you don't want to run diameter on the client due to size? performance? concerns. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 10:32:13 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15313 for ; Tue, 12 Feb 2002 10:32:13 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27523; Tue, 12 Feb 2002 07:31:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29502; Tue, 12 Feb 2002 07:31:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CFUiFh008489 for ; Tue, 12 Feb 2002 07:30:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CFUiAC008488 for mobile-ip-dist; Tue, 12 Feb 2002 07:30:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CFUfFh008481 for ; Tue, 12 Feb 2002 07:30:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29293 for ; Tue, 12 Feb 2002 07:30:43 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02531 for ; Tue, 12 Feb 2002 08:30:43 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CFWZQ29973 for ; Tue, 12 Feb 2002 09:32:35 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Feb 2002 09:30:41 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 09:30:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: bidding down Date: Tue, 12 Feb 2002 09:30:22 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A126A4@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: bidding down Thread-Index: AcGzz2rosKg7B1I6SD2/sZ55oYHAugACrghg To: X-OriginalArrivalTime: 12 Feb 2002 15:30:22.0869 (UTC) FILETIME=[2FC3D450:01C1B3DA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1CFUgFh008482 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Erik Nordmark [Erik.Nordmark@eng.sun.com] wrote: > > >Question is whether this matters in the large scheme of things for >MIPv6. The current scope of the security problem for MIPv6 binding updates is solved by the RR approach. Hence the need for solutions that offer a greater degree of security for BUs should be independently pursued. >Such an attacker can just drop data packets as a DoS attack and can >already (by virtue of being on the path and thereby being able to prevent RO) >see all the data packets (and modify them unless they are protected by >higher layer security like IPsec or TLS). >So does CGA, as we understand it today, really make a significant enough >difference for MIPv6? CGA needs to be explored more before it is used by MIPv6 or for doing other things that you mention below. In order to get the base MIPv6 specification out, discussion of the CGA solution in the base spec should be extremely limited. An active attacker on the HA-CN path can do harm to communication irrespective of RR or CGA. The MITM (HA-CN) problem is not something that MIPv6 needs to solve. >(I continue to believe that CGA would be a useful tool in authrizing e.g. >MLD joins for anycast groups, preventing DAD and address resolution spoofing >on a link, but those approaches might not need a bit in the address - to >early to tell.) > > Erik > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 10:37:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15438 for ; Tue, 12 Feb 2002 10:37:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05874; Tue, 12 Feb 2002 08:37:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00478; Tue, 12 Feb 2002 07:37:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CFaMFh008554 for ; Tue, 12 Feb 2002 07:36:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CFaLgu008553 for mobile-ip-dist; Tue, 12 Feb 2002 07:36:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CFaIFh008546 for ; Tue, 12 Feb 2002 07:36:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22806 for ; Tue, 12 Feb 2002 07:36:21 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14632 for ; Tue, 12 Feb 2002 08:36:19 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1CFcBQ00657 for ; Tue, 12 Feb 2002 09:38:11 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Feb 2002 09:36:18 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 12 Feb 2002 09:36:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 12 Feb 2002 09:36:17 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A126A5@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] BU Authorization method: design team recommendation Thread-Index: AcGz0U82abvyN3x2QcWdEZNPCyf4LQACaS9A To: X-OriginalArrivalTime: 12 Feb 2002 15:36:17.0956 (UTC) FILETIME=[0369CE40:01C1B3DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1CFaJFh008547 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Erik Nordmark [Erik.Nordmark@eng.sun.com] wrote: >Vijay, > >> Nonce N1 and selector go in one message. Nonce N2 and the hash >> (N1 + N2 + selector) goes in another message. An attacker cant >> see both these messages unless he is on the CN's link or the MN's >> link. Please, for a moment, see this mechanism as a generic >> mechanism to select any BU authorization methods based on RR. > >Yes, but I suspect an attacker on the CN's link is a common high-level >threat today with 802.11 and other multi-access links. (Using spoofed >router advertisements or neighbor advertisements, if the L2 can't be >spoofed, in order to see all packets.) > But solving the security problems of 802.11 or other multi-access links is not ncecessarily Mobile IP WGs problem. I believe we need to avoid digressing into solving problems outside the scope of MIPv6 (and IMO securing 802.11 or other multi-access links is not within the scope of finding a solution for securing MIPv6 BUs) -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:04:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16434 for ; Tue, 12 Feb 2002 11:04:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15035; Tue, 12 Feb 2002 09:03:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07719; Tue, 12 Feb 2002 08:03:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CG2lFh008685 for ; Tue, 12 Feb 2002 08:02:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CG2lJJ008684 for mobile-ip-dist; Tue, 12 Feb 2002 08:02:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CG2iFh008677 for ; Tue, 12 Feb 2002 08:02:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04748 for ; Tue, 12 Feb 2002 08:02:46 -0800 (PST) From: georg.chambert@era-t.ericsson.se Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14504 for ; Tue, 12 Feb 2002 09:02:45 -0700 (MST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1CG2jB05462 for ; Tue, 12 Feb 2002 17:02:45 +0100 (MET) Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA15958; Tue, 12 Feb 2002 17:02:44 +0100 Message-ID: <3C693CA0.A6E617F6@era-t.ericsson.se> Date: Tue, 12 Feb 2002 17:02:40 +0100 X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Home Address Option: design team recommendation References: <3C684E38.9070406@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jari, isnt this a case where the "tool concept" way of designing things in the internet proves backsides. I mean, you cannot both have generic concepts and flexible ways to compose and construct things and yet still think that it will be secure, especially for all possible kinds of attacks. So isnt it possible that the basic way of design should be narrowed down for the ways to create mobility. Just a thought BR Georg Jari Arkko wrote: > The MIPv6 security design team is trying to resolve the issues > around potential Denial-of-Service vulnerabilities regarding > the Home Address Option. > > This note specifies the design team's motivation and current > position. In order to move forward in an efficient manner it > would be beneficial if responses could make it clear they are > - a clarification (by putting CLARIFICATION: in the Subject > field) > - an issue with a particular point (by ISSUE:) > - disagreement with the conclusion (by CONCLUSION:) > > We would also like folks to state for each of our three > separate recommendations whether they AGREE, CAN TOLERATE, or > DISAGREE with them. In case of DISAGREE, please explain why. > > 1. INTRODUCTION > =============== > > The main problem with the Home Address Option (HAO) is its > potential to be used as a part of Denial-of-Service > attacks. More precisely, the Home Address Option helps > the attacker to conceal his or hers location. > > 1.1. BASIC ATTACK > > The basic attack can be performed as follows: > > 1. Pick a victim host or network. > > 2. Pick any large set of other IPv6 nodes. There are no other > requirements for the selection of these nodes beyond them > having to be reachable from the Internet. > > 3. Send IPv6 packets with Src=attacker, Dst=reflector, > HOA=victim. Here reflector is one of the chosen IPv6 > nodes, possibly a different one for every sent packet. > The source address can be the attacker's own address. > The attack can be launched from a single host, or > be performed as a distributed attack. > > 4. Each reflector will process the IPv6 packet and respond. > The responses would typically be ICMP errors, ICMP > responses, UDP responses, or answers to TCP SYNs. Typically > at most a single packet is sent as as a response. (In a > variation of this attack, a reflector whose TCP sequence > numbers can be guessed some amplification can be achieved.) > > 5. Since the MIPv6 rules require CNs to use the Home Address > in return traffic towards the MN, the responses are sent to > the victim's address. The victim sees packets that have > Src=reflector, Dst=victim, and there is no indication of > the original source address. > > 1.2. SERIOUSNESS OF THE ATTACK > > The effect to the victim is that the hosts or the networks > Internet connection is filled with traffic. Since a reflector > is used, only replies can be sent and hence it may not be > possible to cause any much more trouble than the consumption > of communication resources. There is also no amplification > involved. On the other hand, the attacker can pick any > protocol to perform the attack, and the number of possible > reflectors is not limited to some special set of nodes such as > the DNS or web servers. In particular, the reflector nodes can > be private PCs and equipment without e.g. easy administrative > contacts, network monitoring, or logging of the used source > addresses. > > The main problem, however, comes from our (in)ability to > prevent these attacks. The two basic approaches to dealing > with Denial-of-Service attacks include ingress filtering, > which prevents the use of wrong addresses, and tracing schemes > such as itrace that can be used in post-mortem analysis of the > attack. Ingress filtering is partially deployed in today's > IPv4 world, and this can be expected to continue in the IPv6 > side. Tracing schemes are not yet deployed, at least not > widely. > > Normal, stateless and filter-based ingress filtering can't > deal with these attacks. This is because by definition of the > HAO, its value can't be expected to be local to the network > where it is being sent from. > > Tracing schemes as defined today can't deal with these attacks > either. Regular forward itrace, for instance, would only send > ICMP trace packets to the reflector on the first leg of the > path, and to the victim on the second leg of the path. But the > victim would not learn of the attacker's location due to the > existence of the reflector in between. A reverse itrace helps > trace back reflector attacks where the attacker has spoofed > the source address, but in this case this would not work as > the source field is not the victim. A hypothetical extension > to itrace, "3-way itrace", could though be defined to send > ICMP trace packets to (a) destination, (b) claimed source, and > (d) claimed home address. > > It seems therefore that ingress filtering is not sufficient > here, but a 3-way itrace might be. This is, however, just the > start of the hard part: allowing attacks that bypass ingress > filtering but are still caught with 3-way itrace could be > considered dangerous. Ingress filtering is by nature a > prevention mechanism while tracing is an analysis tool. > There's also three substantial differences between them: > > - Ingress filtering is partially deployed while itrace is > not. > > - Victim needs to wait more in itrace to figure out what's > going on. > > - Most importantly, since itrace doesn't force you to use a > specific IP address, it will not be possible for the victim > to act quickly by e.g. installing a filter in his network > or his ISP's network to block the offending IP > address. Instead, the victim must wait until the ISP or the > policy on the other side of the globe acts and installs a > filter on their site to block the attacker's link or > computers. This could be time consuming. > > There are other concerns around IPPT, a new technique similar > to itrace and a soon to be WG in the IETF. IPPT works by > hashing each individual packet so that an authorized user > (e.g. the NOC or a customer calling the NOC) can ask questions > about a single recent packet. The hash takes into account > such things as the TCP sequence numbers, the length of the > packet, etc. (but ttl is excluded since it changes in the > network). This means that any "transformation" needs > additional state. Example of transformations are IPv4 > fragmentation by routers, encapsulation and decapsulation. The > entities that perform the transformations need to be part of > the IPPT system and collect this information to prevent > packets from disappearing. Thus a host processing a HAO and > then reflecting e.g. a TCP SYN would need to be part of the > IPPT in order to be able to use IPPT to traceback through that > reflector. Of course, we don't do this for normal reflectors > but they are more predicable since they don't loose the IP > source address. > > In conclusion, the crux of the matter is the impact on ingress > filtering. The design team would be hesitant to "bid down" our > ingress filtering protection and settle for itrace, even if > trace was deployed now. It also seems unlikely that HAO > support can be built for other methods such as IPPT. The > design team recognizes that ingress filtering is not fully > deployed and probably never will be. Still, we feel that the > possibility to use ingress filtering in an effective manner > should be retained even in IPv6 networks. > > 1.3. PRACTICAL EFFECT > > The practical effect of the introduction of the HAO to the > Internet is that attackers can launch DoS attacks where the > victims have no practical ways to quickly disable the attack. > Even tracing of the attacker becomes hard; the tracing is > possible but can be slow and would require widespread > introduction of a technology which is just in its development > phase. Existing and future ingress filtering tools are > rendered largely useless, at least as far as protocol > responses are considered. > > Compared to some other existing DoS attacks, the HAO > reflection attack compares as follows: > > - This is a smaller problem than publicly open IP-in-IP > tunneling, since through HAO we can only run responses. > > - This is a bigger problem than regular source address > spoofing attacks, because they can be prevented with > ingress filtering (and are also detectable with current > itrace mechanisms). > > 1.4. FURTHER BACKGROUND INFORMATION > > Further background information on the security issues around > MIPv6's use of the Home Address Option can be found from > draft-savola-ipv6-rh-ha-security-01.txt, draft-dupont-ipv6- > ingress-filtering-00.txt, as well as in the mailing list > discussions. Reflection attacks in general are treated > extensively in > > http://www.aciri.org/vern/papers/reflectors.CCR.01 > > 2. ALTERNATIVES > =============== > > The alternative decisions we can arrive at are the following: > > (a) Decide that the threat is not significant. > (b) Apply infrastructure-based ingress filtering > (c) Apply infrastructure-less ingress filtering > (d) Allow HAOs only in conjunction of existing bindings (or > IPsec SAs) > (e) Additional information copied to the reflected packet > > 2.1. THREAT IS NOT SIGNIFICANT > > While the exact nature and seriousness of the threat may be > discussed, it seems that the "do no harm" principle is not > fulfilled. This is because the threat appears harder than the > one caused by regular source address spoofing. > > 2.2. INFRASTRUCTURE-BASED INGRESS FILTERING > > Intermediate routers and firewalls could be made more > intelligent in order to still be able to continue to perform > the ingress filtering task. The question is how? > > In infrastructure-based ingress filtering this is done this > with the help of a global infrastructure such as AAA. Upon > requesting access from a challenging router, a node > authenticates itself, the router uses the global > infrastructure to get the node's home organization to verify > the authentication. In doing so, the home network supplies > also a correct Home Address to the visited network. This > information is used to open a "hole" to the ingress filtering > system at the visited network. > > It may not be obvious why a global infrastructure is needed, > and to what extent. First, the global infrastructure is needed > in order for the authentication of the MN to be > verified. Otherwise, anybody could claim to be the rightful > owner of some legitimate Home Address somewhere else. Second, > both the visited and the home domains must be under the same > infrastructure. This implies a SOHO user could not get access > when he is visiting a big ISP, unless the SOHO user was also a > member of the roaming association of the ISPs. Obviously, the > SOHO user could be served by an ISP and perhaps the ISP > authentication procedures could be applied here. It turns out > that this isn't always possible. For instance, DSL providers > may rely on authentication procedures which require nodes to > be reachable at given fixed locations in their topology. This > would preclude authentication of any node or user away from > its usual location. Providers may also have no authentication > at all. With the advent of grass roots, self-organizing or > impromptu networking (typically using wireless LAN technology > to produce a patchwork of network connectivity), many users > will not be serviced by traditional ISP's. These users would > not be able to use such an infrastructure-based ingress > filtering. > > As a result, only a subset of all users in the world would be > able to use this improved ingress filtering. What would be > done with the others? It seems that where ingress filtering is > deployed, it would be necessary to prevent the use of MIPv6 > altogether for users who do not belong to the infrastructure. > This is because it may not be possible to differentiate between > the dangerous use of HAO and its safe use in conjunction with > Route Optimization (see 2.4). > > Ingress filtering should also be as deployable as it is IPv4, > which means multiple places as well as higher up in the > hierarchy than a single Access Router or local firewall. This > sets additional requirements on the challenging router can > authentication the user; it may not be under the same > administration as the Access Router that gave access to the > MN. > > The main benefit of this scheme is the level of control it > allows. The drawbacks include the introduction of a large > global infrastructure, the elimination of certain user groups > from being able to benefit from MIPv6, and the inability of > the global infrastructure to deal with e.g. RFC 3041 > addresses. > > 2.3. INFRASTRUCTURE-LESS INGRESS FILTERING > > A better way would be to come up with an ingress filtering > scheme that does not require a global infrastructure. We note > that such schemes appear to have to be based on similar > principles as the Route Optimization is based on. This is > because the infrastructure and the RR/CGA methods are the only > known ways to have some assurance of address ownership. While > rate limitation and other mechanisms can reduce the problems > associated with HAO reflection, they don't appear to be able > to solve them altogether. The hard problems in rate limiting > are determining what is reasonable rate a the location of the > limiter, and the attacker's ability to use a large number of > different reflectors. > > Without going to the detailed signaling involved in the use of > RR or CGA to prove address ownership to a challenging router, > the basic scheme is as follows: > > 1. Send a message to the CN > 2. The message is intercepted by the challenging router, and > an authentication request is sent to the MN > 3. MN uses an RR or CGA method to prove ownership to the AR, > just as if challenging router was a CN > 4. A filter is installed in the challenging router so that packets from > the MN can not get past that router. > 5. The MN retransmits the packet that the challenging router > dropped in Step 2. > > Benefits of this scheme include keeping the current ingress > filtering model but extending it to do more. Theoretically, > this scheme would also allow the elimination of the HAO from > packets altogether (by simply using the HoA as the source, and > expecting routers to challenge this if necessary), which would > reduce the size of the packets in MIPv6. > > The drawback of this scheme include the following. > > - Deployment: it expects increased network support, which may > delay introduction of MIPv6. > > - Scaling: Instead of having a single ingress filter rule per > prefix, the routers need to have per MN information to track > which HAO each MN can use. New DoS attacks are opened > against the routers because of this. > > - Delay: There is delay due to the router's challenge. > Multiple challenging routers in the path create additional > delay. There might also be potential DoS issues around bogus > challenges injected by random off-path nodes - the MN has no > idea what nodes are routers on the path. > > - Architectural: Should we select end-to-end or network > centric approaches? Generally the network centric approaches > do not scale as well as end-to-end mechanisms, and may be > deployed slower. > > 2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS > > If all CNs ensure first the validity of the Home Address claim > using e.g. RR techniques, HAOs can be accepted. The result of > this is that in order to send packets directly from a MN to a > CN the CN needs to have state about the MN. Thus in effect the > choices are either RO (packets in both direction take the > direct path between MN and CN) and bidirectional tunneling > (packets in both directions go through the HA). Thus it would > not be possible, without creating some authenticated state on > the CN, to send packets directly from the MN to the CN. > > The benefit of this scheme is its zero need for network > support, and its end-to-end nature. The main drawbacks are the > elimination of triangular routing, and the change in the > nature of the BCE state (discussed below in 2.4.1). > > A variation of this approach is that HAOs could additionally > be accepted also if there's an IPsec SA between the MN and the > CN. (In this case, however, the SA must be established using > traditional means such as local PKIs and newer research > results on self-signed certificates or opportunistic IPsec > would not suffice here.) > > 2.4.1. NATURE OF BCE STATE > > The nature of the BCE changes a bit if alternative 2.4 > is adopted. An expired BCE changes more than the routing > of the packets. In the current MIPv6 specifications, the > expiration forces the return packets to take the route > via the HA. But if alternative 2.4 is adopted, an expired > BCE causes any traffic with a HAO to be dropped upon > reception, causing packets to be blackholed until the > MN notices this condition. > > A few observations of the effects can be made: > > - The traffic does not get dropped if the MN and CN have the > same understanding of the length of the expiration period. > > - A CN that has to throw away BCE entries due to lack of > memory or some other reason might cause this. Perhaps one > could argue, though, that it would make more sense to > allocate a fixed size memory pool for Route Optimization, > making it possible for the CN to guarantee a BCE entry > lifetime and refuse new RO requests. However, this would > limit the ability of the CN to dynamically decide that a new > BCE entry is more important than an existing one, and to > throw away the existing before it has expired. > > - However, a CN that reboots can still cause this. The effect > is significant naturally only if the CN can get back to > operational status soon enough to even be able to drop > packets. (Note that RR protected BUs are expected to have > lifetimes of at most few minutes, which limits the duration > of the resulting condition.) > > In conclusion it is necessary to deal with the situation in > some manner. There are different ways of dealing with this but > the design team proposes the following scheme. > > A HAO with no matching BCE entry generates an ICMP error > message. The message is sent to the source of the packet, > i.e. the CoA. This guarantees that there will be no additional > reflection problems because of this. > > It may be possible for attackers to spoof these messages from > the path, or possibly also off-path (it isn't clear that > implementations are expected or even can check for TCP > sequence numbers inside the ICMP packet). This would have the > effect of forcing an unnecessary new RR exchange, or possibly > disabling RO altogether. Like all ICMP spoofing this requires > that the attackers can lie about their source addresses. > However, this attack does not appear to be any more severe > than MIPv6 offers in any case for RO. For instance, an a > spoofed ICMP Destination Unreachable would cause a CN to > revert back to using the HA path. > > 2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS > > In this alternative, a traceback of the attacker is performed > by having the CN include additional information in the > reflected packets. In particular, the CN could include the > claimed source address of the original packet in the response, > e.g. in the "OAH Destination Option". > > This approach is an easy one to provide within the MIPv6 > specifications. A disadvantage is that it helps mainly for > traceback, and does not help as much prevention -- for > instance the victim's ISP could not filter the attacker's > packets using IP source address, but would have to look at the > option. (Prevention may still be possible, but could require > additional functionality in e.g. routers and filtering > firewalls.) A larger drawback of this scheme is that there are > IPv6 socket API implications, at least for UDP applications, > in order to ensure that the response sent due to a request > containing a HAO always contains a OAH option. > > 3. DISCUSSION > ============= > > The design team feels that the a great danger for MIPv6 > deployment is that it is perceived as insecure. This is > particularly true after the widely known events that have > taken place in the IETF for MIPv6 since December 2000. Any > special conditions regarding what service providers need to > get in order to allow MIPv6 securely in their networks is > likely going to reduce the number of MIPv6 users. Therefore, > we feel that potential dangers in HAO should be considered. > > The design team does not feel IFB solutions are acceptable as > a condition for MIPv6's use. MIPv6 will have the largest user > base if it doesn't require additional infrastructure in the > visited locations or in the home networks. > > We'd also like the Internet to use end-to-end mechanisms > rather than network assistance, especially if there are > scalability concerns in the kind of assistance required. The > end-to-end principle isn't just an architectural rule, it will > also ensure that we can deploy our things without waiting for > providers to catch up. > > 4. RECOMMENDATION > ================= > > The design team notes that the resolution to this seemingly > small issue has major ramifications to the MIPv6 architecture. > It affects the topology of the routes the packets take; it has > a node vs. router functionality decision; it has an IFB > vs. IFL decision. > > The design team recommends alternative d to be applied (R1). > We expect MIPv6 deployment to be soonest and largest if we > choose d. > > The design team recognizes that moving non-RO traffic to > bidirectional tunneling has consequences. We do not believe > the technical consequences to delays etc. are significant. It > may be in fact be a cleaner approach to have a 2-level > solution and the RO deployment may grow because of > this. However, there are non-technical consequences. In > particular, the MIPv4 experience indicates that pure > bidirectional tunneling may result in leaving the Route > Optimization functionality behind in the standardization > process, and become less widely if at all implemented. Due to > these considerations, the design team additionally recommends > that (R2) MIPv6 bidir and RO parts be kept in the same RFC and > advanced at the same time, and (R3) RO should be required to > implement in all IPv6 nodes, as implied by RFC 1726. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:09:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16588 for ; Tue, 12 Feb 2002 11:09:42 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17823; Tue, 12 Feb 2002 09:09:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08934; Tue, 12 Feb 2002 08:09:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CG8fFh008728 for ; Tue, 12 Feb 2002 08:08:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CG8e75008727 for mobile-ip-dist; Tue, 12 Feb 2002 08:08:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CG8aFh008717 for ; Tue, 12 Feb 2002 08:08:37 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CG8aM12287; Tue, 12 Feb 2002 17:08:36 +0100 (MET) Date: Tue, 12 Feb 2002 17:04:26 +0100 (CET) From: Erik Nordmark Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > What are the IPR claims that have been made? What patents? What > yet-to-be-filed disclosures? In draft-roe-mobileip-updateauth-01.txt there is an Ericsson IPR notice. In Salt Lake City Christian Huitema stood up in the mobile-ip meeting and said something about Microsoft having IPR. That is all the information I have - I don't know if there are patents, or patent applications and whether any such applications have been published. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:17:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16875 for ; Tue, 12 Feb 2002 11:17:40 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09391; Tue, 12 Feb 2002 08:17:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10170; Tue, 12 Feb 2002 08:17:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGGRFh008797 for ; Tue, 12 Feb 2002 08:16:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CGGRrc008796 for mobile-ip-dist; Tue, 12 Feb 2002 08:16:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGGOFh008789 for ; Tue, 12 Feb 2002 08:16:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10040 for ; Tue, 12 Feb 2002 08:16:26 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22880 for ; Tue, 12 Feb 2002 09:16:26 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA24100 for ; Tue, 12 Feb 2002 09:16:25 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA14129 for ; Tue, 12 Feb 2002 09:05:04 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP; Tue, 12 Feb 2002 10:16:21 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 176562EC85; Tue, 12 Feb 2002 17:11:18 +0100 (CET) To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation References: <200202121451.g1CEpSg03619@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 12 Feb 2002 17:16:22 +0100 In-Reply-To: <200202121451.g1CEpSg03619@givry.rennes.enst-bretagne.fr> Message-Id: Lines: 28 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In your previous mail you wrote: > > What are the IPR claims that have been made? What patents? What > yet-to-be-filed disclosures? Francis Dupont writes: > => oh! What want details? The only concrete fact is Christian Huitema's > declaration at the last meeting (IPR stuff is sent to the IESG) IIRC, Christian's declaration was something rather vague (MAY). I did search public patent databases and it's difficult to me to identify relevant patents on CGA's. That's why I'm asking here. If the patents are not yet issued, or are being now filed, or anywhere on their way to show up in the public databases, it still means that they have only recently been authored and this might raise "novelty" controversies, since those things have been discussed long ago publicly. That's one of the reasons I don't fear that much the "CGA is patented" argument. Or someone please prove me wrong. > => I do *not* want to become a lawyer! Neither do I! Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:29:43 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17214 for ; Tue, 12 Feb 2002 11:29:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12524; Tue, 12 Feb 2002 08:29:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12902; Tue, 12 Feb 2002 08:29:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGSMFh009032 for ; Tue, 12 Feb 2002 08:28:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CGSMx8009031 for mobile-ip-dist; Tue, 12 Feb 2002 08:28:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGSIFh009024 for ; Tue, 12 Feb 2002 08:28:19 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CGSIM15139; Tue, 12 Feb 2002 17:28:18 +0100 (MET) Date: Tue, 12 Feb 2002 17:24:09 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] BU Authorization method: design team recommendation To: Basavaraj.Patil@nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <697DAA22C5004B4596E033803A7CEF44A126A5@daebe007.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >Yes, but I suspect an attacker on the CN's link is a common high-level > >threat today with 802.11 and other multi-access links. (Using spoofed > >router advertisements or neighbor advertisements, if the L2 can't be > >spoofed, in order to see all packets.) > > > > But solving the security problems of 802.11 or other multi-access > links is not ncecessarily Mobile IP WGs problem. > I believe we need to avoid digressing into solving problems outside > the scope of MIPv6 (and IMO securing 802.11 or other multi-access > links is not within the scope of finding a solution for securing MIPv6 > BUs) Raj, I certainly didn't mean to imply that I think MIPv6 needs to solve problems are security issues for multi-access links. I does not as far as I am concerned. I was merely responding to Vijay's statement that doing things a particular way handled threats except e.g. an attacker on the CN's link by pointing out that in reality that link might be a prime place for attackers to do their dirty work. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:33:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17394 for ; Tue, 12 Feb 2002 11:33:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02053; Tue, 12 Feb 2002 09:33:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13810; Tue, 12 Feb 2002 08:33:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGWdFh009067 for ; Tue, 12 Feb 2002 08:32:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CGWdoX009066 for mobile-ip-dist; Tue, 12 Feb 2002 08:32:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGWaFh009059 for ; Tue, 12 Feb 2002 08:32:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06729 for ; Tue, 12 Feb 2002 08:32:38 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01587 for ; Tue, 12 Feb 2002 09:32:38 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1CGWYE22847; Tue, 12 Feb 2002 08:32:34 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW33751; Tue, 12 Feb 2002 08:32:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA26897; Tue, 12 Feb 2002 08:32:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.17313.478396.696440@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 08:32:33 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Francis Dupont , Erik Nordmark , Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: References: <200202120905.g1C95Eg01845@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > => I've tried this (with AH which is a bit easier than ESP as discussed > > in a zillion of messages in lists). It works but it is terribly heavy > > and slow: IKE configuration is a nightmare, certificates are lost > > in first exchanges because of the path MTU discovery and UDP transport, > > IKE does *not* like message lost, etc. It takes many seconds to get the > > SA pair when the MN boots in visit. In fact the only good point is > > this works and was tested between independent implementations. > > This is why I work on AAA based solutions as an alternative (AAA is > > far better but is not a candidate for a general solution). > > BTW IKE is available on very small boxes, Palm Pilots and Psions > > for instance. > > Would AAA be better because diameter runs over SCTP instead of IKE > over UDP? > Others have claimed in the past that you don't want to run diameter on > the client due to size? performance? concerns. Just as a note, IPsec != IKE. You could use KINK instead and all of Francis' criticisms go away. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:42:19 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17799 for ; Tue, 12 Feb 2002 11:42:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15407; Tue, 12 Feb 2002 08:42:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15558; Tue, 12 Feb 2002 08:41:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGf2Fh009140 for ; Tue, 12 Feb 2002 08:41:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CGf2NM009139 for mobile-ip-dist; Tue, 12 Feb 2002 08:41:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGewFh009132 for ; Tue, 12 Feb 2002 08:40:58 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1CGewM16964; Tue, 12 Feb 2002 17:40:58 +0100 (MET) Date: Tue, 12 Feb 2002 17:36:48 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <076001c1b348$adad0860$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > One comment: in the discussion there seemed to > be some confusion about the "bit method" of > reserving an address class for addresses that > are not secured via RR. I assume that what > is meant here is exactly that, and that the > bit combination to be specified will not > be used to specify that CGAs must be used > but some future, to-be-decided IP signaling security > protocol which *might* be CGAs. > > Is that correct? If we go the path of the bit method the idea would be that RR-protected BUs would not be accepted when the bit is set in the peer's HoA. If we can come up with other schemes that can be expressed as a property of the interface ID in the HoA then, as Jari pointed out with including additional information in the hash/prf/mac the actual details of the property and the protocol/algorithms used for securing things could be expressed securely. > Also, I support the idea (which came up in the discussion), > of having the BU security RFC be separate from the > base MIPv6 RFC. This is more modular, and will > simplify introducing a more powerful IP signaling > security technology like CGAs when the IETF gets around > to specifying it. But having a common specification for MIPv6 which includes route optimization probably will increase the rate at which correspondent nodes will implement route optimization. So there are pros and cons here. In any case, it should be possible to specify new methods as separate specifications. The IETF does that all the time. > Also, though the design team hasn't yet specified exactly which method > will be used for securing BUs, I have a difficult time > seeing RR as a widely applicable method. So I would > oppose having a separate RFC at this time strictly > for BU security using CGAs. Why don't you think RR will be widely applicable? Too many packets? > > 3. Regarding issue (i), the design team recommends that the RR > > method should not use a BSA since we already recommend both > > HoA and CoA RR tests to be performed every time a binding is > > refreshed or updated with RR. > > AGREE, with the proviso that if an IPSEC SA already exists, > it should be possible to use it. Clarifying question: do you mean that if an IPsec SA exists carrying the BU over that SA should be sufficient and no RR other BU specific protocol is needed? Or do you mean that the IPsec SA should be used in addition to the RR checks? The former interpretation has authorization problems. Just because the CN has an IPsec SA with a peer that has a certificate mbox=erik.nordmark@sun.com doesn't say anything what HoA's the peer can issue BUs for. > CLARIFICATION > > I can't claim to have examined this in detail, > but this seems like an aweful lot of signaling > potentially going over the Internet, and > runs the risk of congestion > control dropping the packets. > What about the transport protocol? UDP is clearly at risk. > UDP with some reliability mechanism? TCP? > SCTP? This looks like an aweful lot of signaling, > every one of these is an opportunity for something > to go wrong. If either 1a or 1b is dropped, then > recovery may take a long time. Since this is a single-shot (transmit one packet - is no reply retransmit) application using a protocol which performs better under streaming conditions (large amounts of data to transmit) doesn't seem to buy anything. It might make sense to do RTT estimation so that when a binding is refreshed it can use a reasonable RTT estimate based on how quickly the response arrived for previous BU exchanges. > In any event, this is going to slow down MIP > handover by orders of magnitude. A scalable > LMM solution becomes even more critical. Agreed. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:53:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18238 for ; Tue, 12 Feb 2002 11:53:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12608; Tue, 12 Feb 2002 09:53:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18155; Tue, 12 Feb 2002 08:53:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGqVFh009188 for ; Tue, 12 Feb 2002 08:52:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CGqVLM009187 for mobile-ip-dist; Tue, 12 Feb 2002 08:52:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGqRFh009180 for ; Tue, 12 Feb 2002 08:52:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13157 for ; Tue, 12 Feb 2002 08:52:30 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17977 for ; Tue, 12 Feb 2002 09:52:29 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CGqLa32085; Tue, 12 Feb 2002 17:52:21 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA07179; Tue, 12 Feb 2002 17:52:21 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CGqKg04522; Tue, 12 Feb 2002 17:52:20 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121652.g1CGqKg04522@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Tue, 12 Feb 2002 16:14:06 +0100. Date: Tue, 12 Feb 2002 17:52:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Which is very different that the traditional model of > MN -> AAAl -> AAAh and a reply AAAh -> AAAl -> MN > > => this is the model I am working on (MN-AAAl-AAAh-HA). By "this" you couldn't mean the same as mine above, because they are very different. In mine the path stops at AAAh and in yours the HA is the end. => to return a credential (your model?) or to use AAA for the transport (my model) is a matter of taste, I don't believe we have very different opinions. Thus yours is the same as the yet-to-be-standardized diameter-mobileip model, which I think is less than ideal. => I like the diameter-mobileip model but I don't like aggressive modes, i.e. not transport of the BU, not key distribution, etc. Look at draft-dupont-mipv6-aaa-01.txt ... Some while your idea is different than involving the CN as in draft-le-mobileip-dh-01.txt it still doesn't match the traditional architecture for AAA as implemented by Radius today. => I explicitely rely on the existence of an AAA infrastructure which is not implemented today. But same for your model - the AAAh needs to contact the HA. => yes, in my model the HA is an AAA agent. In that case do you see a need for AAAh to invoke the HA? => if you don't do that, you need another exchange. Basically you can do three things: - get only the credential from AAAh (three RTT, MN<->AAAh for the credential, MN<->HA for the SA establishment, MN<->HA for BU/BA). - simple piggy-backing (two RTT, MN<->HA for the SA establishment, MN<->HA for BU/BA) - aggressive (one RTT, MN<->HA for BU/BA) I don't like the last one because I don't trust AAA servers for everything: they are good for network access control (i.e. authentication and authorization of addresses, same than for CGAs but for whole addresses) and transport. With a piggy-backed Diffie-Hellman exchange between the MN and the HA nothing more is needed). > => at least to get a open door in the BU stuff? Do you see a closed door anywhere? => BU authentication == RR [+ CGA] I don't. The protocol would need to get worked out, and follow the normal standards track criteria. (clear, useful, etc) => but the form of the current BU authentication recommendation is closed, for instance I am very surprised we are not flooded by messages about "I already have a good IPsec SA, how can I protect the BU with it"... (there should be a flu epidemic in the Silicon Valley, or we have bored them to near death :-) Would AAA be better because diameter runs over SCTP instead of IKE over UDP? => this is a joke, isn't it? But I believe you are right. Some stupid problems with IKE come from the use of UDP... Others have claimed in the past that you don't want to run diameter on the client due to size? performance? concerns. => argh! I agree the model should be more accurate: there is an AAA attendant between the MN and the AAA local server. Diameter is not run between the MN and the attendant (read my draft :-), only between AAA agents. (PS: for the question I expect you'll ask: I don't know yet, read... :-) About the real topic of this discussion: what is scheduled in the future document about alternative BU authentications, including all the known infrastructure based and/or for home registrations? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 11:59:36 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18424 for ; Tue, 12 Feb 2002 11:59:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20159; Tue, 12 Feb 2002 08:59:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19777; Tue, 12 Feb 2002 08:59:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGwRFh009249 for ; Tue, 12 Feb 2002 08:58:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CGwRs2009248 for mobile-ip-dist; Tue, 12 Feb 2002 08:58:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CGwOFh009241 for ; Tue, 12 Feb 2002 08:58:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19662 for ; Tue, 12 Feb 2002 08:58:27 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15194 for ; Tue, 12 Feb 2002 09:58:26 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id <1L6R3C3W>; Tue, 12 Feb 2002 11:52:08 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 12 Feb 2002 11:52:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello folks, We need to get closure on the Working Group's stance on piggybacking of binding update messages. Much of the discussion last year was around the issue that doing so generally meant that IPsec specifications and implementations needed some modifications in order to protect BU messages that were piggybacked in other messages. Other discussions were around the relative merits of piggybacking in terms of performance of particular kinds of link layers, whether beneficial or harmful. Still other discussions were around the complexity of implementing it in the receiver. This note is an attempt to summarize the pros and cons of the various approaches and to give a design team recommendation. The summary is more difficult because there was little agreement in the earlier discussions on whether the asserted benefits were real. In fact, it doesn't seem there was agreement on ANY of the asserted pros and cons below, except that it would be difficult to add the function later. Jari documented the tradeoffs of using piggybacking with IPSEC well in: http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt In Salt Lake City a set of options was put before the working group. The option to leave piggybacking in the draft without comment on its merits was favored by no one. The other options were as listed below. I would like you to comment on each whether you AGREE, DISAGREE, or CAN LIVE WITH the option. 1. Specify that piggybacking of binding update messages not be used with MIP v6. Pros: - puts no constraints on using IPSEC to protect binding updates when possible Cons: - if the function is added later, some negotiation would be needed between the sender and receiver since all receivers would not be able to support it 2. Specify that piggybacking always be an option. Pros: - allows some improvement in terms of throughput and latency that may be relevant on certain types of links Cons: - the improvements are only relevant on certain types of links and thus this is inclusion of functionality at layer 3 that is useful only for certain layer 2s - in cases where the functionality is detrimental on certain kinds of links, the receiver may be victimized when sent a piggybacked BU - need policy extensions to IPSEC (and corresponding implementation modifications) for those cases in which IPSEC is used to protect BUs. 3. Specify that piggybacking is an option, but subject to negotiation between the two communicating nodes. Pros: - may be able to eliminate the detrimental effects on stations on certain kinds of links Cons: - requires some more specification of signalling on whether or not to use piggybacking and additional behavior in the mobile node The DT has come to the following conclusions: (a) For reasons of timing, we do not recommend extending IPsec specifications in any manner. Therefore, we feel that approaches that rely on better IPsec policy granularity should not be considered. (b) We recommend that when IPsec protection is used, it is always used in *addition* to RR (or CGA) methods, not as a replacement. Thus RR (or CGA) methods would be used to protect MN - CN Route optimization procedures even when IPsec is used. (c) Binding update messages for both HAs and CNs, binding acks, RR messaging, and CGA messaging are to be implemented as a new message set without the ability to piggyback data packets on those messages The basis on this recommendation is as follows: - The DT recognizes the potential benefits of piggybacking. (However, link layer techniques may exist to migitate the disadvantages of sending separate packets, to some extent.) - MIPv6 control packets are needed between MN - HA, MN - CN, and CN - HA - MN. There is no piggybacking policy granularity problem in the MN - CN case, due to recommendation (b). However, if piggybacking is used for the MN - HA case either IPsec specifications would have to be extended, or mechanisms similar to those introduced in draft 14 would have to be employed. - The deciding factor, however, seems to be the protection we need for RR (or to a smaller extent CGA) messages on the CN - HA - MN path. Given that the HA is acting only as a router in this case, it can not insert DOs in the RR packets since that violates fundamental assumptions needed e.g. for Path MTU discovery, and draft 14 mechanisms wouldn't be able to provide the necessary encryption anyway. Therefore, it seems necessary to provide ESP-like functionality in any case for the MNs and HAs. Based on this, it would make sense to use the same mechanism also for BU protection. - It seems very useful to be able to use IPsec ESP (with manual keying) for protecting the RR control packets on the HA-MN path. If the IPsec selectors can't be used to distinguish those packets from data traffic the effect might be that lots of data packets (all that are tunneled through the HA) also become encrypted which would be a source of performance concerns for limited MN devices. - Some BU authorization mechanisms, namely those based on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 12:13:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18927 for ; Tue, 12 Feb 2002 12:13:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23875; Tue, 12 Feb 2002 10:12:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23398; Tue, 12 Feb 2002 09:12:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHBbFh009313 for ; Tue, 12 Feb 2002 09:11:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CHBb5V009312 for mobile-ip-dist; Tue, 12 Feb 2002 09:11:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHBYFh009305 for ; Tue, 12 Feb 2002 09:11:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19659 for ; Tue, 12 Feb 2002 09:11:37 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21334 for ; Tue, 12 Feb 2002 10:11:36 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1CHBZB22779 for ; Tue, 12 Feb 2002 18:11:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Feb 12 18:11:27 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 18:02:08 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A9EE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 12 Feb 2002 18:11:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Phil, AGREE with the conclusion, DISAGREE with some of the earlier analysis but since I agree with the conclusion there is no point in getting into the analysis :) Hesham > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Tuesday, February 12, 2002 5:52 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Piggybacking - DT recommendation > > > > Hello folks, > > We need to get closure on the Working Group's stance on > piggybacking of binding update messages. Much of the > discussion last year was around the issue that doing so > generally meant that IPsec specifications and implementations > needed some modifications in order to protect BU messages that > were piggybacked in other messages. Other discussions were > around the relative merits of piggybacking in terms of > performance of particular kinds of link layers, whether > beneficial or harmful. Still other discussions were around > the complexity of implementing it in the receiver. > > This note is an attempt to summarize the pros and cons > of the various approaches and to give a design team > recommendation. The summary is more difficult because > there was little agreement in the earlier discussions on > whether the asserted benefits were real. In fact, it > doesn't seem there was agreement on ANY of the asserted > pros and cons below, except that it would be difficult to > add the function later. > > Jari documented the tradeoffs of using piggybacking > with IPSEC well in: > > http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu- > security-01.txt > > In Salt Lake City a set of options was put before the > working group. The option to leave piggybacking in the > draft without comment on its merits was favored by no one. > The other options were as listed below. > > I would like you to comment on each whether you AGREE, > DISAGREE, or CAN LIVE WITH the option. > > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. > > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible > Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > > 2. Specify that piggybacking always be an option. > > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > > Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links > Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node > > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > > (c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. > > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. > > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. > > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. > > > Phil > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 12:18:53 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19085 for ; Tue, 12 Feb 2002 12:18:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25219; Tue, 12 Feb 2002 10:18:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24939; Tue, 12 Feb 2002 09:18:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHHoFh009401 for ; Tue, 12 Feb 2002 09:17:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CHHole009400 for mobile-ip-dist; Tue, 12 Feb 2002 09:17:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHHkFh009393 for ; Tue, 12 Feb 2002 09:17:46 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23606 for ; Tue, 12 Feb 2002 09:17:50 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06690 for ; Tue, 12 Feb 2002 09:17:48 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1CHHlB24713 for ; Tue, 12 Feb 2002 18:17:47 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Feb 12 18:17:12 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 18:08:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A9EF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Francis Dupont Subject: RE: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 12 Feb 2002 18:17:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In your previous mail you wrote: > > > > What are the IPR claims that have been made? What > patents? What > > yet-to-be-filed disclosures? > > Francis Dupont writes: > > => oh! What want details? The only concrete fact is > Christian Huitema's > > declaration at the last meeting (IPR stuff is sent to the IESG) > > IIRC, Christian's declaration was something rather vague (MAY). > > I did search public patent databases and it's difficult to me to > identify relevant patents on CGA's. That's why I'm asking here. > > If the patents are not yet issued, or are being now filed, > or anywhere > on their way to show up in the public databases, it still means that > they have only recently been authored and this might raise "novelty" > controversies, since those things have been discussed long ago > publicly. > > That's one of the reasons I don't fear that much the "CGA > is patented" > argument. Or someone please prove me wrong. Alex, There is usually not much gain in doing these searches or trying to get companies to say what *exacty* they filed patents for. The statement you refer to above is vague because it is *meant* to avoid being precise :) lawyers ! So we just have to take it at face value. Incidentally, I don't think that we should always assume that proposals with IPR notices in them are the *only* ones with IPR. Of course, it is no secret that many companies have IPRs on MIP related issues. This is not an argument to push for any particular solution _in_any_way, just a clarification. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 12:30:00 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19414 for ; Tue, 12 Feb 2002 12:30:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28873; Tue, 12 Feb 2002 09:29:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28093; Tue, 12 Feb 2002 09:29:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHSiFh009534 for ; Tue, 12 Feb 2002 09:28:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CHSiR2009533 for mobile-ip-dist; Tue, 12 Feb 2002 09:28:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHSfFh009526 for ; Tue, 12 Feb 2002 09:28:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26839 for ; Tue, 12 Feb 2002 09:28:44 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA03290 for ; Tue, 12 Feb 2002 10:28:41 -0700 (MST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M419GTX>; Tue, 12 Feb 2002 18:28:24 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M4A4MM1; Tue, 12 Feb 2002 18:28:22 +0100 From: "Jean-Michel COMBES" To: Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 12 Feb 2002 18:28:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, - conclusion (a) AGREE - conclusion (b) DISAGREE : why do we need to add an other type of security (eg. RR, CGA) when IPsec (which is a stronger security) is used ? - conclusion (c) CAN LIVE WITH Comments are welcome (especially concerning conclusion (b) :-) Regards France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 [snip] > > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > > (c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. > > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. > > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. > > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. > > > Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 12:34:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19575 for ; Tue, 12 Feb 2002 12:34:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06696; Tue, 12 Feb 2002 10:34:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29062; Tue, 12 Feb 2002 09:34:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHXLFh009572 for ; Tue, 12 Feb 2002 09:33:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CHXLGV009571 for mobile-ip-dist; Tue, 12 Feb 2002 09:33:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CHXIFh009564 for ; Tue, 12 Feb 2002 09:33:18 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28083 for ; Tue, 12 Feb 2002 09:33:21 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13868 for ; Tue, 12 Feb 2002 09:33:20 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA12701 for ; Tue, 12 Feb 2002 10:33:19 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA27050 for ; Tue, 12 Feb 2002 10:33:19 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Tue, 12 Feb 2002 11:33:13 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 902B02EC84; Tue, 12 Feb 2002 18:28:11 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Francis Dupont , hesham.soliman@era.ericsson.se Subject: [mobile-ip] Re: things and such (Was: BU Authorization method: design team recommendation) References: <4DA6EA82906FD511BE2F00508BCF053802C6A9EF@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 12 Feb 2002 18:33:15 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A9EF@Esealnt861.al.sw.ericsson.se> Message-Id: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, "Hesham Soliman (ERA)" writes: > There is usually not much gain in doing these searches or trying to > get companies to say what *exacty* they filed patents for. Right; and far from me any intention to push anyone to get any specific replies back. I did the searches as part of my usual current technical activities, and not in order to question their presence or absence. I will refrain from following up on this. Thanks for your remark. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 13:04:58 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20383 for ; Tue, 12 Feb 2002 13:04:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07898; Tue, 12 Feb 2002 10:04:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07887; Tue, 12 Feb 2002 10:04:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CI34Fh009882 for ; Tue, 12 Feb 2002 10:03:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CI34Gg009881 for mobile-ip-dist; Tue, 12 Feb 2002 10:03:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CI30Fh009874 for ; Tue, 12 Feb 2002 10:03:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09450 for ; Tue, 12 Feb 2002 10:03:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21866 for ; Tue, 12 Feb 2002 11:03:03 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA13786; Tue, 12 Feb 2002 10:03:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CI33K31700; Tue, 12 Feb 2002 10:03:03 -0800 X-mProtect:  Tue, 12 Feb 2002 10:03:03 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNhgfpH; Tue, 12 Feb 2002 10:03:01 PST Message-ID: <3C6958D5.4A5240C9@iprg.nokia.com> Date: Tue, 12 Feb 2002 10:03:01 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Erik, Erik Nordmark wrote: > > Vijay, > > > Nonce N1 and selector go in one message. Nonce N2 and the hash > > (N1 + N2 + selector) goes in another message. An attacker cant > > see both these messages unless he is on the CN's link or the MN's > > link. Please, for a moment, see this mechanism as a generic > > mechanism to select any BU authorization methods based on RR. > > Yes, but I suspect an attacker on the CN's link is a common high-level > threat today with 802.11 and other multi-access links. (Using spoofed > router advertisements or neighbor advertisements, if the L2 can't be > spoofed, in order to see all packets.) There are mainly two kinds of CNs. Web servers and Mobile nodes. We can safely rule out an attacker on a Web Server's link. MIPv6 is not your biggest concern in this case. In the case of the mobile nodes being CNS, any session initiated would through their home address (through their Home Agent). If the tunnel between the CN (a mobile node) and its home agent is protected then we can rule out the attacker in this case too. Lastly there are fixed CNs. that means somebody hacking into the network on which there are fixed CNs. Again MIPv6 is not your biggest concern here. So, lets not worry about the attacker being on the CN's link and able to see both messages (1a and 1b). IMO, this is a resonable assumption to make. Vijay > > > > You are assuming that the MN will immediately setup RO. > > > When sending e.g. queries to a DNS server (a single request response) it > > > might not make sense to setup RO before the exchange. > > > What if the DNS servers (the resolvers) that the MN is configured to > > > use have bogus BCEs for the MN? > > > > I could also argue, that a mobile node does not have to use > > the home address option for a DNS query. It could send a > > normal packet with the source address being CoA. this was > > always an option in the mobile node. > > I don't think my arguement assumed that CoAs couldn't be used for > such short-lived connections. If I made that implicit assumption please > point it out to me. > > In general the tradeoffs whether to use a CoA for short lived communication > vs. the HoA depends on lots of factors like predicting the length > of communication and the likely time of the next move. > There are likely to be cases where using a HoA makes sense due to unknown > in the above time factors even though the number of packets exchanged might not > be sufficient to warrant a RO. > > > You are actually basing your argument on the assumption > > that the attacker could somehow figure out that a particular > > mobile node is about to set up a very short lived session > > with a particular correspondent node. And the attacker gets > > "into position" (basically figure out the route that packets > > will take) to launch the RR attack. > > No. The session doesn't have to be short lived. > It is the fact that I don't think we should assume that all sessions > immediately go to RO (due to short-lived or few-packet sessions existing) > that makes the attack possible. > > If the CN can't know when a new session has started and for how long during > the start of a new session it should ignore RR-protected BUs (because > the MN might want to use a CGA-protected BU) then the attack is possible. > And hardcoding the policy for what is a "new session" and "how long" > wouldn't be good for interoperability. > > Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 13:05:43 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20422 for ; Tue, 12 Feb 2002 13:05:42 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08133; Tue, 12 Feb 2002 10:05:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08155; Tue, 12 Feb 2002 10:05:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CI3lFh009895 for ; Tue, 12 Feb 2002 10:03:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CI3lLq009894 for mobile-ip-dist; Tue, 12 Feb 2002 10:03:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CI3hFh009887 for ; Tue, 12 Feb 2002 10:03:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09714 for ; Tue, 12 Feb 2002 10:03:46 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28550 for ; Tue, 12 Feb 2002 10:03:44 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CI2sa08142; Tue, 12 Feb 2002 19:02:54 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA09141; Tue, 12 Feb 2002 19:02:54 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CI2rg04935; Tue, 12 Feb 2002 19:02:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121802.g1CI2rg04935@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Tue, 12 Feb 2002 08:32:33 PST. <15465.17313.478396.696440@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 19:02:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Just as a note, IPsec != IKE. => I agree but IKE is the only generally available key exchange protocol for IPsec. You could use KINK instead => KINK is fine even not generally available: I looked at KINK when I developed the first version of my AAA-based stuff but today I prefer to use HIP as the model (granularity of HIP is more suitable for the context of Mobile IPv6). and all of Francis' criticisms go away. => note they are facts (the fact it was painful and slow, and the fact it worked). Regards Francis.Dupont@enst-bretagne.fr PS: for this usage the best IPsec stuff is SKIP (BTW I can't find a RFC with the SKIP specs) but it is not enough available. (SKIP was proposed by Jim Bound in a private discussion) From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 13:17:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20928 for ; Tue, 12 Feb 2002 13:17:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10955; Tue, 12 Feb 2002 10:16:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10826; Tue, 12 Feb 2002 10:16:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CIEiFh010039 for ; Tue, 12 Feb 2002 10:14:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CIEiAI010038 for mobile-ip-dist; Tue, 12 Feb 2002 10:14:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CIEfFh010028 for ; Tue, 12 Feb 2002 10:14:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11386 for ; Tue, 12 Feb 2002 10:14:44 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28326 for ; Tue, 12 Feb 2002 11:14:44 -0700 (MST) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1CIEfe04873; Tue, 12 Feb 2002 10:14:41 -0800 (PST) Message-ID: <007d01c1b3f0$ebdd33f0$4c6015ac@T23KEMPF> From: "James Kempf" To: , "Alexandru Petrescu" Cc: , "Erik Nordmark" References: Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 12 Feb 2002 10:13:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The public patent databases only have filed patents starting in January 2000 and granted patents back until 1996. I found a filed patent involving a CGA-like scheme from Ericsson but I could not find the Microsoft patent, so I think it was probably filed before January 2000. There is a patent database that one can search, http://www.delphion.com, for a minimum $75/month fee, but I have not yet had the time to do the search. jak ----- Original Message ----- From: "Erik Nordmark" To: "Alexandru Petrescu" Cc: ; "Erik Nordmark" Sent: Tuesday, February 12, 2002 8:04 AM Subject: Re: (CONCLUSION) Re: [mobile-ip] BU Authorization method: design team recommendation > > What are the IPR claims that have been made? What patents? What > > yet-to-be-filed disclosures? > > In draft-roe-mobileip-updateauth-01.txt there is an Ericsson IPR notice. > > In Salt Lake City Christian Huitema stood up in the mobile-ip meeting > and said something about Microsoft having IPR. > > That is all the information I have - I don't know if there are patents, > or patent applications and whether any such applications have been published. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 13:28:00 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21258 for ; Tue, 12 Feb 2002 13:27:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13664; Tue, 12 Feb 2002 10:27:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13244; Tue, 12 Feb 2002 10:27:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CIQJFh010099 for ; Tue, 12 Feb 2002 10:26:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CIQJSS010098 for mobile-ip-dist; Tue, 12 Feb 2002 10:26:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CIQGFh010091 for ; Tue, 12 Feb 2002 10:26:16 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14884 for ; Tue, 12 Feb 2002 10:26:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09962 for ; Tue, 12 Feb 2002 10:26:17 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CIQEa09940; Tue, 12 Feb 2002 19:26:14 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA09750; Tue, 12 Feb 2002 19:26:15 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CIQFg05055; Tue, 12 Feb 2002 19:26:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202121826.g1CIQFg05055@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: kempf@docomolabs-usa.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Tue, 12 Feb 2002 17:36:48 +0100. Date: Tue, 12 Feb 2002 19:26:15 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > > 3. Regarding issue (i), the design team recommends that the RR > > method should not use a BSA since we already recommend both > > HoA and CoA RR tests to be performed every time a binding is > > refreshed or updated with RR. > > AGREE, with the proviso that if an IPSEC SA already exists, > it should be possible to use it. Clarifying question: do you mean that if an IPsec SA exists carrying the BU over that SA should be sufficient and no RR other BU specific protocol is needed? => ah!ah! Good attempt but James' question is "that SA *could* be sufficient...". Or do you mean that the IPsec SA should be used in addition to the RR checks? => RR uses more than one address and IPsec SAs have some issue with multiple address (cf. SA lookup using *the* destination address in inbound processing, RFC 2401 5.2.1). The former interpretation has authorization problems. => so if an IPsec SA already exists with the proper policy? Just because the CN has an IPsec SA with a peer that has a certificate mbox=erik.nordmark@sun.com doesn't say anything what HoA's the peer may issue BUs for. => this is a policy issue (IPsec knows what is a policy but details, including how to use policies, are not in the IPsec WG scope). And the policy can be encoded in the certificate: your point is the certificate is not always enough (I parse your statement as "is never enough"). Since this is a single-shot... => I still have to read the Home Address Option recommendation to see if Binding Acknowledgements (BAs) are now mandatory but at least some new error codes are to be added in BAs for fast recovery (something like "I don't receive the message Xy"). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 13:31:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21383 for ; Tue, 12 Feb 2002 13:31:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03708; Tue, 12 Feb 2002 11:30:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14457; Tue, 12 Feb 2002 10:30:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CITPFh010146 for ; Tue, 12 Feb 2002 10:29:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CITOT4010145 for mobile-ip-dist; Tue, 12 Feb 2002 10:29:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CITLFh010138 for ; Tue, 12 Feb 2002 10:29:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13997 for ; Tue, 12 Feb 2002 10:29:23 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03120 for ; Tue, 12 Feb 2002 11:29:22 -0700 (MST) Received: from T23KEMPF (dhcp76.docomolabs-usa.com [172.21.96.76]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1CITIe05660; Tue, 12 Feb 2002 10:29:18 -0800 (PST) Message-ID: <008f01c1b3f2$f658b230$4c6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 12 Feb 2002 10:27:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > If we go the path of the bit method the idea would be that RR-protected > BUs would not be accepted when the bit is set in the peer's HoA. > > If we can come up with other schemes that can be expressed as a > property of the interface ID in the HoA then, as Jari pointed out > with including additional information in the hash/prf/mac > the actual details of the property and the protocol/algorithms used > for securing things could be expressed securely. > Since the question of whether to accept the BU is restricted to the BU itself, what's the problem with putting some kind of indication in the BU about which method should be used? > But having a common specification for MIPv6 which includes route optimization > probably will increase the rate at which correspondent nodes will > implement route optimization. > So there are pros and cons here. > > In any case, it should be possible to specify new methods as separate > specifications. The IETF does that all the time. > I think having route optimization in the base spec is fine, I was just talking about the security method, if that can be separated. It probably would have been better to separate out route optimization a year ago when this controversy arose, but now it is too late. And, I agree that having it in the base spec will probably speed adoption. The base spec just needs to be written modularly. > > > Also, though the design team hasn't yet specified exactly which method > > will be used for securing BUs, I have a difficult time > > seeing RR as a widely applicable method. So I would > > oppose having a separate RFC at this time strictly > > for BU security using CGAs. > > Why don't you think RR will be widely applicable? Too many packets? > By "widely applicable" I mean beyond Mobile IP. I think RR probably will see some use in Mobile IP, but it is not entirely clear that it will be widely deployed. As you say, the amount of signaling involved is onerous, I suspect this will be a damper on use, especially over the Internet. And, more seriously, I fear that it may lead to serous pressure for quick standardization of "routing proxy" style LMM solutions when people start realizing how expensive secured BUs are. > Clarifying question: do you mean that if an IPsec SA exists > carrying the BU over that SA should be sufficient and no RR other BU > specific protocol is needed? > Or do you mean that the IPsec SA should be used in addition to the RR > checks? > > The former interpretation has authorization problems. > Just because the CN has an IPsec SA with a peer that has a certificate > mbox=erik.nordmark@sun.com doesn't say anything what HoA's the peer > can issue BUs for. > Good point. Since the IPsec SA adds nothing, perhaps it is unnecessary. > Since this is a single-shot (transmit one packet - is no reply retransmit) > application using a protocol which performs better under streaming conditions > (large amounts of data to transmit) doesn't seem to buy anything. > It might make sense to do RTT estimation so that when a binding is refreshed > it can use a reasonable RTT estimate based on how quickly the response arrived > for previous BU exchanges. > Sure, but it still doesn't solve the problem of what happens when congestion causes a router to drop a packet, particularly 1a and 1b. This could make BUs very expensive in terms of time. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:18:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22700 for ; Tue, 12 Feb 2002 14:18:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00842; Tue, 12 Feb 2002 12:18:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29938; Tue, 12 Feb 2002 11:18:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJGtFh010293 for ; Tue, 12 Feb 2002 11:16:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJGt9m010292 for mobile-ip-dist; Tue, 12 Feb 2002 11:16:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJGqFh010285 for ; Tue, 12 Feb 2002 11:16:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02300 for ; Tue, 12 Feb 2002 11:16:54 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29845 for ; Tue, 12 Feb 2002 12:16:53 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA19836 for ; Tue, 12 Feb 2002 11:16:50 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CJGjv27473 for ; Tue, 12 Feb 2002 11:16:45 -0800 X-mProtect:  Tue, 12 Feb 2002 11:16:45 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGxWybS; Tue, 12 Feb 2002 11:16:43 PST Message-ID: <3C696A1C.7401E58E@iprg.nokia.com> Date: Tue, 12 Feb 2002 11:16:44 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I have a lot of comments on the piggybacking recommendation. Phil Roberts wrote: > This note is an attempt to summarize the pros and cons > of the various approaches and to give a design team > recommendation. The summary is more difficult because > there was little agreement in the earlier discussions on > whether the asserted benefits were real. In fact, it > doesn't seem there was agreement on ANY of the asserted > pros and cons below, except that it would be difficult to > add the function later. That is a very important point. Regarding the "asserted" benefits, I think it can be shown that piggybacking _always_ offers performance benefits to a compliant IPv6 implementation, and that sometimes the benefits would enable important applications (like voice) to work better. > In Salt Lake City a set of options was put before the > working group. The option to leave piggybacking in the > draft without comment on its merits was favored by no one. > The other options were as listed below. > > I would like you to comment on each whether you AGREE, > DISAGREE, or CAN LIVE WITH the option. > > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. DISAGREE. > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible With authentication data as part of the Binding Update, this is not an issue. > Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > > 2. Specify that piggybacking always be an option. AGREE. Notably, for any IPv6 extension header, IPv6 is designed to allow payload. Thus, we would have to explicitly break this part of the IPv6 design in order to disable the inclusion of payload. Also, please note that I do not suggest that payload MUST accompany the Binding Update! I only suggest that we have to make room for implementations that wish to make use of the additional performance improvement that is available by this technique. It does not make sense to me, to penalize all future implementations, just because there are some layer 2s for which the performance improvement is not large. > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s The first clause is also true for fragmentation, jumbo payload option, and probably others which clearly do belong at layer 3. Thus, the second clause is not a valid inference. > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU There are not any such links that correctly implement IPv6 MTU. In fact, for any link that somehow has used up the entire capacity of the link, the issue is transmission of the Binding Update in any form, not along with payload. Otherwise, what kind of "victimization" was intended to be suggested here? > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. The complete answer about how to use IPsec is going to take more effort than we can muster in the near term. Such effort SHOULD take into account the particular needs of Mobile IPv6 BSAs, anyway. I think that we should NOT go back to using only AH, especially because AH itself is likely to be deprecated in the future. This is not to say that AH should be disallowed -- indeed, it SHOULD be allowed! Indeed, any source node that wants to use AH should be encouraged to do so, and right now that would mean not including payload data to avoid selector problems. This would be easiest when we put the Binding Update into a new extension header type. > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > > Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links > Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node I think there is little to be gained by negotiation. Any relevant negotiation should probably be done by particular applications -- or, perhaps as part of specific QoS negotiations. For such applications, we could indicate that payloads should not be accompanied by Binding Updates, but that would amount to some higher-level protocol negotiation at the node, and API controlling the operation of the Binding Cache. It does not mean a layer-3 negotiation. > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. AGREE. I think we should not focus on IPsec problems at this time. > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. If there is a way to pre-recognize IPsec support between MN and CN that is useful for authenticating Binding Updates, then there is no point to do RR. I think we should keep IPsec as a future option, but with the intention of revisiting it after the future of AH is better known, and after we get finished with the base Mobile IPv6 specification. > (c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages DISAGREE. > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. Typically, the home agent doesn't have any data to send to the mobile node. If this is a problem, then we can make the appropriate restriction! > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. I do not think there is any need for the HA to insert such options. The HA can use ESP on packets sent to the mobile node, whether or not they have Binding Updates. If it is desired to have ESP only for packets that have Binding Updates, then we can have a different extension type (not Destination Option), as has been suggested already for Binding Updates, and which I think is a good idea. > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. This is not at all a problem, since the authentication data is available in a suboption to the Binding Update itself. Furthermore, I am mainly concerned about using Binding Update with data. If a return routability test enables creation of a Binding Cache entry, and if we can use Binding Updates to update existing Binding Cache entries, then only the initial creation and periodic update will be affected. These particular packets may not have such a strong need for timeliness as a generic Binding Update that would be sent along with streaming or real-time data. I can certainly imagine that a mobile node will have pre-established (even manual) security associations with certain correspondent nodes for which it does not want to undergo RR establishment of the relevant Binding Security Association. We have to make Mobile IPv6 work well in this case too, in addition to making the scalable solution (e.g., RR) work well. > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. As noted, I agree that we should have a different extension header type; however, this is not at all a determining factor about whether we should allow payload along with the new header type. Besides offering easier selection of security policy, a new header type will allow longer data, perhaps including certificates, to be carried. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:19:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22758 for ; Tue, 12 Feb 2002 14:19:24 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26831; Tue, 12 Feb 2002 12:19:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00156; Tue, 12 Feb 2002 11:18:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJHhFh010315 for ; Tue, 12 Feb 2002 11:17:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJHgcr010309 for mobile-ip-dist; Tue, 12 Feb 2002 11:17:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJHcFh010302 for ; Tue, 12 Feb 2002 11:17:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01765 for ; Tue, 12 Feb 2002 11:17:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02788 for ; Tue, 12 Feb 2002 12:17:40 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20005; Tue, 12 Feb 2002 11:17:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CJHbh28768; Tue, 12 Feb 2002 11:17:37 -0800 X-mProtect:  Tue, 12 Feb 2002 11:17:37 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRrRQgm; Tue, 12 Feb 2002 11:17:35 PST Message-ID: <3C696A4F.8653C362@iprg.nokia.com> Date: Tue, 12 Feb 2002 11:17:35 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, PRoberts@MEGISTO.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil, Phil Roberts wrote: > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. DISAGREE strongly with this. In the first place, I dont understand why this is there in the Piggybacking recommendation. When there is an IPSec SA between an MN and CN (could have been created statically for all you know), there is no need to run either RR or RR+CGA. regards Vijay ps: When would I have static IPSec SA between MN and CN? When I have download something from the PC sitting at my home onto my laptop. (the laptop being my MN, Home PC being my CN with the Home Agent in my corporate network) From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:32:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23070 for ; Tue, 12 Feb 2002 14:32:13 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07457; Tue, 12 Feb 2002 12:31:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03966; Tue, 12 Feb 2002 11:31:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJUVFh010441 for ; Tue, 12 Feb 2002 11:30:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJUVgK010440 for mobile-ip-dist; Tue, 12 Feb 2002 11:30:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJUSFh010433 for ; Tue, 12 Feb 2002 11:30:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05969 for ; Tue, 12 Feb 2002 11:30:30 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06727 for ; Tue, 12 Feb 2002 12:30:30 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1CJUTE03277; Tue, 12 Feb 2002 11:30:30 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW38859; Tue, 12 Feb 2002 11:30:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26937; Tue, 12 Feb 2002 11:30:29 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.27989.288742.685431@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 11:30:29 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: PRoberts@MEGISTO.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation In-Reply-To: <3C696A4F.8653C362@iprg.nokia.com> References: <3C696A4F.8653C362@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > Hi Phil, > > Phil Roberts wrote: > > > (b) We recommend that when IPsec protection is used, it is > > always used in *addition* to RR (or CGA) methods, not as > > a replacement. Thus RR (or CGA) methods would be used to > > protect MN - CN Route optimization procedures even when IPsec > > is used. > > DISAGREE strongly with this. In the first place, I dont > understand why this is there in the Piggybacking > recommendation. When there is an IPSec SA between > an MN and CN (could have been created statically for > all you know), there is no need to run either RR or > RR+CGA. This is not correct. Authentication != Authorization. Being able to positively identify an entity does not authorize use of a particular IP address unless there is explicit linkage between the security policy between the IP address and the identity. In general, there is no such linkage, nor should we expect any between MN and CN. HA/MN is a different story. Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:34:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23177 for ; Tue, 12 Feb 2002 14:34:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04379; Tue, 12 Feb 2002 12:34:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05137; Tue, 12 Feb 2002 11:33:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJWiFh010471 for ; Tue, 12 Feb 2002 11:32:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJWhKF010467 for mobile-ip-dist; Tue, 12 Feb 2002 11:32:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJWdFh010459 for ; Tue, 12 Feb 2002 11:32:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05556 for ; Tue, 12 Feb 2002 11:32:42 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04248 for ; Tue, 12 Feb 2002 11:32:42 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA20931; Tue, 12 Feb 2002 11:32:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CJWeC20494; Tue, 12 Feb 2002 11:32:40 -0800 X-mProtect:  Tue, 12 Feb 2002 11:32:40 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAfuMU2; Tue, 12 Feb 2002 11:32:37 PST Message-ID: <3C696DD6.4BF13651@iprg.nokia.com> Date: Tue, 12 Feb 2002 11:32:38 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: gdommety@cisco.com CC: mobile-ip@sunroof.eng.sun.com, alper@docomolabs-usa.com Subject: Re: [mobile-ip] missing draft-ietf-mobileip-fast-mipv6-04.txt References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> <4.3.2.7.2.20011203163345.02682ae0@mira-sjcm-3.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Gopal, You sent this mail out on 3rd Dec. Why havent you submitted this draft to the IETF internet-draft directories? We are planning to test FMIPv6 at Connectathon 2002. Since it is not there in the internet-draft directories, should we assume that draft 03 is the latest? We have implemented only draft 03. Can somebody please get me a copy of draft 04? Cant find it at the URL given below. regards Vijay Gopal Dommety wrote: > > A newer version of the Draft that addresses a lot comments sent to me can > be found at: > > http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast-mipv6-04.txt > > Thanks > Gopal From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:36:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23258 for ; Tue, 12 Feb 2002 14:36:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12708; Tue, 12 Feb 2002 12:36:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06351; Tue, 12 Feb 2002 11:36:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJZ4Fh010532 for ; Tue, 12 Feb 2002 11:35:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJZ4H0010531 for mobile-ip-dist; Tue, 12 Feb 2002 11:35:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJZ1Fh010521 for ; Tue, 12 Feb 2002 11:35:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07824 for ; Tue, 12 Feb 2002 11:35:04 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11962 for ; Tue, 12 Feb 2002 12:35:03 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1CJZ3t25237 for ; Tue, 12 Feb 2002 11:35:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW38992; Tue, 12 Feb 2002 11:34:34 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26940; Tue, 12 Feb 2002 11:35:02 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.28262.539690.596780@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 11:35:02 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Piggybacking - DT recommendation In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil Roberts writes: > I would like you to comment on each whether you AGREE, > DISAGREE, or CAN LIVE WITH the option. > > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. AGREE > 2. Specify that piggybacking always be an option. DISAGREE > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. DISAGREE > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. AGREE > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. AGREE except this is not necessary between MN/HA, IMO > (c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages AGREE Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:44:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23618 for ; Tue, 12 Feb 2002 14:44:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09586; Tue, 12 Feb 2002 12:44:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08122; Tue, 12 Feb 2002 11:44:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJhSFh010638 for ; Tue, 12 Feb 2002 11:43:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJhRWX010637 for mobile-ip-dist; Tue, 12 Feb 2002 11:43:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJhOFh010630 for ; Tue, 12 Feb 2002 11:43:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08146 for ; Tue, 12 Feb 2002 11:43:27 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16350 for ; Tue, 12 Feb 2002 12:43:26 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id B31A543262; Tue, 12 Feb 2002 20:43:25 +0100 (CET) Received: from it.uc3m.es (zanfona.it.uc3m.es [163.117.139.92]) by smtp01.uc3m.es (Postfix) with ESMTP id 7183299E5D; Tue, 12 Feb 2002 20:43:25 +0100 (CET) Message-ID: <3C697050.8C71FDC4@it.uc3m.es> Date: Tue, 12 Feb 2002 20:43:12 +0100 From: Ignacio Soto Campos X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon Josefsson Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: draft on random interface identifiers available References: <3C5EAE12.DA5F9400@it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Simon, Simon Josefsson wrote: > Ignacio Soto Campos writes: > > > Hi all, > > > > We have submitted the draft "Random generation of interface > > identifiers" that is available from: > > > > http://www.ietf.org/internet-drafts/draft-soto-mobileip-random-iids-00.txt > > > > The abstract is included below. Comments are welcomed. > > To describe how "random generation" of interface identifiers can be > done properly, you might want to cite RFC 1750. Due to the nature of > Yes, you are right, this RFC about how to generate random numbers is interesting information for our draft. Thanks for your feedback. Ignacio > this, using only network traffic as a source of randomness might not > be perfect, I'm not sure if it is worth making a note of this. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 14:46:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23700 for ; Tue, 12 Feb 2002 14:46:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15076; Tue, 12 Feb 2002 12:46:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08628; Tue, 12 Feb 2002 11:45:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJj7Fh010667 for ; Tue, 12 Feb 2002 11:45:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CJj7K8010666 for mobile-ip-dist; Tue, 12 Feb 2002 11:45:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CJj4Fh010659 for ; Tue, 12 Feb 2002 11:45:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08334 for ; Tue, 12 Feb 2002 11:45:05 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17138 for ; Tue, 12 Feb 2002 12:45:05 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA21950; Tue, 12 Feb 2002 11:45:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CJj3t09303; Tue, 12 Feb 2002 11:45:03 -0800 X-mProtect:  Tue, 12 Feb 2002 11:45:03 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqmwMcb; Tue, 12 Feb 2002 11:44:59 PST Message-ID: <3C6970BC.C483E441@iprg.nokia.com> Date: Tue, 12 Feb 2002 11:45:00 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: PRoberts@MEGISTO.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <3C696A4F.8653C362@iprg.nokia.com> <15465.27989.288742.685431@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Vijay Devarapalli writes: > > Hi Phil, > > > > Phil Roberts wrote: > > > > > (b) We recommend that when IPsec protection is used, it is > > > always used in *addition* to RR (or CGA) methods, not as > > > a replacement. Thus RR (or CGA) methods would be used to > > > protect MN - CN Route optimization procedures even when IPsec > > > is used. > > > > DISAGREE strongly with this. In the first place, I dont > > understand why this is there in the Piggybacking > > recommendation. When there is an IPSec SA between > > an MN and CN (could have been created statically for > > all you know), there is no need to run either RR or > > RR+CGA. > > This is not correct. Authentication != Authorization. > Being able to positively identify an entity does > not authorize use of a particular IP address unless > there is explicit linkage between the security policy > between the IP address and the identity. In > general, there is no such linkage, nor should > we expect any between MN and CN. HA/MN is a > different story. You took out the example I gave. In the example I gave, the fact that I manually created the IPSec CA between my home PC and my laptop is authorization enough. Vijay > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 15:06:53 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24343 for ; Tue, 12 Feb 2002 15:06:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06992; Tue, 12 Feb 2002 12:06:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14503; Tue, 12 Feb 2002 12:06:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CK5NFh010911 for ; Tue, 12 Feb 2002 12:05:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CK5NQA010910 for mobile-ip-dist; Tue, 12 Feb 2002 12:05:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CK5KFh010903 for ; Tue, 12 Feb 2002 12:05:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17287 for ; Tue, 12 Feb 2002 12:05:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19086 for ; Tue, 12 Feb 2002 12:05:23 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA23339; Tue, 12 Feb 2002 12:05:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CK5Gw11038; Tue, 12 Feb 2002 12:05:16 -0800 X-mProtect:  Tue, 12 Feb 2002 12:05:16 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeOe74g; Tue, 12 Feb 2002 12:05:14 PST Message-ID: <3C69757B.65954609@iprg.nokia.com> Date: Tue, 12 Feb 2002 12:05:15 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: PRoberts@MEGISTO.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <3C696A4F.8653C362@iprg.nokia.com> <15465.27989.288742.685431@thomasm-u1.cisco.com> <3C6970BC.C483E441@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > Michael Thomas wrote: > > > > Vijay Devarapalli writes: > > > Hi Phil, > > > > > > Phil Roberts wrote: > > > > > > > (b) We recommend that when IPsec protection is used, it is > > > > always used in *addition* to RR (or CGA) methods, not as > > > > a replacement. Thus RR (or CGA) methods would be used to > > > > protect MN - CN Route optimization procedures even when IPsec > > > > is used. > > > > > > DISAGREE strongly with this. In the first place, I dont > > > understand why this is there in the Piggybacking > > > recommendation. When there is an IPSec SA between > > > an MN and CN (could have been created statically for > > > all you know), there is no need to run either RR or > > > RR+CGA. > > > > This is not correct. Authentication != Authorization. > > Being able to positively identify an entity does > > not authorize use of a particular IP address unless > > there is explicit linkage between the security policy > > between the IP address and the identity. In > > general, there is no such linkage, nor should > > we expect any between MN and CN. HA/MN is a > > different story. > > You took out the example I gave. In the example I gave, the > fact that I manually created the IPSec CA between my home ~~~~~~~~ > PC and my laptop is authorization enough. IPSec SA. sorry about that. Vijay > > Vijay > > > > > Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 15:07:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24366 for ; Tue, 12 Feb 2002 15:07:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27859; Tue, 12 Feb 2002 13:07:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14770; Tue, 12 Feb 2002 12:07:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CK6IFh010928 for ; Tue, 12 Feb 2002 12:06:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CK6IRI010927 for mobile-ip-dist; Tue, 12 Feb 2002 12:06:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CK6EFh010920 for ; Tue, 12 Feb 2002 12:06:14 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17529 for ; Tue, 12 Feb 2002 12:06:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23646 for ; Tue, 12 Feb 2002 12:06:17 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA23379 for ; Tue, 12 Feb 2002 12:06:16 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CK6Fm12408 for ; Tue, 12 Feb 2002 12:06:15 -0800 X-mProtect:  Tue, 12 Feb 2002 12:06:15 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdAKJjBL; Tue, 12 Feb 2002 12:06:13 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id MAA80681 for ; Tue, 12 Feb 2002 12:06:14 -0800 (PST) Message-ID: <3C6975B6.124B7AB0@iprg.nokia.com> Date: Tue, 12 Feb 2002 12:06:14 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BU Authorization method: bidding down References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, Thanks for your comments. However, there are some issues important for short-term progress.. Seems you are basically saying there is no need for alternatives to CGA as of the bidding down method is concerned. Perhaps even no need for variations of CGA. But, to have RR+CGA as the only method beyond RR causes that there actually is *no* higher method at all for non-CGA addresses. Furthermore, this supposedly generic bidding down prevention method prevents attempts to have anything for non-CGA addresses in the future, either. Even introducing better variants of RR is not supported. Hence, I must conclude that even if no acceptable alternative mechanisms are found, there should be concern taking the 1-bit to the base MIPv6, since this is not a general-purpose mechanism. Having the bit-method standardized elsewhere should not preclude its use since once CGA address subspace is mandated, any node supporting CGAs should implement this anyway and there enforcement of the bit method should follow naturally. But until that happens, this shouldn't stop making MIPv6 go forward. But I am happy to continue this discussion at a later stage. Some remarks below. > > - the bit method locks us to one method, no much alternatives > > in the future nor room for replacement (even a chosen CGA > > method may need change, e.g. for better security or > > optimization, then the bit encoding needs to change > > again, so it may be not too good for even CGA) > One could take two different approaches for defining the > semantics of the bit: > - An address with the CGA bit set has an interface ID which > is the bottom 64 bits of a hash of a public key (with the > universal and group bits set to indicate the CGA property) > - Same as above but instead of "hash" say SHA-1. > > One question is what the tradeoffs are between the two > descriptions. If the hash is not specified how would a peer > know which hash to apply to verify the public key - interface > ID relationship and what are the security issues in communicating > that insecurely to the peer? You basically say: if it is not at all considered possible to carry selection info online (which I disagree), there is an issue to carry it even as Jari A. mentioned: have it in the hash and tell in the signaling which hash is used. The same concerns should apply to that signaling making James's comment on undecodability of the hash containing the method a valid remark. Also, I wonder if CGA is really designed for permanent home addresses. > If the hash is specified what is the likelyhood that there will be > a new more secure hash (when truncated to 62 or 63 bits) in the future > thus there will be a need to move to using that hash. > Note that more secure hash functions will appear e.g. hashes > producing longer results - the question is whether the fact that the result > must be truncated change the likely evolution. > What has history tell us about the latter question? Do not know about that, but are you saying there is possibly no need to change the hash? Maybe it's a result of the limited amount of bits available for the hash in CGAs rather than no future for new methods. > > - the requirement for change is extensive > > I think the change to reserve the bit might be as small as one sentence > in each of RFC 2373, RFC 3041 and RFC 2472. > Having MIPv6 not allow RR when the bit is set is presumably a short paragraph > in the mipv6 spec. > So I don't know what you mean by "extensive" - the amount of time > to complete the above? > [AD hat on: I think reserving a bit in the interface ID makes sense > independently of CGA - there might be some great new idea in the future that > could benefit from a bit even if CGA doesn't need one.] Can't comment here too much other than note some RFC changes are needed. Also, some analysis on CGA and its specific uses would not hurt before making it a fundamental part of the IPv6 addressing architecture. I agree that there are many ideas on different properties of the address that could be encoded into IPv6 addresses.. [discussion on on-line method] > > - There is no need to actually establish RO, just to do some signaling, > > to be precise, immediately after receiving the first non-RO packet > > with subsequent rate limiting not to do that for every non-RO packet. > > This could be a de-registration establishing the level of authorization > > and that MN wishes to do no RO, but e.g. bidir. tunneling, if desired. > > Hmm - that would seem to imply that the CN would need to keep state oer > MN even when RO is not used. > That state might be just one bit (e.g. don't accept RR BUs) but it would > still require separate state maintenance. > > > - Or, one could add offline tag to support this case (an extension to DNS) > > which gives the minimum condition for the BCE making CN garbage collect > > too low priority BCEs and would be much more flexible for future > > change than address bit encoding and would require change to 1 place > > beyond base MIPv6 instead of many, just to give an example of > > an alternative to 1-bit which is a more "offline" method. > > Yes, but since applications today sit between the DNS (i.e. getaddrinfo()) > and the protocol stack (socket interface) in many systems this would > require changes to the APIs to be able to pass this information. Or then not, depending on where the lookups you mention below are done. > Also, today typically only the initiating end of communication does a DNS > lookup. The above would require the accepting end of communication to > also do a DNS lookup - since that end can't securely know the DNS name > of the peer it presumably needs to do a reverse lookup to find the hostname > and then look for the "tag" record in the forward DNS tree. Or do the last two above from the stack without involving the application, when doing fwd/B cache lookup. But these are speculations on whether alternatives to 1-bit were possible. .. > I think there are present bidding down attacks. (See below). > > > > > Suppose we are using a simple rule in CN which > > > > tags BCE telling how it was authorized and refuses > > > > BUs with lower-priority authorizations during the > > > > lifetime of a BCE but any time accepts authorizations > > > > of the same or higher method. Legitimate MN is never > > > > blocked from regaining the BCE nor can it lose it > > > > when it needs the BCE. When legitimate MN is not > > > > communicating, it should be enough for the CN > > > > to expire unused BCEs injected by RR attacker > > > > for the CN to be able to communicate with the > > > > legitimate MN, and/or always start its sessions > > > > with non RO data packet despite BCE. > > > > > > The "starts its session" seems to imply that the IP layer, when choosing > > > whether or not to use a RR BCE, needs to be able to identify a new session > > > indepedently of the transport and application protocol. > > > > > > For TCP and SCTP I can see us doing this, but what about some yet to > > > be invented protocol over (congestion controlled) UDP? Reliable multicast? > > > It seems impossible to make this distinction in general. > > > > The "start session" option should be generalized as > > the ability by CN to check whether a BCE was not set > > up by a too "low" method. It could be based on recognizing > > sessions (setting new flows could be one way), or also > > to periodically send non-RO packets and a condition that > > MN needs to respond to those with a BU (which can be > > deregistration if one does not want to start RO now > > or at all). This to invoke discussion looking more deeply > > to generic locally standardizable on-line signaling > > alternatives. > > Sure sounds complex. The periodic recheck is basically saying that you > allow DoS blackhole attacks for a time less than the period. > If this period is longer than the time for upper layer protocols (be it > transport or application protocols) to give up the DoS attack has > been successful. If that causes the recheck to happen every 10 seconds > this might be a lot of background chatter on the wire. Note that the ability to do DoS attack should be compared against what you can do against higher methods. I am not suggesting that frequent checks, just the ability to recover from false BCE. To compare DoS, for CGA, you can block DNS requests from the CN. It will not learn the HoA nor the bit telling which method to accept. > I don't understand your point about DNSSEC - if DNSSEC is used by the CN > to find the MN's HoA then the CN will know for sure the setting of > the bit. You can DoS the 1-bit if the DNS query itself can be blocked, saying the flag even there is passed on-line, though not in the RR or BU signaling. > But I think it would be useful to pop up a level when analysing the residual > threats. Per the DT document CGA protected BU's are strictly more secure > than RR protected BU's when it comes to e.g. future attacks and the need for > RR checks against the HoA in the context of attackers that are on the path. Given RR was changed to separately check direct and indirect path, can you specify the non-future (on-path?) attacks against RR if the attacker cannot block messages of the victim? > Question is whether this matters in the large scheme of things for MIPv6. > Such an attacker can just drop data packets as a DoS attack and can > already (by virtue of being on the path and thereby being able to prevent RO) > see all the data packets (and modify them unless they are protected by > higher layer security like IPsec or TLS). > So does CGA, as we understand it today, really make a significant enough > difference for MIPv6? This is what I try to understand. > (I continue to believe that CGA would be a useful tool in authrizing e.g. > MLD joins for anycast groups, preventing DAD and address resolution spoofing > on a link, but those approaches might not need a bit in the address - to > early to tell.) I also think it may have potential, but this would merit more discussion.. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 15:34:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25537 for ; Tue, 12 Feb 2002 15:34:12 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01895; Tue, 12 Feb 2002 13:33:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26748; Tue, 12 Feb 2002 12:33:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CKWlFh011242 for ; Tue, 12 Feb 2002 12:32:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CKWlOf011241 for mobile-ip-dist; Tue, 12 Feb 2002 12:32:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CKWhFh011234 for ; Tue, 12 Feb 2002 12:32:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01428 for ; Tue, 12 Feb 2002 12:32:47 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08999 for ; Tue, 12 Feb 2002 13:32:46 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1CKWkh24915; Tue, 12 Feb 2002 12:32:46 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW40547; Tue, 12 Feb 2002 12:32:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26954; Tue, 12 Feb 2002 12:32:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.31723.114899.427700@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 12:32:43 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Francis Dupont , Vijay Devarapalli , Erik Nordmark , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: References: <200202101343.g1ADh2g94605@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > => you may think this is unworkable in practice in the general case > > but I don't understand why you don't accept this for particular > > cases. For instance DNSSEC can be used on reverse sub-trees of the DNS > > (reverse: address to name/properties maps) and can solve the authentication/ > > authorization problem of Mobile IPv6 on the part of the Internet it applies. > > DNSSEC wasn't intended to be a PKI last time I looked :-) There's a difference between being a PKI and presupposing a PKI. I think that DNSSEC assumes the latter. While I think it's perilous in general to posit large scale PKI's, if the net were ever to have one, DNS seems like a pretty likely suspect considering that it already provides a top down namespace. Whether we'd want ICANN in charge of a global PKI is another argument, of course... Mike From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 15:44:54 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26228 for ; Tue, 12 Feb 2002 15:44:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14233; Tue, 12 Feb 2002 12:44:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29919; Tue, 12 Feb 2002 12:44:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CKhNFh011303 for ; Tue, 12 Feb 2002 12:43:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CKhNJG011302 for mobile-ip-dist; Tue, 12 Feb 2002 12:43:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CKhJFh011295 for ; Tue, 12 Feb 2002 12:43:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22447; Tue, 12 Feb 2002 12:42:37 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01533; Tue, 12 Feb 2002 12:42:37 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1CKgCh01784; Tue, 12 Feb 2002 12:42:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW40825; Tue, 12 Feb 2002 12:41:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26957; Tue, 12 Feb 2002 12:42:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.32290.316241.457577@thomasm-u1.cisco.com> Date: Tue, 12 Feb 2002 12:42:10 -0800 (PST) To: Francis Dupont Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com, Erik Nordmark , Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: <200202121802.g1CI2rg04935@givry.rennes.enst-bretagne.fr> References: <15465.17313.478396.696440@thomasm-u1.cisco.com> <200202121802.g1CI2rg04935@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, My only point is that we not equate the base level crypto with the keying. It's well known that IKE has lots of flaws, and those are being worked on from several fronts (KINK, JFK...). I think its also pretty well agreed upon that the base level 2401 model is not broken, and that any changes there are likely to be evolutionary, rather than revolutionary (nuke AH, AES, nat traversal, kernel/app credential API). Mike Francis Dupont writes: > In your previous mail you wrote: > > Just as a note, IPsec != IKE. > > => I agree but IKE is the only generally available key exchange protocol > for IPsec. > > You could use KINK instead > > => KINK is fine even not generally available: I looked at KINK when > I developed the first version of my AAA-based stuff but today I prefer > to use HIP as the model (granularity of HIP is more suitable for the > context of Mobile IPv6). > > and all of Francis' criticisms go away. > > => note they are facts (the fact it was painful and slow, and the fact > it worked). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: for this usage the best IPsec stuff is SKIP (BTW I can't find > a RFC with the SKIP specs) but it is not enough available. > (SKIP was proposed by Jim Bound in a private discussion) From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 16:11:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27495 for ; Tue, 12 Feb 2002 16:11:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20327; Tue, 12 Feb 2002 13:11:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08187; Tue, 12 Feb 2002 13:11:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CL9IFh011425 for ; Tue, 12 Feb 2002 13:09:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CL9I1c011424 for mobile-ip-dist; Tue, 12 Feb 2002 13:09:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CL9DFh011417 for ; Tue, 12 Feb 2002 13:09:13 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12415 for ; Tue, 12 Feb 2002 13:08:57 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19444 for ; Tue, 12 Feb 2002 13:08:56 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA27539; Tue, 12 Feb 2002 13:08:53 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CL8rp24326; Tue, 12 Feb 2002 13:08:53 -0800 X-mProtect:  Tue, 12 Feb 2002 13:08:53 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBh0KIm; Tue, 12 Feb 2002 13:08:51 PST Message-ID: <3C698463.D85D8A21@iprg.nokia.com> Date: Tue, 12 Feb 2002 13:08:51 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, Erik Nordmark wrote: > Rajeev, > > > How does the attacker see N2 in 1a ? > > In one case because the attacker is the entity sending 1a and 1b > specifying the real HoA of the MN. > It could do this every second or so so that even if the real MN > was doing BUs they would be overridden in less than 1 second. > I think this can be solved by requiring the CN to verify the home address ownership prior to verifying the "selector hash". This is reasonable since the BU authorization protocol (i.e., CGA)the MN is trying to use is tied to proving address ownership anyway. > > Also, an attacker on the same link as the CN would see both 1a and 1b. > Assuming that the "leaf" links are the least secure (imagine a CN in > the IETF WLAN/terminal room) this would be a likely source of attacks. > While this is valid, the problem scope is wider. Regards, -Rajeev > Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 16:21:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27715 for ; Tue, 12 Feb 2002 16:21:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28802; Tue, 12 Feb 2002 14:21:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11628; Tue, 12 Feb 2002 13:21:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CLJqFh011492 for ; Tue, 12 Feb 2002 13:19:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CLJpbx011491 for mobile-ip-dist; Tue, 12 Feb 2002 13:19:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CLJmFh011484 for ; Tue, 12 Feb 2002 13:19:48 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11159 for ; Tue, 12 Feb 2002 13:19:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24454 for ; Tue, 12 Feb 2002 13:19:50 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1CLJma21922 for ; Tue, 12 Feb 2002 22:19:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA13427 for ; Tue, 12 Feb 2002 22:19:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1CLJmg06136 for ; Tue, 12 Feb 2002 22:19:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202122119.g1CLJmg06136@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: (ISSUE) Re: [mobile-ip] Routing headers - part 2 In-reply-to: Your message of Mon, 11 Feb 2002 22:32:24 +0100. Date: Tue, 12 Feb 2002 22:19:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: New routing header type ----------------------- The idea is to define Routing Header type 1 to be a constrained => ARGH!!! The type 1 is already allocated by IANA to NIMROD, cf http://www.iana.org/assignments/ipv6-parameters ! Why do you believe we talked about type 2? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 16:23:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27807 for ; Tue, 12 Feb 2002 16:23:03 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29505; Tue, 12 Feb 2002 14:22:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12162; Tue, 12 Feb 2002 13:22:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CLL1Fh011509 for ; Tue, 12 Feb 2002 13:21:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CLL0FR011508 for mobile-ip-dist; Tue, 12 Feb 2002 13:21:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CLKuFh011501 for ; Tue, 12 Feb 2002 13:20:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16559 for ; Tue, 12 Feb 2002 13:21:00 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14732 for ; Tue, 12 Feb 2002 14:20:54 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1CLKse13355 for ; Tue, 12 Feb 2002 13:20:54 -0800 (PST) Message-ID: <000001c1b40a$ef0e50d0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 12 Feb 2002 11:18:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit FWIW, DoCoMo uses signaling piggybacking on its current i-mode network, for spectral efficiency on the radio link. I don't know the particulars of how, but it is a data point. jak ----- Original Message ----- From: "Phil Roberts" To: Sent: Tuesday, February 12, 2002 8:52 AM Subject: [mobile-ip] Piggybacking - DT recommendation > > Hello folks, > > We need to get closure on the Working Group's stance on > piggybacking of binding update messages. Much of the > discussion last year was around the issue that doing so > generally meant that IPsec specifications and implementations > needed some modifications in order to protect BU messages that > were piggybacked in other messages. Other discussions were > around the relative merits of piggybacking in terms of > performance of particular kinds of link layers, whether > beneficial or harmful. Still other discussions were around > the complexity of implementing it in the receiver. > > This note is an attempt to summarize the pros and cons > of the various approaches and to give a design team > recommendation. The summary is more difficult because > there was little agreement in the earlier discussions on > whether the asserted benefits were real. In fact, it > doesn't seem there was agreement on ANY of the asserted > pros and cons below, except that it would be difficult to > add the function later. > > Jari documented the tradeoffs of using piggybacking > with IPSEC well in: > > http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01. txt > > In Salt Lake City a set of options was put before the > working group. The option to leave piggybacking in the > draft without comment on its merits was favored by no one. > The other options were as listed below. > > I would like you to comment on each whether you AGREE, > DISAGREE, or CAN LIVE WITH the option. > > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. > > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible > Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > > 2. Specify that piggybacking always be an option. > > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > > Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links > Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node > > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > > (c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. > > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. > > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. > > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. > > > Phil > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 17:58:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00192 for ; Tue, 12 Feb 2002 17:58:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14657; Tue, 12 Feb 2002 15:58:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13186; Tue, 12 Feb 2002 14:58:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CMvfFh011951 for ; Tue, 12 Feb 2002 14:57:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CMvfWP011950 for mobile-ip-dist; Tue, 12 Feb 2002 14:57:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CMvcFh011943 for ; Tue, 12 Feb 2002 14:57:38 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22366 for ; Tue, 12 Feb 2002 14:57:41 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05489 for ; Tue, 12 Feb 2002 14:57:40 -0800 (PST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1CMvdv25206 for ; Tue, 12 Feb 2002 16:57:39 -0600 (CST) Message-ID: <3C699DDF.5020405@alcatel.com> Date: Tue, 12 Feb 2002 16:57:35 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil, Looking at the replies to this thread reminds me what happened last year, was it November?. Exactly the same set of people are for and against the conclusion of DT (BTW it goes without saying that I also AGREE). However the point is that Charlie's opinion is an important factor in this and I would have thought that DT first got his consent on it. So I respect Charlie's opinion and hereby ask the DT to consult with him and get him agree first. Regards, Phil Roberts wrote: >Hello folks, > > We need to get closure on the Working Group's stance on >piggybacking of binding update messages. Much of the >discussion last year was around the issue that doing so >generally meant that IPsec specifications and implementations >needed some modifications in order to protect BU messages that >were piggybacked in other messages. Other discussions were >around the relative merits of piggybacking in terms of >performance of particular kinds of link layers, whether >beneficial or harmful. Still other discussions were around >the complexity of implementing it in the receiver. > > This note is an attempt to summarize the pros and cons >of the various approaches and to give a design team >recommendation. The summary is more difficult because >there was little agreement in the earlier discussions on >whether the asserted benefits were real. In fact, it >doesn't seem there was agreement on ANY of the asserted >pros and cons below, except that it would be difficult to >add the function later. > > Jari documented the tradeoffs of using piggybacking >with IPSEC well in: > >http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt > >In Salt Lake City a set of options was put before the >working group. The option to leave piggybacking in the >draft without comment on its merits was favored by no one. >The other options were as listed below. > >I would like you to comment on each whether you AGREE, >DISAGREE, or CAN LIVE WITH the option. > >1. Specify that piggybacking of binding update messages not > be used with MIP v6. > >Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible >Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > >2. Specify that piggybacking always be an option. > >Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links >Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > >3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > >Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links >Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node > >The DT has come to the following conclusions: > >(a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > >(b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > >(c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. > > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. > > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. > > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. > > >Phil > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 18:49:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00956 for ; Tue, 12 Feb 2002 18:49:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05839; Tue, 12 Feb 2002 16:49:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04702; Tue, 12 Feb 2002 15:48:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CNluFh012072 for ; Tue, 12 Feb 2002 15:47:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CNluqI012071 for mobile-ip-dist; Tue, 12 Feb 2002 15:47:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CNlqFh012061 for ; Tue, 12 Feb 2002 15:47:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05135 for ; Tue, 12 Feb 2002 15:47:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08478 for ; Tue, 12 Feb 2002 16:47:54 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA08895 for ; Tue, 12 Feb 2002 15:47:54 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CNlrA03187 for ; Tue, 12 Feb 2002 15:47:53 -0800 X-mProtect:  Tue, 12 Feb 2002 15:47:53 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdjOVURf; Tue, 12 Feb 2002 15:47:51 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id PAA80914 for ; Tue, 12 Feb 2002 15:47:51 -0800 (PST) Message-ID: <3C69A9A7.A0317E93@iprg.nokia.com> Date: Tue, 12 Feb 2002 15:47:51 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, Thanks for the writeup. To participate to forming the WG opinion, my favorite is the RH type 2 due to minimal change and since I disagree that the semantical similarity to RH T0 for fw admins would be big enough issue for them to drop RH T2 as well. Comparing to DO, fw implementors and users need to know something about the new DO, too. AGREE with having RH T2 but with the above disagreement on a con being significant. DISAGREE that we'd need to have a new DO. BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 18:49:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00968 for ; Tue, 12 Feb 2002 18:49:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09153; Tue, 12 Feb 2002 16:49:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04807; Tue, 12 Feb 2002 15:49:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CNlrFh012063 for ; Tue, 12 Feb 2002 15:47:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1CNlqkg012062 for mobile-ip-dist; Tue, 12 Feb 2002 15:47:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1CNlnFh012054 for ; Tue, 12 Feb 2002 15:47:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05119 for ; Tue, 12 Feb 2002 15:47:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05312 for ; Tue, 12 Feb 2002 16:47:51 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA08891; Tue, 12 Feb 2002 15:47:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1CNloV02988; Tue, 12 Feb 2002 15:47:50 -0800 X-mProtect:  Tue, 12 Feb 2002 15:47:50 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoh21lH; Tue, 12 Feb 2002 15:47:48 PST Message-ID: <3C69A942.5E737BB6@iprg.nokia.com> Date: Tue, 12 Feb 2002 15:46:10 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <3C699DDF.5020405@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Behcet, Thanks for your consideration of my message about piggybacking, and I appreciate that you want my opinion to be taken into account. I see that you disagree with the conclusions I have tried to support in my message, but I don't see where I have gone wrong. Can you say what it is that I have written that you disagree with? Regards, Charlie P. Behcet Sarikaya wrote: > Hi Phil, > Looking at the replies to this thread reminds me what happened last > year, was it November?. Exactly the same set of people are for and > against the conclusion of DT (BTW it goes without saying that I also AGREE). > However the point is that Charlie's opinion is an important factor in > this and I would have thought that DT first got his consent on it. So I > respect Charlie's opinion and hereby ask the DT to consult with him and > get him agree first. > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 19:22:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01408 for ; Tue, 12 Feb 2002 19:22:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10759; Tue, 12 Feb 2002 17:21:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12404; Tue, 12 Feb 2002 16:21:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0KmFh012411 for ; Tue, 12 Feb 2002 16:20:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D0KmHG012410 for mobile-ip-dist; Tue, 12 Feb 2002 16:20:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0KfFh012403 for ; Tue, 12 Feb 2002 16:20:43 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1D0KVM27720; Wed, 13 Feb 2002 01:20:33 +0100 (MET) Date: Wed, 13 Feb 2002 01:16:19 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <200202121652.g1CGqKg04522@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => to return a credential (your model?) or to use AAA for the transport > (my model) is a matter of taste, I don't believe we have very different > opinions. I know we have different opinions on this point - the models are different. > > => at least to get a open door in the BU stuff? > > Do you see a closed door anywhere? > > => BU authentication == RR [+ CGA] Huh? I've gotten the message that the MIP WG wants to get MIPv6 secure enough so that it can go to proposed standard. I don't think you're proposing that we delay this until there is some additional approach involving the AAA. So how does having a "do no harm" way of securing BUs prevent there from developping other ways to secure them? > I don't. The protocol would need to get worked out, and follow the normal > standards track criteria. (clear, useful, etc) > > => but the form of the current BU authentication recommendation is closed, > for instance I am very surprised we are not flooded by messages about > "I already have a good IPsec SA, how can I protect the BU with it"... > (there should be a flu epidemic in the Silicon Valley, or we have > bored them to near death :-) Perhaps they see open doors? > Would AAA be better because diameter runs over SCTP instead of IKE > over UDP? > > => this is a joke, isn't it? But I believe you are right. Some stupid > problems with IKE come from the use of UDP... No. It is a direct response to your point about IKE not performing well while AAA performing better under the same assumptions. Both protocols as I understand send a request and wait for a reply (and then repeat). So what makes their performance differ? Does IKE over UDP have a 10 second retransmit timer while SCTP/TCP have an initial retransmit timer of 2? 4? seconds? > About the real topic of this discussion: what is scheduled in the future > document about alternative BU authentications, including all the known > infrastructure based and/or for home registrations? "scheduled"? The WG does need to come to consensus on how to secure home registrations. I'm assuming the WG neither wants to hold up the MIPv6 specification while infrastructure-based methods are developped, nor prevent such methods from being developped and added to the stew. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 19:45:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01781 for ; Tue, 12 Feb 2002 19:45:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26641; Tue, 12 Feb 2002 17:45:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16783; Tue, 12 Feb 2002 16:45:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0iMFh012467 for ; Tue, 12 Feb 2002 16:44:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D0iMk4012466 for mobile-ip-dist; Tue, 12 Feb 2002 16:44:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D0iHFh012459 for ; Tue, 12 Feb 2002 16:44:18 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1D0i9M29351; Wed, 13 Feb 2002 01:44:11 +0100 (MET) Date: Wed, 13 Feb 2002 01:39:57 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: James Kempf Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <008f01c1b3f2$f658b230$4c6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Since the question of whether to accept the BU is restricted to > the BU itself, what's the problem with putting some kind of > indication in the BU about which method should be used? The only issue is how to securely communicate this information to the peer so that a MiTM can't force it to use less secure methods. Jari Arkko's suggestion to include the loose notion of algorythm/method into the hash as well as including that information in the BU messages would solve that problem. But this still assumes that the IPv6 interface ID is a hash of a public key. > > Why don't you think RR will be widely applicable? Too many packets? > > > > By "widely applicable" I mean beyond Mobile IP. I think RR probably > will see some use in Mobile IP, but it is not entirely clear that it > will be widely deployed. As you say, the amount of signaling > involved is onerous, I suspect this will be a damper on use, especially > over the Internet. Are you thinking about Seamoby and LMM type stuff? For those creating BSAs might make more sense. > Sure, but it still doesn't solve the problem of what happens when > congestion > causes a router to drop a packet, particularly 1a and 1b. This could > make > BUs very expensive in terms of time. Sure, having 5 packets instead of 1 increases the probability of at least one of them being dropped. But even with current model of a the single BU packet it might get dropped which would cause delays. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 20:05:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02196 for ; Tue, 12 Feb 2002 20:05:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04095; Tue, 12 Feb 2002 18:05:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21452; Tue, 12 Feb 2002 17:05:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D14XFh012510 for ; Tue, 12 Feb 2002 17:04:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D14XpY012509 for mobile-ip-dist; Tue, 12 Feb 2002 17:04:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D14UFh012502 for ; Tue, 12 Feb 2002 17:04:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19359; Tue, 12 Feb 2002 17:04:33 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07955; Tue, 12 Feb 2002 18:04:32 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1D14We23257; Tue, 12 Feb 2002 17:04:32 -0800 (PST) Message-ID: <019c01c1b42a$2c6b4c20$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: "Erik Nordmark" , References: Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Tue, 12 Feb 2002 17:02:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > Since the question of whether to accept the BU is restricted to > > the BU itself, what's the problem with putting some kind of > > indication in the BU about which method should be used? > > The only issue is how to securely communicate this information to the peer > so that a MiTM can't force it to use less secure methods. > Jari Arkko's suggestion to include the loose notion of algorythm/method > into the hash as well as including that information in the BU messages > would solve that problem. > But this still assumes that the IPv6 interface ID is a hash of a public key. > Hmm, now I am confused. I thought that the idea was not to try to force security against MiTM attacks, because that could not be completely assured for RR anyway. Or maybe some MiTM attacks can be secured and others can't? I agree that Jari's method of a loose inclusion of the algorithm in the hash would work, but I would rather not constrain the address suffix at this point, since a future CGA-like method might be impacted. > > > > Why don't you think RR will be widely applicable? Too many packets? > > > > > > > By "widely applicable" I mean beyond Mobile IP. I think RR probably > > will see some use in Mobile IP, but it is not entirely clear that it > > will be widely deployed. As you say, the amount of signaling > > involved is onerous, I suspect this will be a damper on use, especially > > over the Internet. > > Are you thinking about Seamoby and LMM type stuff? > For those creating BSAs might make more sense. > I'm thinking about securing paging and maybe other kinds of IPv6 signaling, like ND. I think CGAs or something similar may have some applicablity here, RR certainly doesn't. Or maybe BSAs, though that seems too heavyweight. As for LMM, I assume the same RR would need to be done with an LMM agent, unless the MN was prepared to trust the local network and not do so. Or use a BSA, as you state. A BSA would be alot better. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 12 20:23:49 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02560 for ; Tue, 12 Feb 2002 20:23:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07911; Tue, 12 Feb 2002 17:23:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27964; Tue, 12 Feb 2002 17:23:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D1MPFh012565 for ; Tue, 12 Feb 2002 17:22:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D1MPmP012564 for mobile-ip-dist; Tue, 12 Feb 2002 17:22:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D1MKFh012557 for ; Tue, 12 Feb 2002 17:22:21 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1D1MHM02200; Wed, 13 Feb 2002 02:22:18 +0100 (MET) Date: Wed, 13 Feb 2002 02:18:05 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, kempf@docomolabs-usa.com In-Reply-To: "Your message with ID" <200202121826.g1CIQFg05055@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Just because the CN has an IPsec SA with a peer that has a certificate > mbox=erik.nordmark@sun.com doesn't say anything what HoA's the peer > may issue BUs for. > > => this is a policy issue (IPsec knows what is a policy but details, > including how to use policies, are not in the IPsec WG scope). > And the policy can be encoded in the certificate: your point is > the certificate is not always enough (I parse your statement as "is > never enough"). Francis, I don't think there exists current PKIs that can provide a strong relationship between an IP address and a certificate. That doesn't mean it is impossible to develop such a PKI. But until such a PKI exists it would seem prudent to provide implementors and users of MIPv6 with accurate information on security issues, and not pretent that something which looks like "IPsec policy pixie dust" solves the problem. (Yes, "IPsec policy pixie dust" is the next step after "IPsec pixie dust" runs out :-) > => I still have to read the Home Address Option recommendation to see > if Binding Acknowledgements (BAs) are now mandatory but at least > some new error codes are to be added in BAs for fast recovery > (something like "I don't receive the message Xy"). OOps - I think the DT forgot to make a conclusion on the BA part. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 03:59:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23918 for ; Wed, 13 Feb 2002 03:59:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03364; Wed, 13 Feb 2002 01:58:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18316; Wed, 13 Feb 2002 00:58:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D8vSFh013209 for ; Wed, 13 Feb 2002 00:57:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D8vS5L013208 for mobile-ip-dist; Wed, 13 Feb 2002 00:57:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D8vPFh013201 for ; Wed, 13 Feb 2002 00:57:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18263 for ; Wed, 13 Feb 2002 00:57:26 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18859 for ; Wed, 13 Feb 2002 01:57:25 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1D8vNa24003 for ; Wed, 13 Feb 2002 09:57:23 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA20213 for ; Wed, 13 Feb 2002 09:57:20 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1D8vKg08050 for ; Wed, 13 Feb 2002 09:57:20 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202130857.g1D8vKg08050@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: (CLARIFICATION) Re: [mobile-ip] Routing headers - part 2 In-reply-to: Your message of Mon, 11 Feb 2002 22:32:24 +0100. Date: Wed, 13 Feb 2002 09:57:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: New routing header type ----------------------- The idea is to define Routing Header type 1 to be a constrained... The intent is that firewalls that block Routing Header type 0 due to perceived security issues not block Routing Header type 1 due to its much more constrained specification. Unknowns: 1. There might be some concern that the "be conservative what you accept" firewall default configurations and/or firewall administrators will fail to understand that RH type 0 and RH type 1 are conceptually different things. Hence all RH independent of type might get tossed. Summary: ... Predicting the behavior of firewall implementors and administrators is very hard. => this statement is unfair because the new type (>= 2) is defined only in order to get the proper behavior. BTW it assumes firewall implementors are very lazy because to check the type of a RH is very trivial when the existence of a RH is taken into account. (note there is no publicly available IPv6 firewall with RH support) Or the same kind of statements should be added to other alternatives (all should be dealt with by firewalls). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 04:06:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24162 for ; Wed, 13 Feb 2002 04:06:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06168; Wed, 13 Feb 2002 02:05:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19093; Wed, 13 Feb 2002 01:05:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D94aFh013316 for ; Wed, 13 Feb 2002 01:04:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D94a5L013315 for mobile-ip-dist; Wed, 13 Feb 2002 01:04:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D94WFh013308 for ; Wed, 13 Feb 2002 01:04:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18943 for ; Wed, 13 Feb 2002 01:04:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08635 for ; Wed, 13 Feb 2002 01:04:33 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1D94Ws31871 for ; Wed, 13 Feb 2002 11:04:32 +0200 Date: Wed, 13 Feb 2002 11:04:32 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 In-Reply-To: <3C69A9A7.A0317E93@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 12 Feb 2002, Jari T. Malinen wrote: > Thanks for the writeup. To participate to forming > the WG opinion, > > my favorite is the RH type 2 due to minimal change and > since I disagree that the semantical similarity to RH T0 > for fw admins would be big enough issue for them to drop > RH T2 as well. Comparing to DO, fw implementors and users > need to know something about the new DO, too. Checking for RH type needs to be there.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 04:16:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24332 for ; Wed, 13 Feb 2002 04:16:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10284; Wed, 13 Feb 2002 02:16:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20576; Wed, 13 Feb 2002 01:16:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9EgFh013379 for ; Wed, 13 Feb 2002 01:14:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1D9EgM3013378 for mobile-ip-dist; Wed, 13 Feb 2002 01:14:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1D9EdFh013371 for ; Wed, 13 Feb 2002 01:14:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28114 for ; Wed, 13 Feb 2002 01:14:41 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09518 for ; Wed, 13 Feb 2002 02:14:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1D9Eca25467 for ; Wed, 13 Feb 2002 10:14:38 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA20540 for ; Wed, 13 Feb 2002 10:14:38 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1D9Ebg08101 for ; Wed, 13 Feb 2002 10:14:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202130914.g1D9Ebg08101@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 In-reply-to: Your message of Mon, 11 Feb 2002 22:32:24 +0100. Date: Wed, 13 Feb 2002 10:14:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => look at my previous message for my motivation (the level of the firewall concerns of the new RH type is not justified IMHO). Please respond with motivation for the ones you don't AGREE with: 1. New Destination Option (AGREE/DISAGREE/CAN LIVE WITH) => CAN LIVE WITH 2. New RH Type 2 (AGREE/DISAGREE/CAN LIVE WITH) => AGREE Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 07:10:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28868 for ; Wed, 13 Feb 2002 07:10:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18555; Wed, 13 Feb 2002 04:10:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25207; Wed, 13 Feb 2002 04:09:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DC96Fh013739 for ; Wed, 13 Feb 2002 04:09:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DC95od013738 for mobile-ip-dist; Wed, 13 Feb 2002 04:09:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DC92Fh013731 for ; Wed, 13 Feb 2002 04:09:02 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04490 for ; Wed, 13 Feb 2002 04:09:03 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05573 for ; Wed, 13 Feb 2002 05:09:02 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28612; Wed, 13 Feb 2002 07:09:00 -0500 (EST) Message-Id: <200202131209.HAA28612@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-qos-requirements-02.txt Date: Wed, 13 Feb 2002 07:09:00 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Requirements of a QoS Solution for Mobile IP Author(s) : H. Chaskar Filename : draft-ietf-mobileip-qos-requirements-02.txt Pages : 7 Date : 12-Feb-02 Mobile IP ensures correct routing of packets to mobile node as the mobile node changes its point of attachment to the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-qos-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020212144020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-qos-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020212144020.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 07:50:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29891 for ; Wed, 13 Feb 2002 07:50:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23575; Wed, 13 Feb 2002 05:50:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01454; Wed, 13 Feb 2002 04:49:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DCn4Fh013854 for ; Wed, 13 Feb 2002 04:49:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DCn4Sk013853 for mobile-ip-dist; Wed, 13 Feb 2002 04:49:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DCn1Fh013846 for ; Wed, 13 Feb 2002 04:49:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09012 for ; Wed, 13 Feb 2002 04:49:03 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14204 for ; Wed, 13 Feb 2002 04:49:02 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DCmuk19202; Wed, 13 Feb 2002 13:48:57 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA24962; Wed, 13 Feb 2002 13:48:56 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DCmtg08930; Wed, 13 Feb 2002 13:48:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202131248.g1DCmtg08930@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Wed, 13 Feb 2002 01:16:19 +0100. Date: Wed, 13 Feb 2002 13:48:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > > => at least to get a open door in the BU stuff? > > Do you see a closed door anywhere? > > => BU authentication == RR [+ CGA] Huh? => this is the direct effect of the lack of a context description in the introduction of the BU recommendation. I know this doesn't really reflect the opinion of the design team but in place of a BU for random CNs recommendation you produced a BU recommendation... And the 1 bit method is another example of the lack of openness (opening?) in the wording. I've gotten the message that the MIP WG wants to get MIPv6 secure enough so that it can go to proposed standard. => we know the target so I believe the problem is only in the form. I don't think you're proposing that we delay this until there is some additional approach involving the AAA. So how does having a "do no harm" way of securing BUs prevent there from developping other ways to secure them? => it should *not* prevent from using other ways to secure them. > Would AAA be better because diameter runs over SCTP instead of IKE > over UDP? > > => this is a joke, isn't it? But I believe you are right. Some stupid > problems with IKE come from the use of UDP... No. It is a direct response to your point about IKE not performing well while AAA performing better under the same assumptions. Both protocols as I understand send a request and wait for a reply (and then repeat). => the number of exchanges, the size of messages, the complexity of crypto operations, ... many things are a bit different. So what makes their performance differ? Does IKE over UDP have a 10 second retransmit timer while SCTP/TCP have an initial retransmit timer of 2? 4? seconds? => the retransmit timer is based on the RTT but in the case we discussed about the RTT is not yet known for the first exchange which should not have large packets... I believe you are already convinced that SCTP/TCP is better even on first packets than any raw heuristic for UDP, aren't you? > About the real topic of this discussion: what is scheduled in the future > document about alternative BU authentications, including all the known > infrastructure based and/or for home registrations? "scheduled"? => I maintain. The WG does need to come to consensus on how to secure home registrations. => what we need is the list of necessary security properties (easy, this is already in the mobile IPv6 I-D), a way to provide it (a MAY for something which can work or better was proved to work) *and* explicit possibility for any mechanism which can/shall provide the needed security properties. To be allowed to use them for common BUs will be fine (this is the reversed argument of "RR [+ CGA] secures BUs but doesn't apply to the HR special case). I'm assuming the WG neither wants to hold up the MIPv6 specification while infrastructure-based methods are developped, nor prevent such methods from being developped and added to the stew. => so we agree about everything at the exception of a minor point: at least one infrastructure-based method already exists: IPsec (with IKE, KINK, etc) so please give an easy way to add something to the stew (a statement with careful wording should be enough). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 08:19:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00581 for ; Wed, 13 Feb 2002 08:19:06 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06931; Wed, 13 Feb 2002 06:18:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11611; Wed, 13 Feb 2002 05:18:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DDHpFh013993 for ; Wed, 13 Feb 2002 05:17:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DDHo3l013992 for mobile-ip-dist; Wed, 13 Feb 2002 05:17:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DDHkFh013985 for ; Wed, 13 Feb 2002 05:17:47 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1DDHfM28730; Wed, 13 Feb 2002 14:17:41 +0100 (MET) Date: Wed, 13 Feb 2002 14:13:30 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com In-Reply-To: "Your message with ID" <200202131248.g1DCmtg08930@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => it should *not* prevent from using other ways to secure them. We're in violent agreement on that. > No. It is a direct response to your point about IKE not performing well > while AAA performing better under the same assumptions. > Both protocols as I understand send a request and wait for a reply > (and then repeat). > > => the number of exchanges, the size of messages, the complexity of > crypto operations, ... many things are a bit different. But that has presumably some relationship to the resulting security. True that IKE might be too complex but if comparing the son-of-ike proposals against AAA-based SA establishment I would think they would have the same number of messages and same computational complexity to accomplish the same security. If not it seems like AAA-based SA establishement would have some magic potion that should be shared with the son-of-ike folks. And if AAA-based SA establishment can't provide the same level of security that son-of-ike SA estblishment can, then I think we should be very concerned. > => the retransmit timer is based on the RTT but in the case we discussed > about the RTT is not yet known for the first exchange which should not > have large packets... I believe you are already convinced that SCTP/TCP > is better even on first packets than any raw heuristic for UDP, aren't you? No - not for a single request-response interaction. E.g. Single DNS lookups over UDP are better than over TCP - less packets and less residual state. Sure, the implementation of the retransmit timer logic becomes application protocol specific instead of shared e.g. in TCP which places more responsibility on the application protocol and developper. Of course, when there is either a need to have multiple outstanding messages (as opposed to a request-wait-for-response model), when the requests or responses are larger than what fits in one datagram, or when there will be a long conversation, then SCTP/TCP makes more sense. > => so we agree about everything at the exception of a minor point: > at least one infrastructure-based method already exists: IPsec > (with IKE, KINK, etc) so please give an easy way to add something > to the stew (a statement with careful wording should be enough). For home registrations I personally think IPsec is a very good fit. But I think you are referring to using IPsec to secure BUs to CNs as well in lieu of using RR. Are you? The fact that there isn't an automatic way to establish the authorization policy in the CN case makes me wonder how wise it would be to do that. (Yes, the policy can of course be manually created by people with a good understanding of the authorization issues, but that wouldn't help mere mortals.) I'd feel differently about this if/when there is work in the IETF in using DNSSEC on the ip6.arpa tree to store certificates or public keys since then there would be a way to automate this. But it seems to be mostly you and I having opinions on this. I'd also be interested in what others think. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 10:06:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06041 for ; Wed, 13 Feb 2002 10:06:24 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18625; Wed, 13 Feb 2002 07:06:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07263; Wed, 13 Feb 2002 07:05:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DF4eFh014167 for ; Wed, 13 Feb 2002 07:04:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DF4eZn014166 for mobile-ip-dist; Wed, 13 Feb 2002 07:04:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DF4aFh014159 for ; Wed, 13 Feb 2002 07:04:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27265 for ; Wed, 13 Feb 2002 07:04:38 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13199 for ; Wed, 13 Feb 2002 08:04:32 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id <1L6R3DYZ>; Wed, 13 Feb 2002 09:58:10 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] IPR notice relevant to CGA Date: Wed, 13 Feb 2002 09:58:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This was posted today: http://www.ietf.org/ietf/IPR/MICROSOFT-MOBILEIP-UPDATEAUTH.txt From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 10:18:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07088 for ; Wed, 13 Feb 2002 10:18:45 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26212; Wed, 13 Feb 2002 08:18:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10142; Wed, 13 Feb 2002 07:18:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DFHDFh014222 for ; Wed, 13 Feb 2002 07:17:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DFHDbN014221 for mobile-ip-dist; Wed, 13 Feb 2002 07:17:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DFH9Fh014214 for ; Wed, 13 Feb 2002 07:17:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03698 for ; Wed, 13 Feb 2002 07:17:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22599 for ; Wed, 13 Feb 2002 08:17:08 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA17931 for ; Wed, 13 Feb 2002 07:17:03 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DFH3s21928 for ; Wed, 13 Feb 2002 07:17:03 -0800 X-mProtect:  Wed, 13 Feb 2002 07:17:03 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7DJwVw; Wed, 13 Feb 2002 07:17:01 PST Message-ID: <3C6A8309.C4ED582F@iprg.nokia.com> Date: Wed, 13 Feb 2002 07:15:21 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 References: <200202130914.g1D9Ebg08101@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, Here are my responses. > Please respond with motivation for the ones you don't AGREE with: > 1. New Destination Option (AGREE/DISAGREE/CAN LIVE WITH) Won't kill me. I've already sent out quite a lot of motivation about why I would not like this option. > 2. New RH Type 2 (AGREE/DISAGREE/CAN LIVE WITH) Agree, unless we can have RH type 0 instead which is easier. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 10:37:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07780 for ; Wed, 13 Feb 2002 10:37:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02143; Wed, 13 Feb 2002 08:37:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14160; Wed, 13 Feb 2002 07:37:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DFaKFh014328 for ; Wed, 13 Feb 2002 07:36:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DFaKMw014327 for mobile-ip-dist; Wed, 13 Feb 2002 07:36:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DFaHFh014320 for ; Wed, 13 Feb 2002 07:36:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07906 for ; Wed, 13 Feb 2002 07:36:19 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29175 for ; Wed, 13 Feb 2002 08:36:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DFaAk10931; Wed, 13 Feb 2002 16:36:10 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA29300; Wed, 13 Feb 2002 16:36:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DFa6g09557; Wed, 13 Feb 2002 16:36:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202131536.g1DFa6g09557@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, kempf@docomolabs-usa.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Wed, 13 Feb 2002 02:18:05 +0100. Date: Wed, 13 Feb 2002 16:36:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => this is a policy issue (IPsec knows what is a policy but details, > including how to use policies, are not in the IPsec WG scope). > And the policy can be encoded in the certificate: your point is > the certificate is not always enough (I parse your statement as "is > never enough"). I don't think there exists current PKIs that can provide a strong relationship between an IP address and a certificate. => not only they exist but when the IKE phase 1 uses address identities (very common, the default mode of every IKE implementations I know because it is needed for pre-shared keys in main mode) the address must be the subject(Alt)Name of the certificate. This is checked for all compliant IKE implementations and all good implementations check too if the address in the identity and the address used for IKE messages are the same (a trivial attack if not performed). That doesn't mean it is impossible to develop such a PKI. => fortunately (:-)! But until such a PKI exists it would seem prudent to provide implementors and users of MIPv6 with accurate information on security issues, and not pretent that something which looks like "IPsec policy pixie dust" solves the problem. (Yes, "IPsec policy pixie dust" is the next step after "IPsec pixie dust" runs out :-) => yes, there are better positions than FUD or hype... (:-) Don't forget that the "road warrior" case is supported by many IPsec implementations so this is more a question of how protocols are (mis)used than about protocols themselves. OOps - I think the DT forgot to make a conclusion on the BA part. => I'd like to know the opinion of the DT about BA security requirements (BA of HR must be authenticated, but other BAs?) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:09:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09258 for ; Wed, 13 Feb 2002 11:09:57 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21750; Wed, 13 Feb 2002 09:09:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22154; Wed, 13 Feb 2002 08:09:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DG8eFh014446 for ; Wed, 13 Feb 2002 08:08:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DG8e72014445 for mobile-ip-dist; Wed, 13 Feb 2002 08:08:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DG8bFh014438 for ; Wed, 13 Feb 2002 08:08:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21942 for ; Wed, 13 Feb 2002 08:08:39 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18903 for ; Wed, 13 Feb 2002 09:08:38 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 104A981D for ; Wed, 13 Feb 2002 10:08:38 -0600 (CST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 01131CA3 for ; Wed, 13 Feb 2002 08:08:37 -0800 (PST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DG8Zk10604; Wed, 13 Feb 2002 11:08:35 -0500 (EST) From: Brian Haley USG Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA03120; Wed, 13 Feb 2002 11:08:35 -0500 Message-Id: <200202131608.AA03120@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 Date: Wed, 13 Feb 2002 11:08:35 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Please respond with motivation for the ones you don't AGREE with: > 1. New Destination Option (AGREE/DISAGREE/CAN LIVE WITH) CAN LIVE WITH, but with a restriction that it must be alone in a DO w/only HAO if necessary. > 2. New RH Type 1 (AGREE/DISAGREE/CAN LIVE WITH) AGREE -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:21:27 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10436 for ; Wed, 13 Feb 2002 11:21:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25853; Wed, 13 Feb 2002 09:21:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10940; Wed, 13 Feb 2002 08:20:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGJvFh014672 for ; Wed, 13 Feb 2002 08:19:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGJvsX014671 for mobile-ip-dist; Wed, 13 Feb 2002 08:19:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGJsFh014664 for ; Wed, 13 Feb 2002 08:19:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10580 for ; Wed, 13 Feb 2002 08:19:56 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02194 for ; Wed, 13 Feb 2002 08:19:56 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DGJrt26307 for ; Wed, 13 Feb 2002 10:19:54 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <15N0L6NQ>; Wed, 13 Feb 2002 10:19:53 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E020AA786@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: CONCLUSION: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 13 Feb 2002 10:19:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4AA.44AAD190" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4AA.44AAD190 Content-Type: text/plain; charset="ISO-8859-1" I disagree with this conclusion and I find it very sad indeed that the IETF has knelt before the link layers. Especially when the link layers won't even do the route optimization as a mandate. You might was well move the MIP work to one of the other SDO's if this kind of decision making continues. Very very sad indeed. Shame on the DT, IMHO. Glenn > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Tuesday, February 12, 2002 10:52 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Piggybacking - DT recommendation > > > > Hello folks, > > We need to get closure on the Working Group's stance on > piggybacking of binding update messages. Much of the > discussion last year was around the issue that doing so > generally meant that IPsec specifications and implementations > needed some modifications in order to protect BU messages that > were piggybacked in other messages. Other discussions were > around the relative merits of piggybacking in terms of > performance of particular kinds of link layers, whether > beneficial or harmful. Still other discussions were around > the complexity of implementing it in the receiver. > > This note is an attempt to summarize the pros and cons > of the various approaches and to give a design team > recommendation. The summary is more difficult because > there was little agreement in the earlier discussions on > whether the asserted benefits were real. In fact, it > doesn't seem there was agreement on ANY of the asserted > pros and cons below, except that it would be difficult to > add the function later. > > Jari documented the tradeoffs of using piggybacking > with IPSEC well in: > > http://search.ietf.org/internet-drafts/draft-arkko-mipv6-bu-se > curity-01.txt > > In Salt Lake City a set of options was put before the > working group. The option to leave piggybacking in the > draft without comment on its merits was favored by no one. > The other options were as listed below. > > I would like you to comment on each whether you AGREE, > DISAGREE, or CAN LIVE WITH the option. > > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. > > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible > Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > > 2. Specify that piggybacking always be an option. > > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > > Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links > Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node > > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > > (c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. > > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. > > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. > > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. > > > Phil > > ------_=_NextPart_001_01C1B4AA.44AAD190 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable CONCLUSION: [mobile-ip] Piggybacking - DT recommendation

I disagree with this conclusion and I find it very = sad indeed that the IETF has knelt before the link layers. Especially = when the link layers won't even do the route optimization as a = mandate.  You might was well move the MIP work to one of the other = SDO's if this kind of decision making continues.

Very very sad indeed. Shame on the DT, IMHO.

Glenn

> -----Original Message-----
> From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
> Sent: Tuesday, February 12, 2002 10:52 = AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: [mobile-ip] Piggybacking - DT = recommendation
>
>
>
> Hello folks,
>
>     We need to get closure = on the Working Group's stance on
> piggybacking of binding update messages.  = Much of the
> discussion last year was around the issue that = doing so
> generally meant that IPsec specifications and = implementations
> needed some modifications in order to protect = BU messages that
> were piggybacked in other messages.  Other = discussions were
> around the relative merits of piggybacking in = terms of
> performance of particular kinds of link layers, = whether
> beneficial or harmful.  Still other = discussions were around
> the complexity of implementing it in the = receiver.
>
>     This note is an attempt = to summarize the pros and cons
> of the various approaches and to give a design = team
> recommendation.  The summary is more = difficult because
> there was little agreement in the earlier = discussions on
> whether the asserted benefits were real.  = In fact, it
> doesn't seem there was agreement on ANY of the = asserted
> pros and cons below, except that it would be = difficult to
> add the function later.
>
>     Jari documented the = tradeoffs of using piggybacking
> with IPSEC well in:
>
> http://search.ietf.org/internet-drafts/draft-arkko-mip= v6-bu-se
> curity-01.txt
>
> In Salt Lake City a set of options was put = before the
> working group.  The option to leave = piggybacking in the
> draft without comment on its merits was favored = by no one.
> The other options were as listed below.
>
> I would like you to comment on each whether you = AGREE,
> DISAGREE, or CAN LIVE WITH the option.
>
> 1. Specify that piggybacking of binding update = messages not
>    be used with MIP v6.
>
> Pros:
>         = - puts no constraints on using IPSEC to protect
>          = ; binding updates when possible
> Cons:
>         = - if the function is added later, some negotiation
>          = ; would be needed between the sender and receiver
>          = ; since all receivers would not be able to support
>          = ; it
>
> 2. Specify that piggybacking always be an = option.
>
> Pros:
>         = - allows some improvement in terms of throughput
>          = ; and latency that may be relevant on certain types
>          = ; of links
> Cons:
>         = - the improvements are only relevant on certain
>          = ; types of links and thus this is inclusion of
>          = ; functionality at layer 3 that is useful only for
>          = ; certain layer 2s
>          = ;
>         = - in cases where the functionality is detrimental
>          = ; on certain kinds of links, the receiver may be
>          = ; victimized when sent a piggybacked BU
>          = ;
>         = - need policy extensions to IPSEC (and
>          = ; corresponding implementation modifications) for
>          = ; those cases in which IPSEC is used to protect
>          = ; BUs.
>
> 3. Specify that piggybacking is an option, but = subject to
>    negotiation between the two = communicating nodes.
>
> Pros:
>         = - may be able to eliminate the detrimental effects
>          = ; on stations on certain kinds of links
> Cons:
>         = - requires some more specification of signalling on
>          = ; whether or not to use piggybacking and
>          = ; additional behavior in the mobile node
>
> The DT has come to the following = conclusions:
>
> (a) For reasons of timing, we do not recommend = extending
>     IPsec specifications in = any manner.  Therefore, we feel
>     that approaches that = rely on better IPsec policy
>     granularity should not = be considered.
>
> (b) We recommend that when IPsec protection is = used, it is
>     always used in = *addition* to RR (or CGA) methods, not as
>     a replacement. Thus RR = (or CGA) methods would be used to
>     protect MN - CN Route = optimization procedures even when IPsec
>     is used.
>
> (c) Binding update messages for both HAs and = CNs, binding
>     acks, RR messaging, and = CGA messaging are to be
>     implemented as a new = message set without the ability
>     to piggyback data = packets on those messages
>
>     The basis on this = recommendation is as follows:
>
>       - The DT = recognizes the potential benefits of piggybacking.
>         = (However, link layer techniques may exist to migitate
>         = the disadvantages of sending separate packets, to
>         = some extent.)
>
>       - MIPv6 = control packets are needed between MN - HA,
>         = MN - CN, and CN - HA - MN. There is no piggybacking
>         = policy granularity problem in the MN - CN case, due
>         = to recommendation (b). However, if piggybacking is
>         = used for the MN - HA case either IPsec specifications
>         = would have to be extended, or mechanisms similar to
>         = those introduced in draft 14 would have to be employed.
>
>       - The = deciding factor, however, seems to be the protection
>         = we need for RR (or to a smaller extent CGA) messages
>         = on the CN - HA - MN path. Given that the HA is acting
>         = only as a router in this case, it can not insert DOs
>         = in the RR packets since that violates fundamental
>         = assumptions needed e.g. for Path MTU discovery, and
>         = draft 14 mechanisms wouldn't be able to provide the
>         = necessary encryption anyway. Therefore, it seems necessary
>         = to provide ESP-like functionality in any case for the MNs
>         = and HAs. Based on this, it would make sense to use the same
>         = mechanism also for BU protection.
>
>       - It seems = very useful to be able to use IPsec ESP (with
>         = manual keying) for protecting the RR control packets
>         = on the HA-MN path. If the IPsec selectors can't be used
>         = to distinguish those packets from data traffic the effect
>         = might be that lots of data packets (all that are tunneled
>         = through the HA) also become encrypted which would be a
>         = source of performance concerns for limited MN devices.
>
>       - Some BU = authorization mechanisms, namely those based
>         = on Diffie-Hellman and/or CGA, may not fit IPv6 DOs.
>
>
> Phil
>
>

------_=_NextPart_001_01C1B4AA.44AAD190-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:27:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10607 for ; Wed, 13 Feb 2002 11:27:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01475; Wed, 13 Feb 2002 09:27:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12167; Wed, 13 Feb 2002 08:27:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGQHFh014721 for ; Wed, 13 Feb 2002 08:26:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGQHSs014720 for mobile-ip-dist; Wed, 13 Feb 2002 08:26:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGQDFh014713 for ; Wed, 13 Feb 2002 08:26:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20042 for ; Wed, 13 Feb 2002 08:26:15 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25853 for ; Wed, 13 Feb 2002 09:26:14 -0700 (MST) Received: from jariws1 ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020213162531.EQER6990.fep07-app.kolumbus.fi@jariws1>; Wed, 13 Feb 2002 18:25:31 +0200 Message-ID: <02dc01c1b4ab$2781a660$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Erik Nordmark" , Cc: , References: <200202131536.g1DFa6g09557@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Wed, 13 Feb 2002 18:26:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => I'd like to know the opinion of the DT about BA security requirements > (BA of HR must be authenticated, but other BAs?) It seems that you are right about the HR_BA: if a BA could be forged, an attacker could cause an *unnoticeable* DoS by preventing a BU from getting through and then forging a response... hmm... except that if we *encrypt* the BU and it has a random cookie. So, we need either (a) authenticated BA OR (b) BU encryption AND BU/BA cookie. In the CN case, the MN must in any case be prepared for its BCE being thrown out for resource or other reasons, and the effect of the attack is the same as for that. Therefore, it seems that at most the attackers can cause performance problems but not a full DoS. I would say we need CN_BA authentication if we get it easily, but if we have to pay a price in some form to get it, we shouldn't bother. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:29:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10673 for ; Wed, 13 Feb 2002 11:29:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00616; Wed, 13 Feb 2002 09:29:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12589; Wed, 13 Feb 2002 08:29:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGSPFh014774 for ; Wed, 13 Feb 2002 08:28:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGSPhW014773 for mobile-ip-dist; Wed, 13 Feb 2002 08:28:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGSMFh014766 for ; Wed, 13 Feb 2002 08:28:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12535 for ; Wed, 13 Feb 2002 08:28:24 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06186 for ; Wed, 13 Feb 2002 08:28:23 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DGSLk17933 for ; Wed, 13 Feb 2002 17:28:21 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA00763 for ; Wed, 13 Feb 2002 17:28:22 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DGSLg09842 for ; Wed, 13 Feb 2002 17:28:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202131628.g1DGSLg09842@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 In-reply-to: Your message of Wed, 13 Feb 2002 11:04:32 +0200. Date: Wed, 13 Feb 2002 17:28:21 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Checking for RH type needs to be there.. => from the advanced API draft: /* Routing header */ struct ip6_rthdr { uint8_t ip6r_nxt; /* next header */ uint8_t ip6r_len; /* length in units of 8 octets */ uint8_t ip6r_type; /* routing type */ uint8_t ip6r_segleft; /* segments left */ /* followed by routing type specific data */ }; A firewall needs to look at ip6r_nxt (in order to process the next header or the payload), at ip6r_len (in order to find the next header or the payload). To stop there, i.e. not to look at ip6r_type, can be considered as an insult to firewall programmers (note you can't use the backward compatibility argument because no publicly available IPv6 firewall deals with routing headers, i.e. do something else than skip/ignore the header in payload chasing). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:30:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10720 for ; Wed, 13 Feb 2002 11:30:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28505; Wed, 13 Feb 2002 09:30:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12828; Wed, 13 Feb 2002 08:30:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGTEFh014794 for ; Wed, 13 Feb 2002 08:29:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGTEUq014793 for mobile-ip-dist; Wed, 13 Feb 2002 08:29:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGTAFh014783 for ; Wed, 13 Feb 2002 08:29:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12601 for ; Wed, 13 Feb 2002 08:29:12 -0800 (PST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06552 for ; Wed, 13 Feb 2002 08:29:12 -0800 (PST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id E34F8AC9 for ; Wed, 13 Feb 2002 08:32:53 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 276121674 for ; Wed, 13 Feb 2002 10:29:10 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DGT9k13653; Wed, 13 Feb 2002 11:29:09 -0500 (EST) From: Brian Haley USG Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DGT9b24461; Wed, 13 Feb 2002 11:29:09 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA03164; Wed, 13 Feb 2002 11:29:09 -0500 Message-Id: <200202131629.AA03164@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation Date: Wed, 13 Feb 2002 11:29:08 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS I guess I could live with this, performance will suffer of course, but... > A HAO with no matching BCE entry generates an ICMP error > message. The message is sent to the source of the packet, > i.e. the CoA. This guarantees that there will be no additional > reflection problems because of this. Don't a lot of firewalls today drop ICMP packets? How is the MN supposed to know the CN even got the packet if it's behind one, it might just keep retrying, until it eventually stops trying to communicate (figures the CN is dead), or falls-back to reverse-tunneling through its HA. -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:40:06 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10967 for ; Wed, 13 Feb 2002 11:40:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12195; Wed, 13 Feb 2002 08:39:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14843; Wed, 13 Feb 2002 08:39:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGcvFh015078 for ; Wed, 13 Feb 2002 08:38:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGcvet015077 for mobile-ip-dist; Wed, 13 Feb 2002 08:38:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGcqFh015070 for ; Wed, 13 Feb 2002 08:38:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14721 for ; Wed, 13 Feb 2002 08:38:55 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01279 for ; Wed, 13 Feb 2002 09:38:53 -0700 (MST) Received: from jariws1 ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020213163810.ERUR6990.fep07-app.kolumbus.fi@jariws1>; Wed, 13 Feb 2002 18:38:10 +0200 Message-ID: <032701c1b4ac$ec24e4e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Brian Haley USG" Cc: References: <200202131629.AA03164@dogbert.zk3.dec.com> Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation Date: Wed, 13 Feb 2002 18:38:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > A HAO with no matching BCE entry generates an ICMP error > > message. The message is sent to the source of the packet, > > i.e. the CoA. This guarantees that there will be no additional > > reflection problems because of this. > > Don't a lot of firewalls today drop ICMP packets? How is the MN > supposed to know the CN even got the packet if it's behind one, > it might just keep retrying, until it eventually stops trying to > communicate (figures the CN is dead), or falls-back to reverse-tunneling > through its HA. Good point, we didn't think of this! Do you have an understanding how widespread that practise is? Also, do we have other functionality where connectivity depends on ability to get through ICMP packets? For instance, with v4, fragmentation was handled by routers but in v6 we have e2e fragmentation and ICMP Packet Too Big. This would appear to have a similar problem, i.e. you wouldn't get anywhere that has a 1280 byte MTU if your local link was 1500 bytes. Anything else similar, and do we have experience on how well or bad this works in practise? As an alternative we could also specify a MIPv6 specific message to say the same thing as the ICMP ;-) which sounds a bit like the arguments in the RH case. Except this time the fear is ICMP, not RH. Could Binding Request be used for this purpose, with some flag? Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:57:57 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11558 for ; Wed, 13 Feb 2002 11:57:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17436; Wed, 13 Feb 2002 08:57:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29214; Wed, 13 Feb 2002 08:57:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGuoFh015216 for ; Wed, 13 Feb 2002 08:56:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGuoDs015215 for mobile-ip-dist; Wed, 13 Feb 2002 08:56:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGulFh015208 for ; Wed, 13 Feb 2002 08:56:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04763 for ; Wed, 13 Feb 2002 08:56:50 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14222 for ; Wed, 13 Feb 2002 09:56:49 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1DGumhM029014 for ; Wed, 13 Feb 2002 17:56:48 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Feb 13 17:56:41 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 17:56:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA07@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 17:56:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Charlie, This is not an attempt to start another long thread about the benefits of piggybacking but I would like make a couple of points that I think might help: 1. Since the current recommendation seems to be: Mandate RR and optionally CGA on top later. And since it is recommended that RR does not setup a BSA, where is the issue of piggybacking if you use RR only? Something like BU3WAY runs the entire protocol on ICMP, so you can't piggyback these meesages anyway. Where is the issue? 2. So far we've seen a concrete paper from Cedric and yourself which upon discussion didn't not result in any significant advantage of piggybacking the BU (please refer to the archives, thread: 'more on piggybacking'). So I really don't see why you're against this decision. These are the 2 main comments. I have a couple of specific ones below. > That is a very important point. Regarding the "asserted" > benefits, I think it can be shown that piggybacking _always_ > offers performance benefits to a compliant IPv6 implementation, > and that sometimes the benefits would enable important > applications (like voice) to work better. => Interesting, because I can negate the exact argument with examples. But the paper which you co-authored essentially concluded that: - 'Don't go to war over BW efficiency of piggybacking'. - Piggybacking is good to reduce jitter during a handover. Upon discussing the second point in the thread I mentioned, we saw that certain assumptions were made regarding the link layer configuration (of a cellular link) that were not accurate (please refer to the thread). So I'm still not sure about what the benefits are. > > - in cases where the functionality is detrimental > > on certain kinds of links, the receiver may be > > victimized when sent a piggybacked BU > > There are not any such links that correctly implement IPv6 > MTU. => What does this mean?? There are no link layers that follow RFC2460? > The complete answer about how to use IPsec is going to take more > effort than we can muster in the near term. Such effort SHOULD > take into account the particular needs of Mobile IPv6 BSAs, > anyway. I think that we should NOT go back to using only AH, > especially because AH itself is likely to be deprecated in > the future. => I don't think the comment was related to securing BUs with IPsec, but simply _using_ IPsec. Surely we can't leave that out. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 11:59:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12585 for ; Wed, 13 Feb 2002 11:59:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18335; Wed, 13 Feb 2002 09:59:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00034; Wed, 13 Feb 2002 08:59:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGwcFh015259 for ; Wed, 13 Feb 2002 08:58:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DGwc16015258 for mobile-ip-dist; Wed, 13 Feb 2002 08:58:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DGwZFh015251 for ; Wed, 13 Feb 2002 08:58:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05395 for ; Wed, 13 Feb 2002 08:58:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15255 for ; Wed, 13 Feb 2002 09:58:36 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g1DGwZH03313 for ; Wed, 13 Feb 2002 18:58:35 +0200 Date: Wed, 13 Feb 2002 18:58:34 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 In-Reply-To: <200202131628.g1DGSLg09842@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, 13 Feb 2002, Francis Dupont wrote: > => from the advanced API draft: > > /* Routing header */ > struct ip6_rthdr { > uint8_t ip6r_nxt; /* next header */ > uint8_t ip6r_len; /* length in units of 8 octets */ > uint8_t ip6r_type; /* routing type */ > uint8_t ip6r_segleft; /* segments left */ > /* followed by routing type specific data */ > }; > > A firewall needs to look at ip6r_nxt (in order to process the next > header or the payload), at ip6r_len (in order to find the next header > or the payload). To stop there, i.e. not to look at ip6r_type, can > be considered as an insult to firewall programmers Code itself isn't difficult, but people may argue they don't want a every possible knob and detail to be checkable.. syntax for e.g. ip6fw(8) is rather complicated already :-) >(note you can't > use the backward compatibility argument because no publicly available > IPv6 firewall deals with routing headers, i.e. do something else than > skip/ignore the header in payload chasing). Incorrect: ip6fw can drop packets which contain RH (or any header type). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:09:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13542 for ; Wed, 13 Feb 2002 12:09:05 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20924; Wed, 13 Feb 2002 10:08:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03382; Wed, 13 Feb 2002 09:08:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DH7oFh015351 for ; Wed, 13 Feb 2002 09:07:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DH7oET015350 for mobile-ip-dist; Wed, 13 Feb 2002 09:07:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DH7kFh015343 for ; Wed, 13 Feb 2002 09:07:46 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03194 for ; Wed, 13 Feb 2002 09:07:49 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14885 for ; Wed, 13 Feb 2002 09:07:47 -0800 (PST) Received: from jariws1 ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020213170705.EVBN6990.fep07-app.kolumbus.fi@jariws1>; Wed, 13 Feb 2002 19:07:05 +0200 Message-ID: <038f01c1b4b0$f57df140$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Vijay Devarapalli" , , References: <3C696A4F.8653C362@iprg.nokia.com> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 13 Feb 2002 19:07:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > (b) We recommend that when IPsec protection is used, it is > > always used in *addition* to RR (or CGA) methods, not as > > a replacement. Thus RR (or CGA) methods would be used to > > protect MN - CN Route optimization procedures even when IPsec > > is used. > > DISAGREE strongly with this. In the first place, I dont > understand why this is there in the Piggybacking > recommendation. When there is an IPSec SA between > an MN and CN (could have been created statically for > all you know), there is no need to run either RR or > RR+CGA. Apparently we disagree about the likelihood of having the kind of private manual SAs that - I agree - would be sufficient for authorization. But let me ask you a question to clarify your position. Let's *not* discuss for the moment if SAs are sufficient. But why do are you opposed to the in-addition recommendation? Is it because of additional signaling or some other reason? Implementation-wise, I would have thought it'd be easier if you didn't need to know if you had IPsec at the bottom. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:10:56 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14035 for ; Wed, 13 Feb 2002 12:10:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26164; Wed, 13 Feb 2002 10:10:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03932; Wed, 13 Feb 2002 09:10:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DH9jFh015386 for ; Wed, 13 Feb 2002 09:09:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DH9jCt015385 for mobile-ip-dist; Wed, 13 Feb 2002 09:09:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DH9fFh015378 for ; Wed, 13 Feb 2002 09:09:42 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22465 for ; Wed, 13 Feb 2002 09:09:44 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25954 for ; Wed, 13 Feb 2002 09:09:44 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DH9gY27100 for ; Wed, 13 Feb 2002 11:09:42 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MB40J4Q>; Wed, 13 Feb 2002 11:09:42 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E020AA959@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 11:09:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4B1.39D70B10" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4B1.39D70B10 Content-Type: text/plain; charset="iso-8859-1" Charlie, I agree with your TECHNICAL statement below; furthermore, I see conclusions as being invalidated based upon your reasoning. regards, Glenn > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. DISAGREE. > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible With authentication data as part of the Binding Update, this is not an issue. > ------_=_NextPart_001_01C1B4B1.39D70B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Charlie,

I agree with your TECHNICAL statement below; = furthermore, I see conclusions as being invalidated based upon your = reasoning.

regards,

Glenn


> 1. Specify that piggybacking of binding update = messages not
>    be used with MIP v6.

DISAGREE.

> Pros:
>         = - puts no constraints on using IPSEC to protect
>          = ; binding updates when possible

With authentication data as part of the Binding = Update, this
is not an issue.
>

------_=_NextPart_001_01C1B4B1.39D70B10-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:14:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14229 for ; Wed, 13 Feb 2002 12:14:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23894; Wed, 13 Feb 2002 10:13:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05341; Wed, 13 Feb 2002 09:13:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHDDFh015447 for ; Wed, 13 Feb 2002 09:13:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHDDGu015446 for mobile-ip-dist; Wed, 13 Feb 2002 09:13:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHD9Fh015439 for ; Wed, 13 Feb 2002 09:13:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11069 for ; Wed, 13 Feb 2002 09:13:12 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20150 for ; Wed, 13 Feb 2002 10:13:11 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1DHDAhM003800 for ; Wed, 13 Feb 2002 18:13:10 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Feb 13 18:13:03 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:03:42 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA08@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] BU Authorization method: design team recommendati on Date: Wed, 13 Feb 2002 18:12:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > I'm thinking about securing paging and maybe other kinds of > IPv6 signaling, like ND. I think CGAs or something similar > may have some applicablity here, RR certainly doesn't. Or > maybe BSAs, though that seems too heavyweight. > > As for LMM, I assume the same RR would need to be done > with an LMM agent, unless the MN was prepared to > trust the local network and not do so. Or use a BSA, > as you state. A BSA would be alot better. => A BSA would require something more than RR (see the residual threats draft and Pekka N email about these types of attacks). This is one of the reason for suggesting CGAs to be done in the context of MIP ASAP the current WG drafts are unlikely to proceed or perform as we would like them to (FMIP HMIP ...etc) unless we have a stronger solution for security. I'm pretty sure this WG does not want to go through another rework of all drafts because we didn't consider the security solutions for each one. I'm not saying put CGAs in the MIPv6 standard, but let's make sure the 'option' is standardised ASAP so we can move on. Hesham > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:36:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14888 for ; Wed, 13 Feb 2002 12:36:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09585; Wed, 13 Feb 2002 10:36:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12625; Wed, 13 Feb 2002 09:36:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHZJFh015571 for ; Wed, 13 Feb 2002 09:35:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHZJ14015570 for mobile-ip-dist; Wed, 13 Feb 2002 09:35:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHZFFh015563 for ; Wed, 13 Feb 2002 09:35:15 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28234 for ; Wed, 13 Feb 2002 09:35:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08069 for ; Wed, 13 Feb 2002 09:35:17 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DHZEk26613; Wed, 13 Feb 2002 18:35:14 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA02454; Wed, 13 Feb 2002 18:35:14 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DHZDg10269; Wed, 13 Feb 2002 18:35:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202131735.g1DHZDg10269@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Jari Arkko , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Wed, 13 Feb 2002 14:13:30 +0100. Date: Wed, 13 Feb 2002 18:35:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => it should *not* prevent from using other ways to secure them. We're in violent agreement on that. => so this topic is closed. > => the number of exchanges, the size of messages, the complexity of > crypto operations, ... many things are a bit different. But that has presumably some relationship to the resulting security. => yes of course. DoS resistance, identity protection, ... can/should be different. True that IKE might be too complex but if comparing the son-of-ike proposals against AAA-based SA establishment I would think they would have the same number of messages and same computational complexity to accomplish the same security. => agree If not it seems like AAA-based SA establishement would have some magic potion that should be shared with the son-of-ike folks. => the magic potion is from a small village of Brittany (:-) And if AAA-based SA establishment can't provide the same level of security that son-of-ike SA establishment can, then I think we should be very concerned. => I don't believe in 100% equivalence (i.e. there are some reasons to work on the two protocols). AAA can have an advantage if AAA *and* SoI are required (this is the KINK argument in fact). > => the retransmit timer is based on the RTT but in the case we discussed > about the RTT is not yet known for the first exchange which should not > have large packets... I believe you are already convinced that SCTP/TCP > is better even on first packets than any raw heuristic for UDP, > aren't you? No - not for a single request-response interaction. => this is the only case and you have to assume no cached knowledge (i.e. it should be the very first exchange). As I don't like the idea of SA establishment in a single exchange in this case (because the security cannot be as strong as I'd like), and you too (:-), SCTP/TCP should be better. E.g. Single DNS lookups over UDP are better than over TCP - => BTW DNS is the only application in this case (:-). I expect you'll never say the same thing for NFS... less packets and less residual state. Sure, the implementation of the retransmit timer logic becomes application protocol specific instead of shared e.g. in TCP which places more responsibility on the application protocol and developper. => I still wait for a TCP like in applications as good as the real one, and you loose the sharing too. Of course, when there is either a need to have multiple outstanding messages (as opposed to a request-wait-for-response model), when the requests or responses are larger than what fits in one datagram, or when there will be a long conversation, then SCTP/TCP makes more sense. => one time I believed in TTCP... To come back to DNS, the retry stuff is very different between the server (for the "recursive" feature) and the resolver. BTW usually the resolver is a *stub* resolver (:-). > => so we agree about everything at the exception of a minor point: > at least one infrastructure-based method already exists: IPsec > (with IKE, KINK, etc) so please give an easy way to add something > to the stew (a statement with careful wording should be enough). For home registrations I personally think IPsec is a very good fit. But I think you are referring to using IPsec to secure BUs to CNs as well in lieu of using RR. Are you? => I'd like to get IPsec for HRs (we agree) and as HRs are special cases of BUs to be allowed to use same things for BUs in the general case (aka random CNs). As the security requirements for HRs are stronger than for BUs, there is *no* security issue with my demand. The fact that there isn't an automatic way to establish the authorization policy in the CN case makes me wonder how wise it would be to do that. => HAs have exactly the same authorization needs (even more in fact). (Yes, the policy can of course be manually created by people with a good understanding of the authorization issues, but that wouldn't help mere mortals.) => I understand your concern, you can add warnings in the RFC about this but please don't use extreme measures to avoid this authorization issue. I'd feel differently about this if/when there is work in the IETF in using DNSSEC on the ip6.arpa tree to store certificates or public keys since then there would be a way to automate this. => the problems of DNSSEC are mainly operational so the work is mostly done outside the IETF. It will be the same when the AAA infrastructure will be setup. You should believe this is good for the IETF. But it seems to be mostly you and I having opinions on this. => we are in the same timezone too. I'd also be interested in what others think. => I'd like to get the feedback from people who'd like to deploy mobile IPv6 (I expect concrete proposals, perhaps neither AAA nor IPsec/IKE). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:37:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14911 for ; Wed, 13 Feb 2002 12:37:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09927; Wed, 13 Feb 2002 10:36:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12990; Wed, 13 Feb 2002 09:36:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHa3Fh015588 for ; Wed, 13 Feb 2002 09:36:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHa3IJ015587 for mobile-ip-dist; Wed, 13 Feb 2002 09:36:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHa0Fh015580 for ; Wed, 13 Feb 2002 09:36:00 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27933 for ; Wed, 13 Feb 2002 09:36:03 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29800 for ; Wed, 13 Feb 2002 09:36:02 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA25623 for ; Wed, 13 Feb 2002 09:36:02 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DHa1024227 for ; Wed, 13 Feb 2002 09:36:01 -0800 X-mProtect:  Wed, 13 Feb 2002 09:36:01 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.106, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlBCTxb; Wed, 13 Feb 2002 09:35:59 PST Message-ID: <3C6AA3EB.5000409@iprg.nokia.com> Date: Wed, 13 Feb 2002 09:35:39 -0800 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA07@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, since you include me in this discussion... Hesham Soliman (ERA) wrote: >Charlie, > >This is not an attempt to start another >long thread about the benefits of piggybacking >but I would like make a couple of points that >I think might help: > >1. Since the current recommendation seems to be: > Mandate RR and optionally CGA on top later. > And since it is recommended that RR does not > setup a BSA, where is the issue of piggybacking > if you use RR only? > Something like BU3WAY runs the entire protocol > on ICMP, so you can't piggyback these meesages > anyway. Where is the issue? > >2. So far we've seen a concrete paper from Cedric > and yourself which upon discussion didn't not > result in any significant advantage of piggybacking > the BU (please refer to the archives, thread: > 'more on piggybacking'). So I really don't see > why you're against this decision. > The paper results in significant advantage of piggybacking with respect to jitter. I went back to the thread, and could not see any argument disproving this. Your point in the thread was (I rephrase quickly, but go to http://www.atm.tut.fi/list-archive/mobile-ip/thrd6.html#01722 for the details): Hesham: 'oh, but BU and data do not necessarily share the same medium, so BU don't introduce jitter'. To which I responded that: 'but dear, what if they do'. To sum it up, of course, if you chose the right situation (avaibility of a control plane and a user plane, like you suggested in the thread), then there is no jitter benefit (I even have a better situation with absolutely no benefit from piggybacking: prohibit the mobile node from moving :-) But the IETF is not here to design for the convenient link layer. The purpose should be to design the best solution, and piggybacking always reduces bandwidth and improves jitter, the latter often in a very significant way. Regards, Cedric. > > > >These are the 2 main comments. I have a couple >of specific ones below. > > > > That is a very important point. Regarding the "asserted" > > benefits, I think it can be shown that piggybacking _always_ > > offers performance benefits to a compliant IPv6 implementation, > > and that sometimes the benefits would enable important > > applications (like voice) to work better. > >=> Interesting, because I can negate the exact >argument with examples. But the paper which >you co-authored essentially concluded that: >- 'Don't go to war over BW efficiency > of piggybacking'. >- Piggybacking is good to reduce jitter during > a handover. > >Upon discussing the second point in the thread >I mentioned, we saw that certain assumptions >were made regarding the link layer configuration >(of a cellular link) that were not accurate >(please refer to the thread). > please read my comments above. > >So I'm still not sure about what the benefits >are. > > > > > - in cases where the functionality is detrimental > > > on certain kinds of links, the receiver may be > > > victimized when sent a piggybacked BU > > > > There are not any such links that correctly implement IPv6 > > MTU. > >=> What does this mean?? There are no link layers >that follow RFC2460? > > > The complete answer about how to use IPsec is going to take more > > effort than we can muster in the near term. Such effort SHOULD > > take into account the particular needs of Mobile IPv6 BSAs, > > anyway. I think that we should NOT go back to using only AH, > > especially because AH itself is likely to be deprecated in > > the future. > >=> I don't think the comment was related to securing >BUs with IPsec, but simply _using_ IPsec. Surely >we can't leave that out. > >Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:40:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15001 for ; Wed, 13 Feb 2002 12:40:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28225; Wed, 13 Feb 2002 09:39:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13987; Wed, 13 Feb 2002 09:39:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHd7Fh015697 for ; Wed, 13 Feb 2002 09:39:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHd7Wg015696 for mobile-ip-dist; Wed, 13 Feb 2002 09:39:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHd4Fh015689 for ; Wed, 13 Feb 2002 09:39:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28735; Wed, 13 Feb 2002 09:39:02 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03060; Wed, 13 Feb 2002 10:39:01 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DHcxe21896; Wed, 13 Feb 2002 09:38:59 -0800 (PST) Message-ID: <008701c1b4b5$19315bf0$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Francis Dupont" Cc: "Erik Nordmark" , , "Vijay Devarapalli" , "Jari Arkko" , References: Subject: Re: [mobile-ip] BU Authorization method: design team recommendation Date: Wed, 13 Feb 2002 09:37:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > > => it should *not* prevent from using other ways to secure them. > > We're in violent agreement on that. > > > No. It is a direct response to your point about IKE not performing well > > while AAA performing better under the same assumptions. > > Both protocols as I understand send a request and wait for a reply > > (and then repeat). > > > > => the number of exchanges, the size of messages, the complexity of > > crypto operations, ... many things are a bit different. > > But that has presumably some relationship to the resulting security. > True that IKE might be too complex but if comparing the son-of-ike > proposals against AAA-based SA establishment I would think > they would have the same number of messages and same computational complexity > to accomplish the same security. > If not it seems like AAA-based SA establishement would have some magic > potion that should be shared with the son-of-ike folks. > I agree that the difference in message traffic between AAA-based SA establishment and IKE or Son of IKE based SA establishment is probably going to be in the level of percent and not orders of magnitude. The major attraction of AAA-based SA establishment is that ISPs have existing AAA infrastructure that one could see being upgraded to support AAA-based SA establishment, while IKE based SA establisment will require a whole new infrastructure. In addition, ISPs can leverage AAA for other purposes, while IKE is single purpose. Hence, the investment makes more sense. This is a completely practical argument, however, it has nothing to do with the technology. > And if AAA-based SA establishment can't provide the same level of security > that son-of-ike SA estblishment can, then I think we should be very concerned. > Certainly agree. > For home registrations I personally think IPsec is a very good fit. > But I think you are referring to using IPsec to secure BUs to CNs as well > in lieu of using RR. Are you? > > The fact that there isn't an automatic way to establish the authorization > policy in the CN case makes me wonder how wise it would be to do that. > (Yes, the policy can of course be manually created by people with a good > understanding of the authorization issues, but that wouldn't help mere > mortals.) I'd feel differently about this if/when there is work in the IETF in > using DNSSEC on the ip6.arpa tree to store certificates or public keys > since then there would be a way to automate this. > Well, the issue here is that one might want to secure BU traffic with nodes in the foreign network, such as routers or LMM agents, and therefore setting up an SA when the MN comes up in the foreign network, then using it would make lots more sense than going through the RR messaging each time the MN changed its point of attachment. But, yes, I agree that it doesn't make sense for an arbitrary node in the Internet. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:42:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15057 for ; Wed, 13 Feb 2002 12:42:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09806; Wed, 13 Feb 2002 10:42:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14909; Wed, 13 Feb 2002 09:41:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHfGFh015746 for ; Wed, 13 Feb 2002 09:41:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHfG07015745 for mobile-ip-dist; Wed, 13 Feb 2002 09:41:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHfDFh015738 for ; Wed, 13 Feb 2002 09:41:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14645 for ; Wed, 13 Feb 2002 09:41:16 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10875 for ; Wed, 13 Feb 2002 09:41:15 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DHfDY04941 for ; Wed, 13 Feb 2002 11:41:14 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MB40KBN>; Wed, 13 Feb 2002 11:41:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E020AAA49@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 11:41:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4B5.A0FDEA80" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4B5.A0FDEA80 Content-Type: text/plain; charset="iso-8859-1" Sorry about jumping in but.. > 1. Since the current recommendation seems to be: > Mandate RR and optionally CGA on top later. > And since it is recommended that RR does not > setup a BSA, where is the issue of piggybacking > if you use RR only? > Something like BU3WAY runs the entire protocol > on ICMP, so you can't piggyback these meesages > anyway. Where is the issue? Perhaps the no BSA thinking and under what exact circumstances needs to be revisited or clarified as the exact scenario in terms of what the CN supports and doesn't support. I personally see the work progressing towards the creation of another "firewalls might or might not do filtering poriah" which will lead to RO'd MIP being blocked everywhere. Just as RPF checks are often turned on today at places that are not the most optimal. You certainly do point out the folly of trying to deal with each issue as a separate task and you do show how they are sometimes related with your reasoning, though. > > 2. So far we've seen a concrete paper from Cedric > and yourself which upon discussion didn't not > result in any significant advantage of piggybacking > the BU (please refer to the archives, thread: > 'more on piggybacking'). So I really don't see > why you're against this decision. > It would certainly be beneficial to update the binding and send a TCP SYN at the same time - perhaps during a handoff. What more do you need? I fail to see how someone could not see this advantage. ------_=_NextPart_001_01C1B4B5.A0FDEA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Sorry about jumping in but..


> 1. Since the current recommendation seems to = be:
>    Mandate RR and optionally CGA = on top later.
>    And since it is recommended = that RR does not
>    setup a BSA, where is the = issue of piggybacking
>    if you use RR only?
>    Something like BU3WAY runs = the entire protocol
>    on ICMP, so you can't = piggyback these meesages
>    anyway. Where is the = issue?

Perhaps the no BSA thinking and under what exact = circumstances needs to be revisited or clarified as the exact scenario = in terms of what the CN supports and doesn't support.

I personally see the work progressing towards the = creation of another "firewalls might or might not do = filtering  poriah" which will lead to RO'd MIP being blocked = everywhere. Just as RPF checks are often turned on today at places that = are not the most optimal.

You certainly do point out the folly of trying to = deal with each issue as a separate task and you do show how they are = sometimes related with your reasoning, though.

>
> 2. So far we've seen a concrete paper from = Cedric
>    and yourself which upon = discussion didn't not
>    result in any significant = advantage of piggybacking
>    the BU (please refer to the = archives, thread:
>    'more on piggybacking'). So I = really don't see
>    why you're against this = decision.
>   

It would certainly be beneficial to update the = binding and send a TCP SYN at the same time - perhaps during a = handoff.  What more do you need? I fail to see how someone could = not see this advantage.

------_=_NextPart_001_01C1B4B5.A0FDEA80-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:50:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15301 for ; Wed, 13 Feb 2002 12:50:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14153; Wed, 13 Feb 2002 10:50:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18283; Wed, 13 Feb 2002 09:49:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHn5Fh015852 for ; Wed, 13 Feb 2002 09:49:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHn5Eq015851 for mobile-ip-dist; Wed, 13 Feb 2002 09:49:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHn1Fh015844 for ; Wed, 13 Feb 2002 09:49:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25830 for ; Wed, 13 Feb 2002 09:49:04 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08028 for ; Wed, 13 Feb 2002 10:49:03 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1DHn2hM012421 for ; Wed, 13 Feb 2002 18:49:03 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 13 18:49:02 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:39:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA0B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 18:48:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The paper results in significant advantage of piggybacking > with respect > to jitter. > I went back to the thread, and could not see any argument > disproving this. > Your point in the thread was (I rephrase quickly, but go to > http://www.atm.tut.fi/list-archive/mobile-ip/thrd6.html#0172 > 2 for the > details): > Hesham: 'oh, but BU and data do not necessarily share the > same medium, so > BU don't introduce jitter'. To which I responded that: 'but > dear, what > if they do'. => Correct (the argument not the wording). But you didn't mention the argument I added later about the harm of piggybacking on existing connections due to the difference in channel characteristics which are needed for the BU and any odd IP packet carrying anything from HTTP to VoIP. If you want radio QoS you shouldn't treat them the same way. It's all in the same thread. > > To sum it up, of course, if you chose the right situation > (avaibility of > a control plane > and a user plane, like you suggested in the thread), then > there is no > jitter benefit (I even > have a better situation with absolutely no benefit from > piggybacking: > prohibit the > mobile node from moving :-) But the IETF is not here to > design for the > convenient > link layer. => Of course, but this is not something new that the IETF needs to design, link layers with QoS assurances already have these features. 'features' being the ability to configure a certain bearer for a certain type of traffic. Anyway I don't want to get into another infinite loop, it was all said before, point 1) above is the main issue which makes the piggybacking discussion irrelevant, at least when you're using RR only which is the current recommendation for the spec. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:53:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15427 for ; Wed, 13 Feb 2002 12:53:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19209; Wed, 13 Feb 2002 10:53:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19653; Wed, 13 Feb 2002 09:53:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHqkFh015923 for ; Wed, 13 Feb 2002 09:52:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHqjuD015922 for mobile-ip-dist; Wed, 13 Feb 2002 09:52:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHqgFh015915 for ; Wed, 13 Feb 2002 09:52:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27112 for ; Wed, 13 Feb 2002 09:52:45 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10000 for ; Wed, 13 Feb 2002 10:52:42 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1DHqfB11186 for ; Wed, 13 Feb 2002 18:52:41 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 13 18:52:41 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:51:58 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA0C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 18:52:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 2. So far we've seen a concrete paper from Cedric > and yourself which upon discussion didn't not > result in any significant advantage of piggybacking > the BU (please refer to the archives, thread: > 'more on piggybacking'). So I really don't see > why you're against this decision. > It would certainly be beneficial to update the binding and send a TCP SYN at the same time - perhaps during a handoff. What more do you need? I fail to see how someone could not see this advantage. => Sure, but everyone on the other side of the argument is saying that you _can_ do that. Why does it have to be in the same packet? L2 can place them in the same frame. But again I fail to see why this is an issue considering point 1 that I sent earlier. This _is_ the current working assumption that people agreed with. And it's a good one IMHO. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 12:55:13 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15464 for ; Wed, 13 Feb 2002 12:55:12 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02276; Wed, 13 Feb 2002 09:55:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03393; Wed, 13 Feb 2002 09:54:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHs6Fh015958 for ; Wed, 13 Feb 2002 09:54:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DHs6KX015957 for mobile-ip-dist; Wed, 13 Feb 2002 09:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DHs3Fh015950 for ; Wed, 13 Feb 2002 09:54:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03196 for ; Wed, 13 Feb 2002 09:54:06 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16630 for ; Wed, 13 Feb 2002 10:54:06 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA26711 for ; Wed, 13 Feb 2002 09:54:05 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DHs5d21891 for ; Wed, 13 Feb 2002 09:54:05 -0800 X-mProtect:  Wed, 13 Feb 2002 09:54:05 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.106, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLPfu48; Wed, 13 Feb 2002 09:54:02 PST Message-ID: <3C6AA826.9090900@iprg.nokia.com> Date: Wed, 13 Feb 2002 09:53:42 -0800 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil, > >I would like you to comment on each whether you AGREE, >DISAGREE, or CAN LIVE WITH the option. > >1. Specify that piggybacking of binding update messages not > be used with MIP v6. > DISAGREE. I participated in a little analytical study that shows there is always a benefit to piggybacking, especially with respect to jitter, it would be a shame to lose this benefit. > >2. Specify that piggybacking always be an option. > CAN LIVE WITH > >Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links >Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > This last point is not a fair characterization: I can come up with many links that would be abused if piggybacking was NOT used, and the receiver severely bruised. Such a statement can be written for any functionality, replace 'piggybacked BU' with your least favorite functionality. I hope this does not show a bias of the DT. > > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > >3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > CAN LIVE WITH, but seems convoluted and impractical to me. > >The DT has come to the following conclusions: > >(a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > >(b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > >(c) Binding update messages for both HAs and CNs, binding > acks, RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > DISAGREE. I think Charlie provided some good technical points wrt this. Cheers, Cedric. > > > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. > (However, link layer techniques may exist to migitate > the disadvantages of sending separate packets, to > some extent.) > AGREE with the benefits part. Parenthesis sounds speculative. > > > - MIPv6 control packets are needed between MN - HA, > MN - CN, and CN - HA - MN. There is no piggybacking > policy granularity problem in the MN - CN case, due > to recommendation (b). However, if piggybacking is > used for the MN - HA case either IPsec specifications > would have to be extended, or mechanisms similar to > those introduced in draft 14 would have to be employed. > MN-HA piggybacking sounds like a strange idea to me. > > > - The deciding factor, however, seems to be the protection > we need for RR (or to a smaller extent CGA) messages > on the CN - HA - MN path. Given that the HA is acting > only as a router in this case, it can not insert DOs > in the RR packets since that violates fundamental > assumptions needed e.g. for Path MTU discovery, and > draft 14 mechanisms wouldn't be able to provide the > necessary encryption anyway. Therefore, it seems necessary > to provide ESP-like functionality in any case for the MNs > and HAs. Based on this, it would make sense to use the same > mechanism also for BU protection. > > - It seems very useful to be able to use IPsec ESP (with > manual keying) for protecting the RR control packets > on the HA-MN path. If the IPsec selectors can't be used > to distinguish those packets from data traffic the effect > might be that lots of data packets (all that are tunneled > through the HA) also become encrypted which would be a > source of performance concerns for limited MN devices. > > - Some BU authorization mechanisms, namely those based > on Diffie-Hellman and/or CGA, may not fit IPv6 DOs. > > >Phil > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:14:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15974 for ; Wed, 13 Feb 2002 13:14:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00704; Wed, 13 Feb 2002 11:14:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08037; Wed, 13 Feb 2002 10:14:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIDEFh016172 for ; Wed, 13 Feb 2002 10:13:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DIDEA4016171 for mobile-ip-dist; Wed, 13 Feb 2002 10:13:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DID9Fh016164 for ; Wed, 13 Feb 2002 10:13:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07783 for ; Wed, 13 Feb 2002 10:13:04 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25165 for ; Wed, 13 Feb 2002 10:13:03 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1DID2B15974 for ; Wed, 13 Feb 2002 19:13:02 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Feb 13 19:13:00 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 19:03:31 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA0E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 Date: Wed, 13 Feb 2002 19:12:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > A firewall needs to look at ip6r_nxt (in order to process the next > > header or the payload), at ip6r_len (in order to find the > next header > > or the payload). To stop there, i.e. not to look at ip6r_type, can > > be considered as an insult to firewall programmers > > Code itself isn't difficult, but people may argue they > don't want a every > possible knob and detail to be checkable.. syntax for e.g. > ip6fw(8) is > rather complicated already :-) => Is this speculation based on some foundation? I'm just trying to understand how far we can go speculating about what people might like or not like. If they just 'can't be bothered' then tough luck! Hesham > > >(note you can't > > use the backward compatibility argument because no > publicly available > > IPv6 firewall deals with routing headers, i.e. do > something else than > > skip/ignore the header in payload chasing). > > Incorrect: ip6fw can drop packets which contain RH (or any > header type). > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:17:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16040 for ; Wed, 13 Feb 2002 13:17:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02622; Wed, 13 Feb 2002 11:16:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08959; Wed, 13 Feb 2002 10:16:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIFSFh016222 for ; Wed, 13 Feb 2002 10:15:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DIFQVt016221 for mobile-ip-dist; Wed, 13 Feb 2002 10:15:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIFMFh016214 for ; Wed, 13 Feb 2002 10:15:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26464 for ; Wed, 13 Feb 2002 10:15:25 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01937 for ; Wed, 13 Feb 2002 11:15:24 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA28902 for ; Wed, 13 Feb 2002 10:15:24 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DIFNL29038 for ; Wed, 13 Feb 2002 10:15:23 -0800 X-mProtect:  Wed, 13 Feb 2002 10:15:23 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.106, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtdacG7; Wed, 13 Feb 2002 10:15:21 PST Message-ID: <3C6AAD24.3020505@iprg.nokia.com> Date: Wed, 13 Feb 2002 10:15:00 -0800 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA0B@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, Hesham Soliman (ERA) wrote: >=> Correct (the argument not the wording). >But you didn't mention the argument I added >later about the harm of piggybacking >on existing connections due to the difference >in channel characteristics which are needed >for the BU and any odd IP packet carrying anything >from HTTP to VoIP. If you want radio QoS >you shouldn't treat them the same way. >It's all in the same thread. > thanks for reminding me, I never responded to this point. I think you forgot BU's have reliability on their own, by way of BAck. So link layer is not required to provide another level of reliability. >> > > To sum it up, of course, if you chose the right situation > > (avaibility of > > a control plane > > and a user plane, like you suggested in the thread), then > > there is no > > jitter benefit (I even > > have a better situation with absolutely no benefit from > > piggybacking: > > prohibit the > > mobile node from moving :-) But the IETF is not here to > > design for the > > convenient > > link layer. > >=> Of course, but this is not something new that >the IETF needs to design, link layers with QoS >assurances already have these features. 'features' >being the ability to configure a certain bearer >for a certain type of traffic. > >Anyway I don't want to get into another infinite >loop, it was all said before, >point 1) above is the main issue which makes the >piggybacking discussion irrelevant, at least when >you're using RR only which is the current recommendation >for the spec. > I hope my (delayed) reply to this point makes you reconsider that you should not dismiss the piggybacking discussion on this ground. Take care, Cedric. > > >Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:22:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16142 for ; Wed, 13 Feb 2002 13:22:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05409; Wed, 13 Feb 2002 11:22:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10625; Wed, 13 Feb 2002 10:22:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DILYFh016320 for ; Wed, 13 Feb 2002 10:21:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DILY2d016319 for mobile-ip-dist; Wed, 13 Feb 2002 10:21:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DILVFh016312 for ; Wed, 13 Feb 2002 10:21:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28481 for ; Wed, 13 Feb 2002 10:21:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04880 for ; Wed, 13 Feb 2002 11:21:33 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29493; Wed, 13 Feb 2002 10:21:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DILWL06966; Wed, 13 Feb 2002 10:21:32 -0800 X-mProtect:  Wed, 13 Feb 2002 10:21:32 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjJ1CnI; Wed, 13 Feb 2002 10:21:29 PST Message-ID: <3C6AAE4A.F0134846@iprg.nokia.com> Date: Wed, 13 Feb 2002 10:19:54 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA07@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, I'll try to avoid repeating what others are saying, but perhaps without complete success. "Hesham Soliman (ERA)" wrote: > 1. Since the current recommendation seems to be: > Mandate RR and optionally CGA on top later. > And since it is recommended that RR does not > setup a BSA, where is the issue of piggybacking > if you use RR only? We have to allow for situations where mobile node and correspondent node already have an appropriate security association, created by whatever means. RR is proposed as a scalable solution that can support billions of nodes. I would be very opposed to any attempt to shape every other bit of protocol around this interim solution. > Something like BU3WAY runs the entire protocol > on ICMP, so you can't piggyback these meesages > anyway. Where is the issue? This is totally irrelevant to what happens when you already have an established security association that enables use of Binding Update with payload. > 2. So far we've seen a concrete paper from Cedric > and yourself which upon discussion didn't not > result in any significant advantage of piggybacking > the BU (please refer to the archives, thread: > 'more on piggybacking'). So I really don't see > why you're against this decision. Cedric has responded to this, but I wish you would not so blithely brush aside this work. > > That is a very important point. Regarding the "asserted" > > benefits, I think it can be shown that piggybacking _always_ > > offers performance benefits to a compliant IPv6 implementation, > > and that sometimes the benefits would enable important > > applications (like voice) to work better. > > => Interesting, because I can negate the exact > argument with examples. If so, then I will be able to show that your examples are not IPv6 compliant. > Upon discussing the second point in the thread > I mentioned, we saw that certain assumptions > were made regarding the link layer configuration > (of a cellular link) that were not accurate > (please refer to the thread). > So I'm still not sure about what the benefits > are. I don't have the thread handy, but I do not recall any such inaccurate assumptions. > > > - in cases where the functionality is detrimental > > > on certain kinds of links, the receiver may be > > > victimized when sent a piggybacked BU > > > > There are not any such links that correctly implement IPv6 > > MTU. > > => What does this mean?? There are no link layers > that follow RFC2460? Of course it does not mean that. It means that link layers are required to handle MTU >= 1280, and Binding Updates with average payloads fit well within that requirement. I cannot imagine how you might have constructed the interpretation in your second sentence. > > The complete answer about how to use IPsec is going to take more > > effort than we can muster in the near term. Such effort SHOULD > > take into account the particular needs of Mobile IPv6 BSAs, > > anyway. I think that we should NOT go back to using only AH, > > especially because AH itself is likely to be deprecated in > > the future. > > => I don't think the comment was related to securing > BUs with IPsec, but simply _using_ IPsec. Surely > we can't leave that out. You can use IPsec, and if you do you might wish to avoid having payload, in order to avoid the problems that have been raised. I can use Binding Authentication Data suboption, and have payload. Compliant IPv6 implementations can receive both. I do not see any problem here with allowing piggybacking. Everyone can be happy. Thus, I am at a loss to figure out why you are not happy. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:41:35 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16774 for ; Wed, 13 Feb 2002 13:41:34 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14376; Wed, 13 Feb 2002 10:41:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13373; Wed, 13 Feb 2002 10:41:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIeDFh016425 for ; Wed, 13 Feb 2002 10:40:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DIeDVG016424 for mobile-ip-dist; Wed, 13 Feb 2002 10:40:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIe9Fh016417 for ; Wed, 13 Feb 2002 10:40:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12918 for ; Wed, 13 Feb 2002 10:40:11 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02067 for ; Wed, 13 Feb 2002 11:40:09 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1DIe8hM020895 for ; Wed, 13 Feb 2002 19:40:08 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Feb 13 19:40:01 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 19:30:40 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA0F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 19:39:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 1. Since the current recommendation seems to be: > > Mandate RR and optionally CGA on top later. > > And since it is recommended that RR does not > > setup a BSA, where is the issue of piggybacking > > if you use RR only? > > We have to allow for situations where mobile node > and correspondent node already have an appropriate > security association, created by whatever means. => Can you show one example for 'whatever means'? The reason I'm asking is that it has been mentioned by several people that the issue here is authorisation. Currently the only methods we know of that would guarantee the required levels of authorisation are : RR and RR+CGA. Possible alternatives: - PKI with addresses inside? didn't think this is an option - AAA? This adds more burdens (infrastructure requirement and inflexbility) I'm trying to keep it short but the details were all discussed in the last 2 weeks. > RR is proposed as a scalable solution that can support > billions of nodes. I would be very opposed to any > attempt to shape every other bit of protocol around > this interim solution. => I don't know why you think it's interim. > > > Something like BU3WAY runs the entire protocol > > on ICMP, so you can't piggyback these meesages > > anyway. Where is the issue? > > This is totally irrelevant to what happens when you > already have an established security association that > enables use of Binding Update with payload. => See above. > > > That is a very important point. Regarding the "asserted" > > > benefits, I think it can be shown that piggybacking _always_ > > > offers performance benefits to a compliant IPv6 > implementation, > > > and that sometimes the benefits would enable important > > > applications (like voice) to work better. > > > > => Interesting, because I can negate the exact > > argument with examples. > > If so, then I will be able to show that your examples > are not IPv6 compliant. => Charlie, this argument does not hold. Using extension headers is useful for processing of the 'received' packets. It doesn't mean that we can put any protocol into any packet and that disallowing this breaks IPv6. It might be worth discussing this on the IPv6 list though. > > > There are not any such links that correctly implement IPv6 > > > MTU. > > > > => What does this mean?? There are no link layers > > that follow RFC2460? > > Of course it does not mean that. It means that link layers are > required to handle MTU >= 1280, and Binding Updates with > average payloads fit well within that requirement. => 'Fit well' depends on the size of the packet without the BU. I cannot > imagine how you might have constructed the interpretation in > your second sentence. => It seemed like you said: there are no such links that correctly implement IPv6 MTU. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:45:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16891 for ; Wed, 13 Feb 2002 13:45:14 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14648; Wed, 13 Feb 2002 11:44:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14773; Wed, 13 Feb 2002 10:44:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIiAFh016489 for ; Wed, 13 Feb 2002 10:44:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DIiAuE016488 for mobile-ip-dist; Wed, 13 Feb 2002 10:44:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIi7Fh016481 for ; Wed, 13 Feb 2002 10:44:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16501 for ; Wed, 13 Feb 2002 10:44:08 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03816 for ; Wed, 13 Feb 2002 11:44:07 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1DIi6B21403 for ; Wed, 13 Feb 2002 19:44:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 13 19:44:06 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 19:34:38 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA10@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 19:43:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >=> Correct (the argument not the wording). > >But you didn't mention the argument I added > >later about the harm of piggybacking > >on existing connections due to the difference > >in channel characteristics which are needed > >for the BU and any odd IP packet carrying anything > >from HTTP to VoIP. If you want radio QoS > >you shouldn't treat them the same way. > >It's all in the same thread. > > > thanks for reminding me, I never responded to this point. > I think you forgot BU's have reliability on their own, by > way of BAck. > So link layer is not required to provide another level of > reliability. => I think that L2 retransmission is much faster than an e2e delay with exponential backoff. Of course you can always set the A flag and achieve the above, but on a link with QoS assurances, it would be unfortunate to eliminate such QoS features. > >Anyway I don't want to get into another infinite > >loop, it was all said before, > >point 1) above is the main issue which makes the > >piggybacking discussion irrelevant, at least when > >you're using RR only which is the current recommendation > >for the spec. > > > I hope my (delayed) reply to this point makes you > reconsider that you > should not dismiss the piggybacking discussion on this ground. => But maybe I don't understand your reasoning? Are you referring to the point 1) ? I might be a bit slow in understanding why I should not consider this as an argument but I'd appreciate your explanation, so please don't keep me waiting for too long :) Hesham > > Take care, > > Cedric. > > > > > > >Hesham > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:49:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17080 for ; Wed, 13 Feb 2002 13:49:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17172; Wed, 13 Feb 2002 11:48:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16515; Wed, 13 Feb 2002 10:48:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DImBFh016569 for ; Wed, 13 Feb 2002 10:48:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DImBKk016568 for mobile-ip-dist; Wed, 13 Feb 2002 10:48:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIm8Fh016561 for ; Wed, 13 Feb 2002 10:48:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16277 for ; Wed, 13 Feb 2002 10:48:10 -0800 (PST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09982 for ; Wed, 13 Feb 2002 10:48:10 -0800 (PST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1DIm9F21829 for ; Wed, 13 Feb 2002 12:48:09 -0600 (CST) Message-ID: <3C6AB4E2.30507@alcatel.com> Date: Wed, 13 Feb 2002 12:48:03 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA0C@Esealnt861.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------000004030108090507090508" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------000004030108090507090508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Hesham, I do not know why you restarted the discussion on this. I think that it is time to vote. Let the cochairs decide on the consensus. Regards, Hesham Soliman (ERA) wrote: >>2. So far we've seen a concrete paper from Cedric >> and yourself which upon discussion didn't not >> result in any significant advantage of piggybacking >> the BU (please refer to the archives, thread: >> 'more on piggybacking'). So I really don't see >> why you're against this decision. >> >> >It would certainly be beneficial to update the binding and send a TCP SYN at the same time - perhaps during a handoff. What more do you need? I fail to see how someone could not see this advantage. > >=> Sure, but everyone on the other side of the >argument is saying that you _can_ do that. >Why does it have to be in the same packet? >L2 can place them in the same frame. > >But again I fail to see why this is an >issue considering point 1 that I sent >earlier. This _is_ the current working >assumption that people agreed with. And it's >a good one IMHO. > >Hesham > -- Behcet --------------000004030108090507090508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hesham,
  I do not know why you restarted the discussion on this. I think that it is time to vote. Let the cochairs decide on the consensus.

Regards,

Hesham Soliman (ERA) wrote:
2. So far we've seen a concrete paper from Cedric 
   and yourself which upon discussion didn't not 
   result in any significant advantage of piggybacking 
   the BU (please refer to the archives, thread: 
   'more on piggybacking'). So I really don't see 
   why you're against this decision. 
   
It would certainly be beneficial to update the binding and send a TCP SYN at the same time - perhaps during a handoff.  What more do you need? I fail to see how someone could not see this advantage.

=> Sure, but everyone on the other side of the 
argument is saying that you _can_ do that. 
Why does it have to be in the same packet?
L2 can place them in the same frame.

But again I fail to see why this is an 
issue considering point 1 that I sent 
earlier. This _is_ the current working 
assumption that people agreed with. And it's
a good one IMHO.

Hesham

-- 
Behcet

--------------000004030108090507090508-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 13:58:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17410 for ; Wed, 13 Feb 2002 13:58:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23972; Wed, 13 Feb 2002 11:57:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19405; Wed, 13 Feb 2002 10:57:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIutFh016618 for ; Wed, 13 Feb 2002 10:56:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DIutaf016617 for mobile-ip-dist; Wed, 13 Feb 2002 10:56:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DIuqFh016610 for ; Wed, 13 Feb 2002 10:56:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20222 for ; Wed, 13 Feb 2002 10:56:53 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14263 for ; Wed, 13 Feb 2002 10:56:52 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA01888 for ; Wed, 13 Feb 2002 10:56:52 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DIupc31452 for ; Wed, 13 Feb 2002 10:56:51 -0800 X-mProtect:  Wed, 13 Feb 2002 10:56:51 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.52, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXrsRJM; Wed, 13 Feb 2002 10:56:47 PST Message-ID: <3C6AB6E4.3080505@iprg.nokia.com> Date: Wed, 13 Feb 2002 10:56:36 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <3C696A4F.8653C362@iprg.nokia.com> <038f01c1b4b0$f57df140$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jari, Jari Arkko wrote: >>>(b) We recommend that when IPsec protection is used, it is >>> always used in *addition* to RR (or CGA) methods, not as >>> a replacement. Thus RR (or CGA) methods would be used to >>> protect MN - CN Route optimization procedures even when IPsec >>> is used. >>> >>DISAGREE strongly with this. In the first place, I dont >>understand why this is there in the Piggybacking >>recommendation. When there is an IPSec SA between >>an MN and CN (could have been created statically for >>all you know), there is no need to run either RR or >>RR+CGA. >> > > Apparently we disagree about the likelihood of having the kind > of private manual SAs that - I agree - would be sufficient for > authorization. > > But let me ask you a question to clarify your position. > Let's *not* discuss for the moment if SAs are sufficient. > But why do are you opposed to the in-addition recommendation? > Is it because of additional signaling or some other reason? Additional signaling, of course. If an IPSec SA were enough, I wouldnt want to do RR messages, especially during a handoff. This is a big gain (not having to do RR, whenever possible). Also another reason why I objected was, this is a piggybacking recommendation. Why does a piggybacking recommendation have to say that IPSec SA would never be enough and should be used always in addition to RR. Shouldnt we take that up separately? Now something about the IPSec SA itself. If the IPSec SA were created by AAA, PKI or some future infrastructure method, I think it would be enough for securing the BUs without having to do RR. And I also see a static SA created between my MN and my friend's MN very realistic and possible. regards Vijay > Implementation-wise, I would have thought it'd be easier if > you didn't need to know if you had IPsec at the bottom. > > Jari > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:01:28 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17495 for ; Wed, 13 Feb 2002 14:01:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19598; Wed, 13 Feb 2002 11:01:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20933; Wed, 13 Feb 2002 11:01:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJ0MFh016680 for ; Wed, 13 Feb 2002 11:00:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJ0MmH016679 for mobile-ip-dist; Wed, 13 Feb 2002 11:00:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJ0JFh016669 for ; Wed, 13 Feb 2002 11:00:19 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21321 for ; Wed, 13 Feb 2002 11:00:20 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15909 for ; Wed, 13 Feb 2002 11:00:19 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA02074; Wed, 13 Feb 2002 11:00:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DJ0Ie04522; Wed, 13 Feb 2002 11:00:18 -0800 X-mProtect:  Wed, 13 Feb 2002 11:00:18 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduTrMvU; Wed, 13 Feb 2002 11:00:15 PST Message-ID: <3C6AB75B.7465C235@iprg.nokia.com> Date: Wed, 13 Feb 2002 10:58:35 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA0F@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, Continuing... "Hesham Soliman (ERA)" wrote: > => Can you show one example for 'whatever means'? How about manual configuration? Every mobile node should be allowed to establish a permanent security association by manual configuration. The argument against this for billions of correspondent nodes is clear. There isn't any good argument for disallowing it in special cases. I also think it is clear that protocols will be developed for long-term key establishment that do not depend on bu3way or RR, although I like RR methods myself. Any long-term association will serve for this example. > - AAA? This adds more burdens (infrastructure > requirement and inflexbility) There's a huge difference between mandating AAA for all purposes (which would be hard because of the reasons you have given) and disallowing it for all applications (which would be bad, because many scenarios work well with AAA-style authorization). AAA (and others!) could be used to establish longer-term security associations than ephemeral RR. > > RR is proposed as a scalable solution that can support > > billions of nodes. I would be very opposed to any > > attempt to shape every other bit of protocol around > > this interim solution. > > => I don't know why you think it's interim. O.K. Even if it's permanent, other solutions will be devised. > > > => Interesting, because I can negate the exact > > > argument with examples. > > > > If so, then I will be able to show that your examples > > are not IPv6 compliant. > > => Charlie, this argument does not hold. Using > extension headers is useful for processing > of the 'received' packets. It doesn't mean > that we can put any protocol into any packet and > that disallowing this breaks IPv6. It might > be worth discussing this on the IPv6 list > though. This discussion about piggybacking is ONLY relevant for received packets, and already IPv6 essentially mandates that receivers be able to to the appropriate processing for IPv6 extension headers. There is NO requirement that a sender has to use piggybacking. When I read this sentence: It doesn't mean that we can put any protocol into any packet and that disallowing this breaks IPv6. I start to think that you are absolutely not following my discussion. But to try to make it clear: - IPv6 nodes MUST be able to transmit packets with MTU >= 1280 - IPv6 nodes MUST be able to parse certain extension headers. Putting these two mandates does not in any way add up to "putting any protocol into any packet". I think you should try to explain why you made that characterization. > I cannot > > imagine how you might have constructed the interpretation in > > your second sentence. > > => It seemed like you said: there are no such links > that correctly implement IPv6 MTU. The links that you claim, are links that do not correctly implement IPv6. There are no links, such as you claim, that correctly implement IPv6. There are plenty of links that correctly implement IPv6. These links are not of the variety that you claim exist. I don't know what else I can say to make this clearer. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:03:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17559 for ; Wed, 13 Feb 2002 14:03:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24902; Wed, 13 Feb 2002 12:02:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21808; Wed, 13 Feb 2002 11:02:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJ25Fh016733 for ; Wed, 13 Feb 2002 11:02:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJ25U3016732 for mobile-ip-dist; Wed, 13 Feb 2002 11:02:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJ21Fh016722 for ; Wed, 13 Feb 2002 11:02:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21815 for ; Wed, 13 Feb 2002 11:02:03 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24427 for ; Wed, 13 Feb 2002 12:02:01 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA02183 for ; Wed, 13 Feb 2002 11:02:00 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DJ20N06386 for ; Wed, 13 Feb 2002 11:02:00 -0800 X-mProtect:  Wed, 13 Feb 2002 11:02:00 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.106, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUNEzKo; Wed, 13 Feb 2002 11:01:57 PST Message-ID: <3C6AB810.3020701@iprg.nokia.com> Date: Wed, 13 Feb 2002 11:01:36 -0800 From: Cedric Westphal User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA10@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) wrote: >=> I think that L2 retransmission is much faster >than an e2e delay with exponential backoff. >Of course you can always set the A flag and achieve >the above, but on a link with QoS assurances, it >would be unfortunate to eliminate such QoS >features. > > > >Anyway I don't want to get into another infinite > > >loop, it was all said before, > > >point 1) above is the main issue which makes the > > >piggybacking discussion irrelevant, at least when > > >you're using RR only which is the current recommendation > > >for the spec. > > > > > I hope my (delayed) reply to this point makes you > > reconsider that you > > should not dismiss the piggybacking discussion on this ground. > >=> But maybe I don't understand your reasoning? >Are you referring to the point 1) ? > I am replying to whichever point you mentioned my name into. >I might be a bit slow in understanding why >I should not consider this as an argument >but I'd appreciate your explanation, so >please don't keep me waiting for too long :) > Wasn't this short and painless? Cedric. > > >Hesham > > > > > > Take care, > > > > Cedric. > > > > > > > > > > >Hesham > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:12:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17804 for ; Wed, 13 Feb 2002 14:12:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02385; Wed, 13 Feb 2002 12:12:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25244; Wed, 13 Feb 2002 11:11:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJB8Fh016877 for ; Wed, 13 Feb 2002 11:11:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJB8j3016876 for mobile-ip-dist; Wed, 13 Feb 2002 11:11:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJB5Fh016869 for ; Wed, 13 Feb 2002 11:11:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27707 for ; Wed, 13 Feb 2002 11:11:06 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01613 for ; Wed, 13 Feb 2002 12:11:06 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DJB4Y09929 for ; Wed, 13 Feb 2002 13:11:04 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <15N0L8KS>; Wed, 13 Feb 2002 13:11:04 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E020AAC9F@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 13:11:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4C2.2EB4F1F0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4C2.2EB4F1F0 Content-Type: text/plain; charset="ISO-8859-1" Again, people seem to be leading to another pariah and the BSA needs to at least be clarified if not revisited entirely by both of the DTs, IMO. The little blurbs given by the design teams aren't telling the whole story and the ramifications of their conclusions. > But again I fail to see why this is an > issue considering point 1 that I sent > earlier. This _is_ the current working > assumption that people agreed with. And it's > a good one IMHO. > ------_=_NextPart_001_01C1B4C2.2EB4F1F0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Again, people seem to be leading to another pariah = and the BSA needs to at least be clarified if not revisited entirely by = both of the DTs, IMO. The little blurbs given by the design teams = aren't telling the whole story and the ramifications of their = conclusions.

> But again I fail to see why this is an
> issue considering point 1 that I sent
> earlier. This _is_ the current working
> assumption that people agreed with. And = it's
> a good one IMHO.
>

------_=_NextPart_001_01C1B4C2.2EB4F1F0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:12:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17840 for ; Wed, 13 Feb 2002 14:12:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01929; Wed, 13 Feb 2002 12:11:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25064; Wed, 13 Feb 2002 11:11:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJAMFh016858 for ; Wed, 13 Feb 2002 11:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJALdk016857 for mobile-ip-dist; Wed, 13 Feb 2002 11:10:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJAIFh016850 for ; Wed, 13 Feb 2002 11:10:18 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14814 for ; Wed, 13 Feb 2002 11:09:18 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20173 for ; Wed, 13 Feb 2002 11:07:57 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA19795 for ; Wed, 13 Feb 2002 12:07:57 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA01222 for ; Wed, 13 Feb 2002 12:07:56 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Wed, 13 Feb 2002 13:07:48 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9F0792EC83; Wed, 13 Feb 2002 20:02:44 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: monet@nal.motlabs.com Subject: Re: [mobile-ip] Routing headers - part 2 References: From: Alexandru Petrescu Date: 13 Feb 2002 20:07:52 +0100 In-Reply-To: Message-Id: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik Nordmark writes: > The basis for comparing these [Routing Header] alternatives does not > take into account issues relating to Mobile Routers or Mobile > Networks because it isn't clear what the architecture will be for > such things, to what extent they will use route optimization, and > how such optimizations would be effected by the choices made for > Mobile IPv6. Hi Erik. A monet architecture that source routes through the MR looks very natural to me since IPv6 offers RH type 0. But if Mobile IPv6 uses type 2 instead, then monet's will have to choose between either type 0 or type 2. Or eventually generate a new type 3 for monets. At the same time, I guess the firewalling argument holds in the monet environments too. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:19:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18077 for ; Wed, 13 Feb 2002 14:19:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03078; Wed, 13 Feb 2002 12:18:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28273; Wed, 13 Feb 2002 11:18:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJHwFh017151 for ; Wed, 13 Feb 2002 11:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJHwNE017150 for mobile-ip-dist; Wed, 13 Feb 2002 11:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJHtFh017143 for ; Wed, 13 Feb 2002 11:17:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18513 for ; Wed, 13 Feb 2002 11:17:57 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05140 for ; Wed, 13 Feb 2002 12:17:57 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DJHtY11664 for ; Wed, 13 Feb 2002 13:17:55 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MB40LDC>; Wed, 13 Feb 2002 13:17:55 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E020AACD9@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Wed, 13 Feb 2002 13:17:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4C3.226F0C90" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4C3.226F0C90 Content-Type: text/plain; charset="iso-8859-1" There is no technical merit to the DT's conclusion. As such they need to find some before a vote is done. -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Wednesday, February 13, 2002 12:48 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Hi Hesham, I do not know why you restarted the discussion on this. I think that it is time to vote. Let the cochairs decide on the consensus. Regards, Hesham Soliman (ERA) wrote: 2. So far we've seen a concrete paper from Cedric and yourself which upon discussion didn't not result in any significant advantage of piggybacking the BU (please refer to the archives, thread: 'more on piggybacking'). So I really don't see why you're against this decision. It would certainly be beneficial to update the binding and send a TCP SYN at the same time - perhaps during a handoff. What more do you need? I fail to see how someone could not see this advantage. => Sure, but everyone on the other side of the argument is saying that you _can_ do that. Why does it have to be in the same packet? L2 can place them in the same frame. But again I fail to see why this is an issue considering point 1 that I sent earlier. This _is_ the current working assumption that people agreed with. And it's a good one IMHO. Hesham -- Behcet ------_=_NextPart_001_01C1B4C3.226F0C90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There=20 is no technical merit to the DT's conclusion. As such they need to find = some=20 before a vote is done.
-----Original Message-----
From: Behcet Sarikaya=20 [mailto:behcet.sarikaya@alcatel.com]
Sent: Wednesday, = February 13,=20 2002 12:48 PM
To: = mobile-ip@sunroof.eng.sun.com
Subject:=20 Re: [Fwd: Re: [mobile-ip] Piggybacking - DT=20 recommendation]

Hi Hesham,
  I do not = know why you=20 restarted the discussion on this. I think that it is time to vote. = Let the=20 cochairs decide on the consensus.

Regards,

Hesham = Soliman (ERA)=20 wrote:
2. So far we've seen a =
concrete paper from Cedric 
   and yourself which upon discussion =
didn't not 
   result in any significant advantage of piggybacking =

   the BU (please refer to the archives, thread: 
   'more on =
piggybacking'). So I really don't see 
   why you're against this =
decision. 
   
It would =
certainly be beneficial to update the binding and send a TCP SYN at the =
same time - perhaps during a handoff.  What more do you need? I fail to =
see how someone could not see this advantage.

=3D> Sure, but =
everyone on the other side of the 
argument is saying that you _can_ =
do that. 
Why does it have to be in the same packet?
L2 can place =
them in the same frame.

But again I fail to see why this is an =

issue considering point 1 that I sent 
earlier. This _is_ the =
current working 
assumption that people agreed with. And it's
a =
good one IMHO.

Hesham

--=20
Behcet

------_=_NextPart_001_01C1B4C3.226F0C90-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:47:10 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18875 for ; Wed, 13 Feb 2002 14:47:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16098; Wed, 13 Feb 2002 12:46:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28266; Wed, 13 Feb 2002 11:46:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJjqFh017354 for ; Wed, 13 Feb 2002 11:45:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJjo3b017353 for mobile-ip-dist; Wed, 13 Feb 2002 11:45:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJjlFh017346 for ; Wed, 13 Feb 2002 11:45:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27739 for ; Wed, 13 Feb 2002 11:45:49 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15533 for ; Wed, 13 Feb 2002 12:45:48 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DJjkk06253 for ; Wed, 13 Feb 2002 20:45:46 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA04815 for ; Wed, 13 Feb 2002 20:45:47 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DJjkg11258 for ; Wed, 13 Feb 2002 20:45:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202131945.g1DJjkg11258@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 In-reply-to: Your message of Wed, 13 Feb 2002 18:58:34 +0200. Date: Wed, 13 Feb 2002 20:45:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Code itself isn't difficult, but people may argue they don't want a every possible knob and detail to be checkable.. syntax for e.g. ip6fw(8) is rather complicated already :-) => the idea is to avoid this new knob. >(note you can't > use the backward compatibility argument because no publicly available > IPv6 firewall deals with routing headers, i.e. do something else than > skip/ignore the header in payload chasing). Incorrect: ip6fw can drop packets which contain RH (or any header type). => yes, I look at the code (I checked with ipf) and the IPv4 option filter code was translated into an IPv6 header filter code. IMHO you may insult the authors, this is really laziness! BTW it seems there will be a good majority for can live with ADA, agree with RH type 2. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:54:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19079 for ; Wed, 13 Feb 2002 14:54:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23295; Wed, 13 Feb 2002 12:54:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01269; Wed, 13 Feb 2002 11:54:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJrrFh017436 for ; Wed, 13 Feb 2002 11:53:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJrrs6017435 for mobile-ip-dist; Wed, 13 Feb 2002 11:53:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJroFh017428 for ; Wed, 13 Feb 2002 11:53:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08493 for ; Wed, 13 Feb 2002 11:53:52 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07223 for ; Wed, 13 Feb 2002 11:53:51 -0800 (PST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id <1L6R313N>; Wed, 13 Feb 2002 14:47:31 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 13 Feb 2002 14:47:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > This last point is not a fair characterization: I can come up > with many > links that > would be abused if piggybacking was NOT used, and the > receiver severely > bruised. > Such a statement can be written for any functionality, replace > 'piggybacked BU' with > your least favorite functionality. I hope this does not show > a bias of > the DT. > Cedric, No, it was an attempt to capture assertions made on the list. Phil From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 14:55:56 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19115 for ; Wed, 13 Feb 2002 14:55:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02242; Wed, 13 Feb 2002 11:55:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01671; Wed, 13 Feb 2002 11:55:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJsUFh017453 for ; Wed, 13 Feb 2002 11:54:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DJsUHX017452 for mobile-ip-dist; Wed, 13 Feb 2002 11:54:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DJsBFh017438 for ; Wed, 13 Feb 2002 11:54:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08534 for ; Wed, 13 Feb 2002 11:54:13 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19541 for ; Wed, 13 Feb 2002 12:54:13 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DJsCe28159 for ; Wed, 13 Feb 2002 11:54:12 -0800 (PST) Message-ID: <00bd01c1b4c7$fc8e99a0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 13 Feb 2002 11:52:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. > > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible > Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > DISAGREE. > 2. Specify that piggybacking always be an option. > > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > AGREE. > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > > Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links > Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node > DISAGREE > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. > DISAGREE. The tendency in the MIP group in the past has been to avoid facing up to cases where the properties of wired networks and wireless networks are different enough that changes are required to efficiently support IP on wireless networks. I think this is another such case. As I mentioned previously, DoCoMo uses piggybacking to good effect in i-mode, that indicates to me that it is likely to be useful. Without further analysis, of course, it is hard to say how useful and whether the tradeoff is worth it, but it is one implementation data point. It has been mentioned before that Cedric and Charlie's draft (which I admit to not having read) also lists some possible benefits of piggypacking. Therefore, I think there is enough uncertainty about this point to not take the drastic action of prohibiting piggybacking. If changes are required in IPsec, then I think we ought to ask for them. > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. > DISAGREE. Requring RR for BU security if the BU is between the MN and an AR or LMM agent in the local foreign network will have serious performance impact. Requiring just CGA or something similar would probably have less impact. In any case, the MN should be able to establish a BSA when it enters the foreign network and use that to secure any routing update signaling with entities in the foreign network. > (c) Binding update messages for both HAs and CNs, binding > acks, DISAGREE > RR messaging, and CAN LIVE WITH. Since I think there is no other choice. > CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages > DISAGREE. I believe a through study is needed of CGA or CGA-like solution before we jump into standardizing anything here. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 15:16:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19644 for ; Wed, 13 Feb 2002 15:16:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00363; Wed, 13 Feb 2002 13:16:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13812; Wed, 13 Feb 2002 12:16:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DKEmFh017630 for ; Wed, 13 Feb 2002 12:14:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DKEmJD017629 for mobile-ip-dist; Wed, 13 Feb 2002 12:14:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DKEiFh017622 for ; Wed, 13 Feb 2002 12:14:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08354 for ; Wed, 13 Feb 2002 12:14:47 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13104 for ; Wed, 13 Feb 2002 13:14:46 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BC7C02E68 for ; Wed, 13 Feb 2002 15:14:45 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 28301151D for ; Wed, 13 Feb 2002 14:14:45 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DKEiT27733; Wed, 13 Feb 2002 15:14:44 -0500 (EST) From: Brian Haley USG Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1DKEib31968; Wed, 13 Feb 2002 15:14:44 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA03564; Wed, 13 Feb 2002 15:14:42 -0500 Message-Id: <200202132014.AA03564@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Wed, 13 Feb 2002 15:14:42 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The DT has come to the following conclusions: > > (a) For reasons of timing, we do not recommend extending > IPsec specifications in any manner. Therefore, we feel > that approaches that rely on better IPsec policy > granularity should not be considered. CAN LIVE WITH. If I'm using IPsec between a MN and CN/HA, I'll use it for every packet, not just BUs. > (b) We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. DISAGREE. IPsec AH covers enought header fields so that we know the packet wasn't changed in flight. RR seems like overkill. > (c) Binding update messages for both HAs and CNs, binding > acks, DISAGREE. There is no reason a MN can't set a bit (P-bit?) to tell the HA/CN it should not be sent a piggybacked BA or BR. We already know that most CNs support piggybacking (either Ericsson or UNH had a ping test last Connectathon that piggybacked), and it's easy to control the BU behavior on a MN. If the CN doesn't wish to have the MN piggyback in the future, it can just return a new < 128 status code - this would cover the MN to MN case. So technically it looks to me like there's a way to eliminate all but the first Binding piggyback. > RR messaging, and CGA messaging are to be > implemented as a new message set without the ability > to piggyback data packets on those messages CAN LIVE WITH. > The basis on this recommendation is as follows: > > - The DT recognizes the potential benefits of piggybacking. How can the DT recognize there is a *potential* benefit, but decide to kill piggybacking? -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 16:56:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22399 for ; Wed, 13 Feb 2002 16:56:42 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20257; Wed, 13 Feb 2002 14:56:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09726; Wed, 13 Feb 2002 13:56:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DLtUFh018084 for ; Wed, 13 Feb 2002 13:55:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DLtUac018083 for mobile-ip-dist; Wed, 13 Feb 2002 13:55:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DLtRFh018076 for ; Wed, 13 Feb 2002 13:55:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06126 for ; Wed, 13 Feb 2002 13:55:30 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22126 for ; Wed, 13 Feb 2002 13:55:30 -0800 (PST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1DLtTv09288 for ; Wed, 13 Feb 2002 15:55:29 -0600 (CST) Message-ID: <3C6AE0CB.4040704@alcatel.com> Date: Wed, 13 Feb 2002 15:55:23 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <00bd01c1b4c7$fc8e99a0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello James, Sorry but I could not get the relationship between i-mode and BU piggbacking. i-mode is a technology implemented and deployed by DoCoMo in Japan where DoCoMo has market domination on circuit-switched 2G cell phone system called PDC and using IPv4. MIPv4 does have BU piggbacking. The term piggbacking is used in other contexts such as in TCP, TCP piggbacks data with ACKs, so that should also provide some justification for BU piggbacking in MIPv6? Regards, Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 17:04:33 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22525 for ; Wed, 13 Feb 2002 17:04:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20118; Wed, 13 Feb 2002 15:04:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12863; Wed, 13 Feb 2002 14:04:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DM3IFh018135 for ; Wed, 13 Feb 2002 14:03:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DM3INh018134 for mobile-ip-dist; Wed, 13 Feb 2002 14:03:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DM3FFh018127 for ; Wed, 13 Feb 2002 14:03:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12416 for ; Wed, 13 Feb 2002 14:03:17 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23476 for ; Wed, 13 Feb 2002 15:03:16 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DM3Ek16906 for ; Wed, 13 Feb 2002 23:03:14 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA06532 for ; Wed, 13 Feb 2002 23:03:14 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DM3Eg12079 for ; Wed, 13 Feb 2002 23:03:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132203.g1DM3Eg12079@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation In-reply-to: Your message of Tue, 12 Feb 2002 01:05:28 +0200. <3C684E38.9070406@piuha.net> Date: Wed, 13 Feb 2002 23:03:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: 1. INTRODUCTION =============== Normal, stateless and filter-based ingress filtering can't deal with these attacks. => (CLARIFICATION, DISAGREE) stateless and filter-based ingress filtering is assumed up to the end of the introduction. I understand that "ingress filtering" is already very long to type/read but this should make clear or some next statements are at least misleading. 1.4. FURTHER BACKGROUND INFORMATION => (ISSUE) the attack against anti-spoofing filtering (i.e. HAOs with the Home Address (H@) inside the site) is not addressed and is a *real* security problem if such H@s are valid, i.e. there is a Home Agent (HA) in the site. 2. ALTERNATIVES =============== 2.2. INFRASTRUCTURE-BASED INGRESS FILTERING => (ISSUE) you make the assumption that the verification of the H@ is critical: - there is no proof (no argument in fact) of this - unicast RPF check ingress filtering never requires the verification of source addresses, it just checks if source addresses are plausible (aka topologically correct) - (note: if you maintain this opinion, can I explicitely quote you in my to-write draft "RFC 3041 considered harmful"?) In infrastructure-based ingress filtering this is done this with the help of a global infrastructure such as AAA. => (CLARIFICATION) My draft tries to make clear that such a global infrastructure is better but not necessary. So this alternative doesn't reflect what I proposed. The main benefit of this scheme is the level of control it allows. => of course, a stronger hypothesis should give a stronger result (:-). 2.3. INFRASTRUCTURE-LESS INGRESS FILTERING A better way would be to come up with an ingress filtering scheme that does not require a global infrastructure. We note that such schemes appear to have to be based on similar principles as the Route Optimization is based on. This is because the infrastructure and the RR/CGA methods are the only known ways to have some assurance of address ownership. => (CLARIFICATION) this introduction shows clearly you think the HAO solution must solve the address ownership problem too. The drawback of this scheme include the following. => even the author of this proposal recognized it is unfeasible. 2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS A variation of this approach is that HAOs could additionally be accepted also if there's an IPsec SA between the MN and the CN. (In this case, however, the SA must be established using traditional means such as local PKIs and newer research results on self-signed certificates or opportunistic IPsec would not suffice here.) => (ISSUE) I disagree with this statement: if the SA uses the H@ (in fact it must because of the HAO with IPsec processing rule) or the packet is fake and IPsec processing will reject it, or the packet is not fake and IPsec processing will by side effect prove the authenticity of the source. Of course (but this should be a standard IPsec requirement) the IPsec transform should include authentication. The self-signed certificates & co stuff has nothing to do here, if someone is ready to accept unsafe ways to establish IPsec SAs he is ready to manage protected tunnels with unknown "road warriors"... PROPOSAL: HAOs could be accepted as soon as the CN can verify the validity of the H@: - using BCE (Co@ (in IPv6 header) and H@ (in HAO) match the BCE) - using IPsec SA which uses the H@ as the source address selector (the knowledge of the sharedsecret(s) of the SA proves the source of the packet, the source address in the IPv6 header does *not* matter) The only possible problem with IPsec is DoS against the authentication computing but this threat is already in IPsec with or without HAO (reread RFC 2401 5.2.1 if you don't know why). 2.4.1. NATURE OF BCE STATE A few observations of the effects can be made: => basically BCE state will become hard state. => (CLARIFICATION) I'd like to get the (obvious) consequences for Binding Acknowledges (should be required) and Binding Requests (still useful? the opposite (binding done?) more interesting?). 2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS In this alternative, a traceback of the attacker is performed by having the CN include additional information in the reflected packets. In particular, the CN could include the claimed source address of the original packet in the response, e.g. in the "OAH Destination Option". => (CLARIFICATION) This should be handled automatically, i.e. by the kernel. So there are immediate issues: - what kind of state? how long to keep it? - what to do if only some packets have HAO? - what to do if there is not enough memory to handle the state? - trivial performance attack with rogue packets (force the additional of an OAH to any packet for the victim) etc. A larger drawback of this scheme is that there are IPv6 socket API implications, at least for UDP applications, in order to ensure that the response sent due to a request containing a HAO always contains a OAH option. => (ISSUE) This is based on an incorrect assumption about possible implementations. Of course this solution is unfeasible if it is not transparent to applications... 3. DISCUSSION ============= 4. RECOMMENDATION ================= The design team recommends alternative d to be applied (R1). We expect MIPv6 deployment to be soonest and largest if we choose d. => CAN TOLERATE (R1) The design team recognizes that moving non-RO traffic to bidirectional tunneling has consequences. We do not believe the technical consequences to delays etc. are significant. It may be in fact be a cleaner approach to have a 2-level solution => (CLARIFICATION) you should exhibit a case where such a 2-level solution for a security problem did work (good luck :-). Due to these considerations, the design team additionally recommends that (R2) MIPv6 bidir and RO parts be kept in the same RFC and advanced at the same time, => CAN TOLERATE (R2) and (R3) RO should be required to implement in all IPv6 nodes, as implied by RFC 1726. => DISAGREE (R3): this kind of requirement is *not* in the scope of the mobile-ip WG. It is clearly the job of the IPv6 WG. The only acceptable thing is a recommendation from the mobile-ip WG to the IPv6 WG to consider such a requirement for all IPv6 nodes. BTW it will be fine to exactly describe what is required and what is not required, same for default configuration, etc. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 17:21:17 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22847 for ; Wed, 13 Feb 2002 17:21:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27907; Wed, 13 Feb 2002 15:21:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18980; Wed, 13 Feb 2002 14:21:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMK9Fh018337 for ; Wed, 13 Feb 2002 14:20:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DMK8RJ018336 for mobile-ip-dist; Wed, 13 Feb 2002 14:20:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMK5Fh018329 for ; Wed, 13 Feb 2002 14:20:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08171 for ; Wed, 13 Feb 2002 14:20:07 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00739 for ; Wed, 13 Feb 2002 15:20:06 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DMK4k18153 for ; Wed, 13 Feb 2002 23:20:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA06772 for ; Wed, 13 Feb 2002 23:20:05 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DMK4g12143 for ; Wed, 13 Feb 2002 23:20:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132220.g1DMK4g12143@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] [CLARIFICATION] Home Address Option: design team recommendation In-reply-to: Your message of Tue, 12 Feb 2002 09:48:57 +0200. Date: Wed, 13 Feb 2002 23:20:04 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Note: this can also be used for spoofing attacks (e.g. exploits in stateless protocols like UDP (unless TCP sequence numbers are guessed)) unless destination site implements a firewall policy that examines HAO of the packet and rejects it if it belongs to the site provided that it isn't a Home Address of a roaming local node. => agree: this point was completely missed... I don't think all that many firewalls will implement checks like this. => the proposed solution (R1) has to prove to be a solution of this (I believe it is the case but this seems to be an argument against CGAs without RR) Note: this could be implemented in a similar fashion as routing header: "segments left" decremented and if it reaches 0, the option would no longer be processed. => nice semantics but the packet is not forwarded, just responded to... However, as it seems ADA will be preferred over RH#1, => not yet done! these kind of semantics probably don't make sense. => your proposal saves one option type (waouh!) and makes detection of reflection attacks very easy (reception of burnt HAO when the node is not mobile)... Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 17:29:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22983 for ; Wed, 13 Feb 2002 17:29:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01602; Wed, 13 Feb 2002 15:29:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21470; Wed, 13 Feb 2002 14:29:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMSXFh018422 for ; Wed, 13 Feb 2002 14:28:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DMSWbT018421 for mobile-ip-dist; Wed, 13 Feb 2002 14:28:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMSTFh018414 for ; Wed, 13 Feb 2002 14:28:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21162 for ; Wed, 13 Feb 2002 14:28:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08287 for ; Wed, 13 Feb 2002 15:28:30 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA17763; Wed, 13 Feb 2002 14:28:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1DMS7h16723; Wed, 13 Feb 2002 14:28:07 -0800 X-mProtect:  Wed, 13 Feb 2002 14:28:07 -0800 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdjyZ7ud; Wed, 13 Feb 2002 14:25:28 PST Message-ID: <3C6AE7D8.72D376CA@kniveton.com> Date: Wed, 13 Feb 2002 14:25:28 -0800 From: "T.J. Kniveton" Organization: NOKIA Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Youn-Hee Han Subject: Re: [mobile-ip] Valid Period of Home Address? References: <005d01c1afba$2fed1910$462d98a3@disys42.korea.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Youn-Hee Han wrote: > > Before I read the MIPv6 draft, I believed the followings > "After the MN acquires a home address, the home address is fixed at the MN and is permanent." > That is, I have assured that the home address of a MN becomes the identifier of the MN. > > In many places in the MIPv6 draft, however, I can find that the eternity of home address is not true. > Of course, the home network renumbering and the initial address configuration cause the home address to be configured by using 'ICMP Mobile Prefix Solicitation'. But, the ICMP message is also used in order to refresh home addresses before the expiration of their validity. > Also, I think that the Duplicate Address Detection is also another evidence of the short-lived of home address. > > If the home address is not permanent. I am worried about the followings. > > 1. If the home address is changed, how does a correspondent node open any TCP connection with the MN after the changes? > > 2. We cannot find any terms about the valid period of home address. Is the period depended of an implementation? > > I admit that any temporary home address should be used in some cases. > However, the temporary home address is conflict with the following goal of Mobile IP. > > "Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet" > > Thanks in advance. > Best regards, Hi Youn-Hee. Thanks for your question about home address validity. Since no one else has commented, I'll take a crack at it.. This is a subject that came up last year when we discussed renumbering. There is an ongoing question about whether IPv6 addresses have the same semantics in identifying a node as was the case in IPv4. It seems, as you observed, that there is a bit less permanence in IPv6 addresses for this purpose -- or at least *potential* for less permanence. Nevertheless, my sense of this, so far, is that the goal is to make IPv6 addresses long-lived in a similar way to how they are in IPv4. It is certainly desirable to be able to have a known and persistent address for the CN to contact the MN (and vice versa) and other well-known nodes. Keep in mind that while a router advertisement or mobile prefix advertisement from the HA might have a given lifetime for a prefix, that doesn't mean the prefix will be invalid at the end of that life -- in the same way a DHCP lease could expire in IPv4 but be renewed before expiration, the IPv6 prefixes should be constantly refreshed by the router. Ultimately, all of this will be subject to administrative policies, since implementations will be tunable by the administrator for a site. But renumbering and address changes should be an unusual event. To answer question 2, please take a look at RFC 2461 p. 30 (Valid Lifetime and Preferred Lifetime), and pp. 78-79 (Renumbering), as well as RFC 2462, pretty much the whole thing. These documents focus more on the mechanisms for creating and deprecating addresses, and focus less on policies for how long an address should persist for. But there is no reason that IPv6 prefixes can't be similar to IPv4 subnets - i.e. infinite for all intents and purposes. Hope this is at least somewhat helpful. -TJ -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 17:34:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23108 for ; Wed, 13 Feb 2002 17:33:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03816; Wed, 13 Feb 2002 15:33:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23241; Wed, 13 Feb 2002 14:33:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMWvFh018514 for ; Wed, 13 Feb 2002 14:32:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DMWvSg018513 for mobile-ip-dist; Wed, 13 Feb 2002 14:32:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMWrFh018506 for ; Wed, 13 Feb 2002 14:32:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11318 for ; Wed, 13 Feb 2002 14:32:55 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03415 for ; Wed, 13 Feb 2002 15:32:54 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1DMWqk19092 for ; Wed, 13 Feb 2002 23:32:52 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA06982 for ; Wed, 13 Feb 2002 23:32:53 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1DMWrg12196 for ; Wed, 13 Feb 2002 23:32:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202132232.g1DMWrg12196@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation In-reply-to: Your message of Wed, 13 Feb 2002 18:38:52 +0200. <032701c1b4ac$ec24e4e0$8a1b6e0a@arenanet.fi> Date: Wed, 13 Feb 2002 23:32:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Good point, we didn't think of this! Do you have an understanding how widespread that practise is? => far too much! (BTW my dictionary says practice (noun), practise (verb)) Also, do we have other functionality where connectivity depends on ability to get through ICMP packets? => mobile to mobile communication with simultaneous movement (BUs never reach peers until a fallback path though a HA is used). For instance, with v4, fragmentation was handled by routers but in v6 we have e2e fragmentation and ICMP Packet Too Big. This would appear to have a similar problem, i.e. you wouldn't get anywhere that has a 1280 byte MTU if your local link was 1500 bytes. => path MTU discovery is a very well known victim of ICMP filtering madness. Just ask any IPsec VPN implementer/user. Anything else similar, and do we have experience on how well or bad this works in practise? => very bad in practice (what does happen to ICMPs with NATs?). Supposed to be better for IPv6... As an alternative we could also specify a MIPv6 specific message to say the same thing as the ICMP ;-) => a binding nack? which sounds a bit like the arguments in the RH case. Except this time the fear is ICMP, not RH. Could Binding Request be used for this purpose, with some flag? => this is a job for binding (negative) acknowledges, we have just to define some new status (perhaps not so new, the status list has a long history with 16 steps :-). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 17:55:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23519 for ; Wed, 13 Feb 2002 17:55:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13167; Wed, 13 Feb 2002 15:55:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16011; Wed, 13 Feb 2002 14:55:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMriFh018714 for ; Wed, 13 Feb 2002 14:53:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1DMrhUb018713 for mobile-ip-dist; Wed, 13 Feb 2002 14:53:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMreFh018706 for ; Wed, 13 Feb 2002 14:53:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15795 for ; Wed, 13 Feb 2002 14:53:38 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAB17973 for ; Wed, 13 Feb 2002 15:53:37 -0700 (MST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1DMrae05817 for ; Wed, 13 Feb 2002 14:53:36 -0800 (PST) Message-ID: <01f301c1b4e1$0bb7a2f0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <00bd01c1b4c7$fc8e99a0$7e6015ac@T23KEMPF> <3C6AE0CB.4040704@alcatel.com> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 13 Feb 2002 14:44:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The i-mode network piggybacks signalling with data traffic, specifically with HTTP. What I intended to say is that this is one data point that piggybacking is useful for radio networks. That's all I intended to say. jak > Sorry but I could not get the relationship between i-mode and BU > piggbacking. i-mode is a technology implemented and deployed by DoCoMo > in Japan where DoCoMo has market domination on circuit-switched 2G cell > phone system called PDC and using IPv4. MIPv4 does have BU piggbacking. > The term piggbacking is used in other contexts such as in TCP, TCP > piggbacks data with ACKs, so that should also provide some justification > for BU piggbacking in MIPv6? From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 19:07:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24615 for ; Wed, 13 Feb 2002 19:07:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22425; Wed, 13 Feb 2002 16:07:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27499; Wed, 13 Feb 2002 16:07:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E05VFh018874 for ; Wed, 13 Feb 2002 16:05:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E05VMG018873 for mobile-ip-dist; Wed, 13 Feb 2002 16:05:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E05SFh018866 for ; Wed, 13 Feb 2002 16:05:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06998 for ; Wed, 13 Feb 2002 16:05:31 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14828 for ; Wed, 13 Feb 2002 17:05:30 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1E05Sk26897 for ; Thu, 14 Feb 2002 01:05:28 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id BAA08296 for ; Thu, 14 Feb 2002 01:05:29 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1E05Sg12722 for ; Thu, 14 Feb 2002 01:05:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202140005.g1E05Sg12722@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation In-reply-to: Your message of Tue, 12 Feb 2002 11:52:08 EST. Date: Thu, 14 Feb 2002 01:05:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: We need to get closure on the Working Group's stance on piggybacking of binding update messages. => for quick comments before reading the 35 other messages of the thread! Jari documented the tradeoffs of using piggybacking with IPsec... => I wrote and presented at the last IETF a generalize multi-payload proposal for IPv6 (draft-dupont-ipv6-payload-00.txt) in order to get opinions from the IPv6 folk (they were no, kill that, I become sick, etc). BTW I still wait for some help in order to produce a second version of this draft. Jari's draft was written a week before so has still Robert Elz' proposal in reference [13]. 1. Specify that piggybacking of binding update messages not be used with MIP v6. => AGREE (you may not put two things in the same packet when policies for the two things can be different. IPsec is just an example of this basic problem). 2. Specify that piggybacking always be an option. => DISAGREE Pros: - allows some improvement in terms of throughput and latency that may be relevant on certain types of links => DISAGREE: this argument only proves the piggy-backing "optimization" should be done by the link-layer. Cons: - the improvements are only relevant on certain types of links and thus this is inclusion of functionality at layer 3 that is useful only for certain layer 2s => AGREE - need policy extensions to IPSEC (and corresponding implementation modifications) for those cases in which IPSEC is used to protect BUs. => AGREE but this is true for any kind of policies, not only IPsec. 3. Specify that piggybacking is an option, but subject to negotiation between the two communicating nodes. => DISAGREE: this assumes the peers has the full knowledge of applied policies to traffic between them. Cons: - requires some more specification of signalling on whether or not to use piggybacking and additional behavior in the mobile node => AGREE (please apply KISS principle). The DT has come to the following conclusions: (a) For reasons of timing, we do not recommend extending IPsec specifications in any manner. Therefore, we feel that approaches that rely on better IPsec policy granularity should not be considered. => AGREE (b) We recommend that when IPsec protection is used, it is always used in *addition* to RR (or CGA) methods, not as => note the BU recommendations are "RR" or "RR + CGA", not "RR" or "CGA". a replacement. Thus RR (or CGA) methods would be used to protect MN - CN Route optimization procedures even when IPsec is used. => 100% DISAGREE: IPsec protection with proper policies can provide far better security than any RR/CGA mechanism. (now I understand why I can smell of smoke :-) (c) Binding update messages for both HAs and CNs, binding acks, RR messaging, and CGA messaging are to be implemented as a new message set without the ability to piggyback data packets on those messages => AGREE (note I don't understand why there are other recommendations). The basis on this recommendation is as follows: - It seems very useful to be able to use IPsec ESP (with manual keying) for protecting the RR control packets => why manual keying? on the HA-MN path. If the IPsec selectors can't be used to distinguish those packets from data traffic the effect might be that lots of data packets (all that are tunneled through the HA) also become encrypted which would be a source of performance concerns for limited MN devices. => AGREE: BUs, BAs, RR, etc, should be "IPsec selectable" so have to be payloads (in the common IPv6 packet meaning). I'll come back tomorrow on (b) in order to understand. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 20:42:24 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25472 for ; Wed, 13 Feb 2002 20:42:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07754; Wed, 13 Feb 2002 17:42:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24990; Wed, 13 Feb 2002 17:41:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E1f0Fh019078 for ; Wed, 13 Feb 2002 17:41:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E1f0rI019077 for mobile-ip-dist; Wed, 13 Feb 2002 17:41:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E1ewFh019070 for ; Wed, 13 Feb 2002 17:40:59 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23511 for ; Wed, 13 Feb 2002 20:41:02 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA29245 for mobile-ip@sunroof.eng.sun.com; Wed, 13 Feb 2002 20:41:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1DMIsFh018293 for ; Wed, 13 Feb 2002 14:18:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12176 for ; Wed, 13 Feb 2002 14:18:56 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18692 for ; Wed, 13 Feb 2002 14:18:48 -0800 (PST) Received: from piuha.net ([62.248.150.36]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with ESMTP id <20020213221804.GAQS6990.fep07-app.kolumbus.fi@piuha.net> for ; Thu, 14 Feb 2002 00:18:05 +0200 Message-ID: <3C6AE681.4060504@piuha.net> Date: Thu, 14 Feb 2002 00:19:45 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation References: <200202132203.g1DM3Eg12079@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, thanks again for your in-depth comments! Some quick responses below: > PROPOSAL: HAOs could be accepted as soon as the CN can verify > the validity of the H@: > - using BCE (Co@ (in IPv6 header) and H@ (in HAO) match the BCE) > - using IPsec SA which uses the H@ as the source address selector > (the knowledge of the sharedsecret(s) of the SA proves the source > of the packet, the source address in the IPv6 header does *not* matter) Does this mean that you propose HAOs to be accepted either because there's an IPSec SA or because there's a BCE, and bidir tunneling otherwise? I think I could AGREE with that. > => (CLARIFICATION) This should be handled automatically, i.e. > by the kernel. So there are immediate issues: > - what kind of state? how long to keep it? > - what to do if only some packets have HAO? > - what to do if there is not enough memory to handle the state? > - trivial performance attack with rogue packets (force the > additional of an OAH to any packet for the victim) > etc. > > A larger drawback of this scheme is that there are > IPv6 socket API implications, at least for UDP applications, > in order to ensure that the response sent due to a request > containing a HAO always contains a OAH option. > > => (ISSUE) This is based on an incorrect assumption about > possible implementations. Of course this solution is unfeasible > if it is not transparent to applications... True, but you yourself listed some issues with the kernel approach. We didn't see a way out so we didn't consider it further. But it isn't certain that there's no way out. Do you see answers to your questions above, and a technical kernel solution? If yes, let's discuss it! > and (R3) RO should be required to > implement in all IPv6 nodes, as implied by RFC 1726. > > => DISAGREE (R3): this kind of requirement is *not* in the scope > of the mobile-ip WG. It is clearly the job of the IPv6 WG. > The only acceptable thing is a recommendation from the mobile-ip WG > to the IPv6 WG to consider such a requirement for all IPv6 nodes. Yes, AGREE... I think this was roughly what we meant though the text didn't exactly come out so. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 21:27:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26008 for ; Wed, 13 Feb 2002 21:27:48 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01727; Wed, 13 Feb 2002 19:27:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05904; Wed, 13 Feb 2002 18:27:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E2QZFh019393 for ; Wed, 13 Feb 2002 18:26:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E2QZw9019392 for mobile-ip-dist; Wed, 13 Feb 2002 18:26:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E2QWFh019385 for ; Wed, 13 Feb 2002 18:26:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02309 for ; Wed, 13 Feb 2002 18:26:34 -0800 (PST) Received: from flower.ce.chungnam.ac.kr (flower.comeng.chungnam.ac.kr [168.188.44.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08617 for ; Wed, 13 Feb 2002 19:26:31 -0700 (MST) Received: from schumann (beethoven.comeng.chungnam.ac.kr [168.188.46.68]) by flower.ce.chungnam.ac.kr (8.9.3/8.9.3) with SMTP id LAA21145 for ; Thu, 14 Feb 2002 11:27:42 +0900 (KST) Message-ID: <004101c1b4ff$0c7292e0$442ebca8@ce.cnu.ac.kr> From: =?ks_c_5601-1987?B?v8C47civ?= To: "IETF_MIP_WG_mailingList" Subject: [mobile-ip] Looking for mobile-ip sources.. Date: Thu, 14 Feb 2002 11:26:45 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C1B54A.7C27E040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C1B54A.7C27E040 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8gdGhlcmUuIA0KSSdtIGEgc3R1ZGVudCwgc3R1ZHlpbmcgdGhlIG1vYmlsZS1pcCByZWxh dGVkIHdvcmtzLg0KSSd2ZSBiZWVuIHRyeWluZyB0byBmaW5kIG1vaWJsZS1pcCByZWxhdGVkIHNv dXJjZXMuIGJ1dCBJIGNvdWxkbid0IGZpbmQgcHJvcGVyIG9uZS4gDQpJJ20gbG9va2luZyBmb3Ig TUlQIHNvdXJjZSBpbmNsdWRpbmcgJ1JPVVRFIE9QSU1JWkFUSU9OJy4NCklmIHRoZXJlIHdlcmUg YW55Ym9keSB3aG8gaGFzIE1JUC1yb3V0ZSBvcHRpbWl6ZWQgc291cmNlIG9yIGtub3dzIHdoZXJl IGkgY291bGQgZmluZCB0aGF0LA0KQ291bGQgeW91IGdpdmUgbWUgc29tZSBpbmZvcm1hdGlvbiBh Ym91dCBpdD8NClRoYW5rcyBmb3IgeW91ciBwYXRpZW5jZSBhbmQgSSBob3BlIGkgY291bGQgZ2V0 IHlvdXIgaGVscCA6cA0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCk15b3VuZy1Id2FuIE9oLg0KR3JhZHVhdGUg U3R1ZGVudCBEaXN0cmlidXRlZCBTeXN0ZW0gTGFiLiANCkRlcGFydG1lbnQgb2YgQ29tcHV0ZXIg RW5naW5lZXJpbmcsIENodW5nbmFtIE5hdGlvbmFsIFVuaXZlcnNpdHkgDQoyMjAgS3VuZyBEb25n LCBUYWVqb24gMzA1NzY0LCBLb3JlYSANClRFTDorODItNDItODIzLTYwNDkgRkFYOis4Mi00Mi04 MjItNDk5NyANCkUtbWFpbDogbWhvaEBjZS5jbnUuYWMua3IgDQoNCg0KDQo= ------=_NextPart_000_003E_01C1B54A.7C27E040 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI3MTIuMzAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGVsbG8gdGhl cmUuIDxCUj5JJ20gYSBzdHVkZW50LCBzdHVkeWluZyB0aGUgbW9iaWxlLWlwIHJlbGF0ZWQgDQp3 b3Jrcy48QlI+SSd2ZSBiZWVuIHRyeWluZyB0byBmaW5kIG1vaWJsZS1pcCByZWxhdGVkIHNvdXJj ZXMuIGJ1dCBJIGNvdWxkbid0IA0KZmluZCBwcm9wZXIgb25lLiA8QlI+SSdtIGxvb2tpbmcgZm9y IDxGT05UIGNvbG9yPSMwMDAwODA+TUlQIHNvdXJjZSBpbmNsdWRpbmcgDQonUk9VVEUgT1BJTUla QVRJT04nPC9GT05UPi48QlI+SWYgdGhlcmUgd2VyZSBhbnlib2R5IHdobyBoYXMgTUlQLXJvdXRl IG9wdGltaXplZCANCnNvdXJjZSBvciBrbm93cyB3aGVyZSBpIGNvdWxkIGZpbmQgdGhhdCw8QlI+ Q291bGQgeW91IGdpdmUgbWUgc29tZSBpbmZvcm1hdGlvbiANCmFib3V0IGl0PzxCUj5UaGFua3Mg Zm9yIHlvdXIgcGF0aWVuY2UgYW5kIEkgaG9wZSBpIGNvdWxkIGdldCB5b3VyIGhlbHAgDQo6cDxC Uj48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9G T05UPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIA0KPEJSPk15b3VuZy1Id2FuIE9oLjxCUj5HcmFkdWF0ZSBTdHVkZW50IERpc3RyaWJ1dGVk IFN5c3RlbSBMYWIuIDxCUj5EZXBhcnRtZW50IA0Kb2YgQ29tcHV0ZXIgRW5naW5lZXJpbmcsIENo dW5nbmFtIE5hdGlvbmFsIFVuaXZlcnNpdHkgPEJSPjIyMCBLdW5nIERvbmcsIFRhZWpvbiANCjMw NTc2NCwgS29yZWEgPEJSPlRFTDorODItNDItODIzLTYwNDkgRkFYOis4Mi00Mi04MjItNDk5NyA8 QlI+RS1tYWlsOiA8QSANCmhyZWY9Im1haWx0bzptaG9oQGNlLmNudS5hYy5rciI+bWhvaEBjZS5j bnUuYWMua3I8L0E+IDwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48QlI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_003E_01C1B54A.7C27E040-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:20:52 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28280 for ; Wed, 13 Feb 2002 22:20:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21309; Wed, 13 Feb 2002 19:20:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13055; Wed, 13 Feb 2002 19:20:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IEFh019666 for ; Wed, 13 Feb 2002 19:18:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3HsNj019502 for mobile-ip-dist; Wed, 13 Feb 2002 19:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HlFh019479 for ; Wed, 13 Feb 2002 19:17:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04609 for ; Wed, 13 Feb 2002 19:17:50 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02336 for ; Wed, 13 Feb 2002 19:17:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <215C954ACE13D4119B9400D0B73E9AB9047106D2@il02exm22.comm.mot.com> From: Bekiares Tyrone-CTB041 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIPv4: can a foreign agent broadcast an ARP request for the home address of a mobile node? Date: Wed, 2 Jan 2002 11:34:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 25 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I've been reading over the MIPv4 RFC-2002 and the updated Internet Draft in greater detail, and it appears to be somewhat ambigious as to whether or not a foreign agent can broadcast an ARP request for the home address of a mobile node. Page 59 of the updated Internet Draft "IP Mobility Support for IPv4, revised" states that "A Foreign agent MUST NOT use broadcast ARP for a mobile node's MAC address on a foreign network." Yet on page 66 of the same draft, it reads "Finally, while the mobile node is away from home, it MUST NOT reply to ARP Requests in which the target IP address is its own home address, **** unless the ARP Request is unicast by a foreign agent with which the mobile node is attempting to register or a foreign agent with which the mobile node has an unexpired registration ****" That last bit seems to imply the use of a unicast ARP request mechanism, which dosen't make any sense to me (anyone?). The original RFC basically has the same verbiage, but leaves out the word "unicast"... Why would the FA ever need to do an ARP request for the the mobile node's home address? Shouldn't it update its ARP cache based on the MIPv4 Registration Request (discussed on page 59 of the Internet Draft)? Thanks! + Tyrone Bekiares - Advanced Technology, Motorola From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:23:05 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28331 for ; Wed, 13 Feb 2002 22:23:05 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23480; Wed, 13 Feb 2002 20:22:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14006; Wed, 13 Feb 2002 19:22:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3LkFh019851 for ; Wed, 13 Feb 2002 19:21:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3LkVs019850 for mobile-ip-dist; Wed, 13 Feb 2002 19:21:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3LaFh019832; Wed, 13 Feb 2002 19:21:36 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12564; Wed, 13 Feb 2002 19:21:39 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29087; Wed, 13 Feb 2002 19:21:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1FD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jari Arkko Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RE: How to move forward in the HAO & ingress filter discussion Date: Tue, 15 Jan 2002 13:49:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Status: RO X-UID: 546 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis > I have a proposal. But first, let me make some observations: > > - Most people do seem to agree that HAO reflection is an > issue that needs to be dealt with somehow. > > => we have to deal with it but we don't need a stronger solution > than today ingress filtering which is a BCP, i.e. something like > a SHOULD. => But how can that be true ?? Today's ingress filtering is clearly insufficient for HAO issues. Or perhaps you mean we need a solution that doesn't have to be mandated (SHOULD instead of MUST) ? If so, this is too early to discuss, we don't have an agreement on a solution yet. I haven't heard anyone answering my question as to why reverse tunnelling by the MN thru the HA is so much worse than triangular routing, that we need to develop something new to fix the HAO problem 'only sometimes'. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:27:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28398 for ; Wed, 13 Feb 2002 22:27:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16104; Wed, 13 Feb 2002 20:27:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15179; Wed, 13 Feb 2002 19:27:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3QbFh020132 for ; Wed, 13 Feb 2002 19:26:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3QbH8020131 for mobile-ip-dist; Wed, 13 Feb 2002 19:26:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXK1019898 for ; Wed, 13 Feb 2002 19:26:30 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11736; Wed, 13 Feb 2002 19:18:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28006; Wed, 13 Feb 2002 19:18:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Mon, 7 Jan 2002 19:54:23 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] RE: Is RR only enough ? To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C1A1@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 235 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 1. You implied that today's MITM attacks (or at > least the ones you mentioned in this thread) > can be avoided be e2e encryption. The attack I'm > referring to can not be avoided by e2e encryption. If e2e security is done right any MiTM attack would just be capable of performing a DoS attack by preventing communication. "Done right" assumes that the peers some how know the identity of each other and the public keys associated with those identities and that's what is required to be able to securely be able to communicate with a known entity. > 2. If I understood you correctly, you were implying > that the MITM in the scenario you mentioned is > intercepting packets. I.e. the MITM has the ability > to receive the packets, modify them and hence cause > a situation where both a MN-CN connection 'goes > through him'. On the other hand, in the attack I'm > referring to, the MITM only needs to 'see' the > packets addressed to the Home address of the MN. > He doesn't need to intercept any packets. Yes, there is such a subtle difference. But Maruc Leech said in the MobileIP meeting in SLC that for on-path attacks we shouldn't worry about the distiction between an active and a passive attacker. This seem to make sense to me - if somebody uses ARP/ND spoofing to gain access on multi-access links or hacks a switch/router in the path it would be easy for them to modify packets. > So lets consider this scenario: > > - Bad Guy is on the path between the CN and the HA. > For simplicity lets assume Bad Guy is on an ethernet. > > - Bad Guy forms an address based on the RA on that > ethernet. Bad Guy also puts his card in promiscuous > mode. > > - Bad Guy sees one packet addressed to the MN's Home > address. From that he gets the CN's address and > the MN's home address (he could have the home address > before anyway, it would be public knowledge). > > - No Bad Guy can launch this attack regardless of whether > e2e security is used between the MN and CN. But without binding updates the additional piece that is needed in today's internet is to spoof the ARP packets for the routers' and victim's IP addresses and now all packets will go through the attacker. There is a subtle difference in that an ARP spoofing attack might be more "visible" than snooping the wire - if an admin happens to look at the content of the ARP cache during the attack the admin might observe that it doesn't look like the router's Ethernet address. But an admin is pretty unlikely to look. > I don't know how to assess whether an attack is > significantly worse than another, perhaps someone > can point me to some general guidelines, but AFAICS, > this attack (I mention above) seems to be significantly > different from the ones existing today. I agree there are differences but I find them rather subtle. I don't have a magic way to tell the difference other than by trying to put myself in the shoes of a determined attacker. If the attacker can get access to a multi-access link in the path what can be done? If the attacker can break a switch/router in the path what can be done? > Just to overload this email a bit, I'd like to suggest > that IF all agree that this attack is significantly > different from today's attacks we can choose between > two options I have in mind: > > - CGAs combined with RR as one obvious option I agree that CGA+RR is stronger than just RR. I'm just trying to make sure we all understand what the differences are in terms of residual attacks. > - Extending BU3WAY or BUSEC to make them BU4WAY :) > So in this case the MN would send 'half' the secret > through the HA, and the other half directly from > its CoA. The CN would also reply in both paths > (i.e. one to the Home address and one to the CoA). BU4WAY wouldn't address an attacker on the CN's link, right? I think it is easier to attack at the edges (where there are lots of hosts) than in the middle of the network. And even with BU4WAY an attacker between the CN and HA can just claim to itself be the CoA, thus it would be on both of the paths. > One assumption: ingress filtering on source addresses > is widely used. > > Based on this suggestion and the assumption above, > the attacker will not be able to use the MN's Home > address as a source address since the packet will be > dropped by ingress filtering. If the attacker is on the path between the HA and the CN it sits on the path where packets normally tracel what have the HoA as a source thus ingress filtering can't filter those out. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:32:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29409 for ; Wed, 13 Feb 2002 22:32:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18648; Wed, 13 Feb 2002 20:32:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16592; Wed, 13 Feb 2002 19:32:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3UYFh020343 for ; Wed, 13 Feb 2002 19:30:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3UWCZ020336 for mobile-ip-dist; Wed, 13 Feb 2002 19:30:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fh020208 for ; Wed, 13 Feb 2002 19:30:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16180 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28036 for ; Wed, 13 Feb 2002 19:18:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A4BA@yn-server1.yodanetworks.com> From: "Kota, Ravikumar" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Any pointer on mobile ip simulators Date: Tue, 8 Jan 2002 14:26:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 279 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Can anybody help me to get some light about simulators available for mobile ip and required equipment to run them. Thansk alot Ravikumar Kota From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:36:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29481 for ; Wed, 13 Feb 2002 22:36:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26860; Wed, 13 Feb 2002 20:36:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17448; Wed, 13 Feb 2002 19:36:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3Z5Fh020508 for ; Wed, 13 Feb 2002 19:35:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Z56Q020506 for mobile-ip-dist; Wed, 13 Feb 2002 19:35:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YmFr020456 for ; Wed, 13 Feb 2002 19:34:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12305 for ; Wed, 13 Feb 2002 19:19:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13960 for ; Wed, 13 Feb 2002 20:19:02 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: "Jean-Michel COMBES" To: Subject: RE: [mobile-ip] Routing headers: design team recommendation Date: Wed, 30 Jan 2002 15:39:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 987 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Comments concerning #2 (ie. about firewall and RH). IMO, there could be two FW policies : 1. Policy based on MIPv6-H@ This case, IMHO ,is the simplest policy but the most complex to administrate: the FW checks the last @ in the RH 2. Policy based on MIPv6-Co@ In this case, the FW checks the last address in the RH (ie. RH-@[Segments Left]). If this is a MIPv6-H@ (ie. not topologically correct), then it checks the RH-H@[SL-1] and then resolves the case regarding its policy. Comments are welcome :-) PS : I am not a FW vendor, so I think it would be better if some FW guys could give their opinions. Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Erik Nordmark > Envoye : mercredi 23 janvier 2002 21:35 > A : mobile-ip@sunroof.eng.sun.com > Objet : [mobile-ip] Routing headers: design team recommendation > > > The MIPv6 security design team is trying to resolve the issues > around routing headers as used by MIPv6. > > This note specifies the design teams' motivation and current position. > In order to move forward in an efficient manner it would be beneficial if > responses could make it clear whether it is > - a clarification (by putting CLARIFICATION: in the subject field), > - an issue with a particular point (by putting ISSUE: in the > subject field), > - disagreement with the conclusion (by putting CONCLUSION: in > the subject > field) > > INTRODUCTION > ============ > > There is background information on the security issues around > MIPv6's use of the routing header in > draft-savola-ipv6-rh-ha-security-01.txt. > This note explores how to move forward on the routing header issue. > > Today in IPv4, firewalls block IPv4 source routes by default. > The original motivation for this was that the TCP/IPv4 > implementations reverse > the source route received in a SYN and use it for the connection. > This means > that if source routes are allowed and hosts do any form of access control > based on the source IP address (such as UNIX r* commands) they could be > trivially spoofed. > > In an IPv6 world the situation is different. > IPv6 nodes MUST NOT reverse an unauthenticated (with IPsec) > routing header. > Thus routing headers can't be used to spoof IP address based > access control. > (Of course, this doesn't mean that IP address based > access control is good security - it is still a bad and grossly > insufficient > form of security - but folks might end up doing it when porting > applications > from IPv4 to IPv6). > > When there is an IPv6 firewall in place and it wants to prevent > inside node A > from communication externally (for a subset or all protocols/port > numbers) > while allowing inside node B to communicate externally (for those > protocols/ports) it needs to ensure that a routing header can't > be used to > reach node A via node B (where B might be a host or a router). > > ALTERNATIVES > ============ > > There seem to be three fundamentally different ways to approach this: > 1. Make the inside nodes (hosts and routers) be "safe" enough in their > handling of routing headers that the firewall can avoid > specific checks > on the presence of the routing header as well as the IP > addresses contained > in the RH. > > 2. Make the firewall understand the routing headers and filter based on > their content. > > 3. Try to simplify things by not using Routing Headers for MIPv6 > > Make RH "safe enough" > --------------------- > > The implications of approach #1 seem to be draconian for other use of > the routing header. > Not only can hosts not process routing headers and send the > packet out (the > same or a different interface), but internal routers cannot > process routing > headers either. > If a router processes the routing headers then the above A/B > scenario can be > used to bypass the firewall policy for host A by source routing > packets via > the router B to A. > > Thus the implications of #1 are likely to be that all hosts and > routers must > not process any routing headers and forward the packet. The only routing > header processing that would be allowed would be for a MN to > process a RH > where the packet doesn't leave the MN. > > Thus in effect routing headers would not be very useful for the initially > intended purpose; they would only be useful for the MIPv6 usage. > > > Make the firewall RH aware > -------------------------- > > When looking at #2 we need to understand what type of filtering a > firewall would need to have to prevent the A/B bypass while still allowing > MIPv6 to function. > > There are several things needed for MIPv6 to function. > We need to be able to allow: > A. CNs inside the firewall need to be able to use RH to send to > MNs outside > the firewall. > B. "visiting" MNs i.e. MNs who have a Home Address outside the firewall > and a CoA inside the firewall. > C. "local" MNs i.e. MNs where both the HoA and CoA are inside the > firewall. > > [Note that in general allowing A, B, and/or C might be subject to site's > firewall policy in general. Hence the use of "need to be able to > allow" above.] > A above doesn't cause any problems since allowing outbound RH through > the firewall doesn't cause problems with the simple rules that A can't > communicate externally. > However, if the firewall rules are more complex as in A only being able > to communicate with a specified external IP address then there are issues > if that external node is a MN and A would use a routing header > when sending > to the MN. > > The case B looks like an external entity sending a packet with a > destination > being inside the firewall with the subsequent hop (in the RH) > being outside > of the firewall. > > Possible rules for a firewall to apply in approach #2 for packets > inbound to the site would be: > 1. If the destination address is not inside the firewall then > the firewall would presumably drop it > 2. If there is no RH or an RH with zero elements then > follow non-MIPv6 firewall policy > 3. If the RH has more then one element then > treat it as a non-MIPv6 routing header (whatever policy > that is subject > to) > 4. If one element RH with the address in the RH being external to the site > allow it (assuming "visiting" MNs are allowed) > 5. If one element RH with the address in the RH being internal verify > that the address in the RH is allowed to communicate externally with > the protocol/port number. If so allow the packet with the RH. > > The above firewall rules are somewhat complex and they can't, by the > very nature of the routing header, prevent source routing. > For instance, rule #4 means that packets can be source routed through > the site and back out again, and rule #5 allows some internal > source routing. > Thus this approach assumes that there isn't a perception that > IPv6 firewalls > need to block actual source routing while allowing the MIPv6 use > of routing > headers. There is also a concern that the existing IPv4 firewall behavior > of blocking source routing might be carried forth into IPv6 firewalls. > Should this happen there is a failure case where route optimization > is established through a Binding Update but the data packets, with the RH, > are dropped. If the CN somehow decides to discard the binding cache entry > and send through the HA, it is likely that this would anew result in a > Binding Update. > Thus if this approach is taken it would seem prudent to make MIPv6 robust > against packets with RH being discarded. > > Define a MIPv6 specific thing instead of using RH > ------------------------------------------------- > > An open question is to what extent approach #3 would make things > significantly > simpler. The non-RH packet format could be to e.g. define a new > destination > option, define a new extension header, define a new routing header type, > or use IPv6_NO_SRC as specified in > draft-deering-ipv6-encap-addr-deletion-00.txt. > The following discussion doesn't assume any particular of the above > encodings - it just assumes that it is a different encoding than the > current routing header so that the firewall can have different policies > for source routing and MIPv6. > > For all the encodings it is assumed that the rules are that > 1) only a single address is contained in the encoding (just like a single > element routing header), and > 2) the receiving node never forwards the packet after processing it. > > The encoding that is most consistent with the Home Address Option would > be to define a destination option carrying the Home Address for the > destination. This could be name the alternate (or "outer"? > "upper layer"?) destination address option. > If this approach is taken it might make sense to rename the Home > Address Option to have a similar name e.g. the Alternate Source > Address Option. > RECOMMENDATION > ============== > > The design team is leaning towards #3 at the moment. One > reason for this is that this would remove any suspicion that firewall > administrators have for the use of the Routing Header and > which might consequently lead to disabling MIPv6 because of these > fears. Also, the firewall rules necessary to process the Routing > Header are complex and accidental disabling of MIPv6 might also > occur. The use of the Routing Header for other purposes would > also not be affected. There are also drawbacks in alternative #3. > One such issue is that existing MIPv6 implementations have to > be changed. We feel that this drawback is offset by the expected > wider usability of MIPv6 as a result. This change will also imply > a substantial document modification for the MIPv6 I-D. This > does not appear to be a structural change, however, and in > general we feel that direct procedure is easier to describe than > attempting to describe some additional rules to constrain the use > of the Routing Header. Finally, alternative #3 might lead us to > depend on the external work such as the new tunnel encapsulation > work at IPNG. The design team feels that we should stay away > from these non-MIPv6 solutions due schedule issues as well > as in the interests of making a self-contained RFC. > > --- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:37:07 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29511 for ; Wed, 13 Feb 2002 22:37:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22962; Wed, 13 Feb 2002 19:36:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17538; Wed, 13 Feb 2002 19:36:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3Z3Fh020501 for ; Wed, 13 Feb 2002 19:35:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Z3Qn020498 for mobile-ip-dist; Wed, 13 Feb 2002 19:35:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YmFj020456 for ; Wed, 13 Feb 2002 19:34:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12282 for ; Wed, 13 Feb 2002 19:19:03 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13951 for ; Wed, 13 Feb 2002 20:19:02 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201301108.g0UB8tg37938@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 28 Jan 2002 19:47:53 +0100. Date: Wed, 30 Jan 2002 12:08:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 982 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Excuse me but I think I missed an episode : 1. at first, RH is said to be dangerous [Why not ...] => not exactly, RH is said to need a careful usage so MIPv6 use and other uses interfere in careful usage requirements (i.e. if we fix it for MIPv6 we impede other uses). 2. after, one idea to replace RH functionality is to create a new DO [Why not ...] => there are 4 propositions, one is a new DO. 3. and now, it is proposed to place this new DO between the fragment header and the ... RH [!?!] => there is an issue about the position of the DO header with the DO... This shows a new RH type is a good alternative to a new DO. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:37:24 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29538 for ; Wed, 13 Feb 2002 22:37:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22982; Wed, 13 Feb 2002 19:36:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17565; Wed, 13 Feb 2002 19:36:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3Z3Fh020500 for ; Wed, 13 Feb 2002 19:35:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Z3W7020499 for mobile-ip-dist; Wed, 13 Feb 2002 19:35:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YmFn020456 for ; Wed, 13 Feb 2002 19:34:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12302 for ; Wed, 13 Feb 2002 19:19:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15112 for ; Wed, 13 Feb 2002 20:19:03 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C61479A.9DEB3464@lmf.ericsson.se> Date: Wed, 06 Feb 2002 17:11:22 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, mat@cisco.com CC: john.loughney@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation References: <0C1353ABB1DEB74DB067ADFF749C4EEF5D95AB@esebe004.NOE.Nokia.com> <3C60F092.FE30AB1F@lmf.ericsson.se> <15457.17596.186810.603818@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Jari Arkko writes: > > However, I do *not* believe this eliminates any > > future options as to the use of BSAs with RR, CGA > > or other techniques. My personal opinion on the > > use of the BSAs e.g. a la IPsec would be that they > > would be *additional* protection on top of RR, > > not a replacement. > > Even in the case of HA/MN? The HA really knows > the authorization status of the subnet the MN > is using, therefore possession of the key should > be sufficient test, right? Sorry for the confusion. I was talking about MN-CN security in the above. I believe IPsec SA would be sufficient for the HA-MN security. RR nor CGA would not be run MN-HA. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 22:37:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29560 for ; Wed, 13 Feb 2002 22:37:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27177; Wed, 13 Feb 2002 20:36:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17819; Wed, 13 Feb 2002 19:36:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3Z4Fh020505 for ; Wed, 13 Feb 2002 19:35:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Z4jP020502 for mobile-ip-dist; Wed, 13 Feb 2002 19:35:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YmFl020456 for ; Wed, 13 Feb 2002 19:34:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12280 for ; Wed, 13 Feb 2002 19:19:03 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07424 for ; Wed, 13 Feb 2002 20:19:01 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201300847.g0U8lVg37079@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 28 Jan 2002 18:45:09 +0100. Date: Wed, 30 Jan 2002 09:47:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 973 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: just one question : are there others cases (eg. protocols) where RH are used ? => two examples: - (theory) the selection of an intermediate ISP, i.e. to go from the West coast to the East coast you choose to go through Chicago, Saint-Louis, Memphis or New Orleans by a RH with the subnet anycast address of the selected ISP. - (practice) traceroute6 -g (there are two (not three :-) standard applications with IPv6 RH support: traceroute6 and telnet (in order to understand the syntax for telnet, you have to read (and sometimes to fix) the source. Regards Francis.Dupont@enst-bretagne.fr PS: the first usage is potentially critical (BTW is this kind of features mandatory in the USA since ISPs are regulated as telecom operators?) From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:01:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00111 for ; Wed, 13 Feb 2002 23:01:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24111; Wed, 13 Feb 2002 21:00:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16246; Wed, 13 Feb 2002 19:59:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIx020843 for ; Wed, 13 Feb 2002 19:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q4n1020111 for mobile-ip-dist; Wed, 13 Feb 2002 19:26:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGb019898 for ; Wed, 13 Feb 2002 19:25:06 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11788 for ; Wed, 13 Feb 2002 19:18:07 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28057 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: From: "Lajos Zaccomer (ETH)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Janos Miskolczi (ETH)" Subject: RE: [mobile-ip] HMIPv6 test Date: Wed, 9 Jan 2002 10:05:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 295 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi HMIP experts, Greg already summarized what happened at the event in question. I cannot add anything special. Some more details about the contact persons whom you can contact in case of any further questions: AT-CRC: Greg.Daley@eng.monash.edu.au Ericsson - ERA: Martti.Kuparinen@iki.fi Ericsson - R&D Hungary, Conformance Lab: Janos.Miskolczi@eth.ericsson.se, Lajos.Zaccomer@eth.ericsson.se Regards, Lajos Zaccomer -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Thursday, December 20, 2001 7:44 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6 test a quick question. Who are the contact persons for these implementations? Vijay "Hesham Soliman (ERA)" wrote: > > Hi all, > > Just a quick note to inform you that a small > interop test was held before IETF in which > HMIPv6 ver-4 was tested. > There were implementations from Ericsson, > Monash University, and test cases from > conformance lab in Ericsson. > > Regards, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:03:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00193 for ; Wed, 13 Feb 2002 23:03:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24917; Wed, 13 Feb 2002 21:02:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16603; Wed, 13 Feb 2002 20:01:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJH020843 for ; Wed, 13 Feb 2002 19:41:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q4fN020109 for mobile-ip-dist; Wed, 13 Feb 2002 19:26:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGd019898 for ; Wed, 13 Feb 2002 19:25:09 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11582 for ; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27897 for ; Wed, 13 Feb 2002 19:17:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C32E8C8.5000208@nomadiclab.com> Date: Wed, 02 Jan 2002 13:02:32 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko , Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] list of things for MIPv6 References: <200112241438.fBOEcWD04946@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 7 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, [I am catching old e-mail; the to/cc didn't include me so I didn't notice this before now.] Francis Dupont wrote: > Well, to me this seems to depend on how the CoAs are > assigned. If the MN is allowed to use stateless autoconfiguration, > it can generate a few thousand different CoAs for itself, > and use each CoA separately to send different home addresses > in the Home Address Option. > > => this behavior is so different than standard MN's one that > the ingress filtering should block it. How can ingress filtering notice that so that it could block it? That is, how can it differentiate between one host generating 200 different CoAs and using them and having 200 different hosts in the network? Of course this depends on the link layer, but given a suitable link layer (e.g. Ethernet), you cannot make the difference. (For Ethernet you need MAC spoofing, but that is easy.) --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:04:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00317 for ; Wed, 13 Feb 2002 23:04:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03939; Wed, 13 Feb 2002 21:03:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16825; Wed, 13 Feb 2002 20:02:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekI5020843 for ; Wed, 13 Feb 2002 19:41:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3J5Rr019750 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HxFh019560; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04629; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02352; Wed, 13 Feb 2002 19:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Date: Fri, 4 Jan 2002 17:57:13 +0200 (EET) From: Pekka Savola To: cc: Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO X-UID: 131 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, 4 Jan 2002, Francis Dupont wrote: > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). Feedback you get here does *not* reflect to the real world -- those who work around here, are usually even a little conscientious. The problem is the ignorant and the uncaring. FWIW, we provide connectivity for every university and the like in Finland, and they're all ingress-filtered at ISP-organization border. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:04:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00366 for ; Wed, 13 Feb 2002 23:04:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27155; Wed, 13 Feb 2002 20:04:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16935; Wed, 13 Feb 2002 20:03:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIp020843 for ; Wed, 13 Feb 2002 19:41:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JNGi019770 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IFFh019678 for ; Wed, 13 Feb 2002 19:18:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11668 for ; Wed, 13 Feb 2002 19:17:59 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13443 for ; Wed, 13 Feb 2002 20:17:58 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C385531.8050606@nomadiclab.com> Date: Sun, 06 Jan 2002 15:46:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A proposed MIPv6 security policy statement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 180 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, Based on my observation about the "future attack" against RR (see my previous message), may I suggest that we establish a recommended security policy statement for all IPv6 nodes that implement MIPv6 CN functionality. I'd like the present the following statement as a seed for discussion: A node MUST NOT establish a binding unless the BU has been properly protected. If the BU is protected only with return reachability (RR), the maximun lifetime of the binding SHOULD NOT exceed MAX_RR_BU_LIFETIME minutes. If the BU is protected with cryptographically generated addresses (CGA) or by stronger local means, e.g. by employing AAA or a local PKI, the maximum lifetime of the binding is a matter of local policy. If a binding has been created in a result of a BU protected only with RR tests, and the MN wants to renew or change the binding, the CN MUST check the return reachability of both the care-of-address and the home address. If, on the other hand, the binding has been created in a result of a BU protected with CGA or stronger means, the test checking the return routability of the _home_address_ MAY be skipped. The return routablity of the care-of-address MUST be performed in any case. Rationale: RR is computationally much cheaper than CGA, but it leaves open some threats that are not present in IPv4. However, there seems to be environments where the protection provided by RR is enough. On the other hand, to provide reasonable protection against the aforementioned threats, RR of _both_ the home address and care-of-address MUST be checked every time an RR based binding is renewed or changed. CGA, combined with initial RR, on the other hand, provides reasonable grounds to believe that the CN really "owns" the home address. Consequently, if CGA is used, it seems to be sufficient to check the RR of the CoA whenever a binding is renewed or changed. Note that checking the RR of the CoA may be easily mixed with the regular packet stream (and therefore e.g. does not cause problems to packet header compression) while checking the RR of the Home Address requires an extra exchange that falls outside the normal packet flow. I think that statement might serve us in desiging the MIPv6 security solution in such a way that it allows flexibility of mechanisms without opening too many vulnerabilities. A reasonable value for MAX_RR_BU_LIFETIME might be e.g. a few minutes. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:06:37 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00468 for ; Wed, 13 Feb 2002 23:06:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04938; Wed, 13 Feb 2002 21:06:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17165; Wed, 13 Feb 2002 20:05:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIh020843 for ; Wed, 13 Feb 2002 19:41:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dJQp020810 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcFv020453 for ; Wed, 13 Feb 2002 19:38:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04709 for ; Wed, 13 Feb 2002 19:18:19 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21928 for ; Wed, 13 Feb 2002 20:18:18 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C42EDE0.5D8720D4@iiic.ethz.ch> Date: Mon, 14 Jan 2002 15:40:32 +0100 From: Thomas Heinis X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IP address of new access router Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 468 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I have got some problems concerning the Mobile Determined Handover described in draft 3 for Fast Handovers for Mobile IPv6. The MN sends a Router Solicitation for Proxy message to the old access router containing the link local address of the new access router. After that, the old access router is supposed to send a Handover Initiation to the new access router. Wherefrom does the old access router know the IP address of the new access router(unless NAR is a neighbour of the OAR)? The OAR only has the link local address of NAR sent by MN in the Router Solicitation for Proxy. Furthermore I don't really see wherefrom OAR has the prefix information about NAR it should send back to the MN in the Proxy Router Advertisement? Please forgive me if this is the wrong mailing list or if these questions have already been discussed(I've had a look at the archives but didn't find anything). Regards Thomas From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:07:21 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00658 for ; Wed, 13 Feb 2002 23:07:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28005; Wed, 13 Feb 2002 20:07:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17227; Wed, 13 Feb 2002 20:05:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIj020843 for ; Wed, 13 Feb 2002 19:41:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JR00019774 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I5Fh019608 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11605 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02348 for ; Wed, 13 Feb 2002 19:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C192@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] list of things for MIPv6 Date: Thu, 3 Jan 2002 16:14:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 58 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, December 21, 2001 10:12 PM > To: Jari Arkko > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] list of things for MIPv6 > > > Jari Arkko wrote: > > > I believe there is a real difference in current spoofing > > attacks compared to the ones enabled by the home > > address option. Namely, ingress filtering or other techniques > > can prevent source address spoofing but I can't see how > > they could prevent HAO spoofing. > > Ingress filtering could put some restriction on this. > For instance, it could be enforced that only one home > address could be associated to a particular care-of address. > This would eliminate most of the "fun" that would be > associated with such spoofing. We could also say that > a correspondent node has to do such filtering. After > these two measures are taken, I think that no self-respecting > bad guy would waste time on such a low-payoff exploit. > Hello Charlie, > Supposing we had a new header type. Wouldn't it be > appropriate to make the necessary signaling for protecting > Binding Updates to also fit in the same container? => Absolutely. In fact it is as simple as taking the exact same ext header and giving it a new name/Header Type. I think the biggest amount of work will be done by IANA :) But I think Francis already said that. Regarding your response on RR and CGAs please see the separate thread containing my response to Erik and respond to that if you like. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:08:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00912 for ; Wed, 13 Feb 2002 23:08:42 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27871; Wed, 13 Feb 2002 21:08:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA10714; Wed, 13 Feb 2002 20:07:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJf020843 for ; Wed, 13 Feb 2002 19:41:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PlEX020092 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGD019898 for ; Wed, 13 Feb 2002 19:24:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11822 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21858 for ; Wed, 13 Feb 2002 20:18:08 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f X-Delivered-For: X-mProtect: Wed, 9 Jan 2002 10:39:20 -0800 Nokia Silicon Valley Messaging Protection Message-ID: <3C3C8DA1.9070309@iprg.nokia.com> Date: Wed, 09 Jan 2002 10:36:17 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] bitstring for calculating Authentication Data References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 327 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it was a slip. In my implementation, I include the reserved field in the Binding Acknowledgement. Vijay Lajos Zaccomer (ETH) wrote: > Hi all, > > Can anyone tell me, why does not the bitstring for calculating Authentication Data of a BA contain the reserved field? > In case of BU, all the reserved octets are included. Including that mysterious octet in the bitstring would simplify calculation. Otherwise, the reserved field of BU should be removed either. > > Zacco > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:08:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00941 for ; Wed, 13 Feb 2002 23:08:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27331; Wed, 13 Feb 2002 21:08:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17414; Wed, 13 Feb 2002 20:07:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJn020843 for ; Wed, 13 Feb 2002 19:41:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JDMP019755 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HoFh019488 for ; Wed, 13 Feb 2002 19:17:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04621 for ; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14558 for ; Wed, 13 Feb 2002 20:17:51 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Thu, 03 Jan 2002 09:32:27 +1100 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6 test To: mobile-ip@sunroof.eng.sun.com Cc: Lajos.Zaccomer@eth.ericsson.se, akos.cserveni@eth.ericsson.se Message-id: <3C338A7B.3DE9647F@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=iso-8859-1 X-Accept-Language: en References: <4DA6EA82906FD511BE2F00508BCF053801C4C17B@Esealnt861.al.sw.ericsson.se> <003b01c18a79$cf157390$df0589c1@loliveira> List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id PAA28610 Status: RO X-UID: 43 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1E3HpFh019498 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Luís Miguel Oliveira wrote: > > Hi, > > Anyone have some details about this tests? Hi Luis, I've just returned from christmas/summer break so I do not have any breakdowns of the testing. I'll try to define the areas, and maybe Lajos or Akos can flesh out details. the testing was divided into Interop and Conformance testing. Conformance testing was performed with the Ericsson Hungary testing suite, which has a lot of control over test cases. Primarily the testing was aimed at HMIPv6-draft4, but some reliances on the underlying MIPV6 stack were tested. Mobile node and MAP roles were tested for conformance to the basic mode of operation. As far as I know, neither implementation has Extended Mode to a testable state. As far as I can tell, tests for all the MUSTs in the draft (which apply to basic mode) have been provided as well as some common sense cases (which were not all passed... :) Interop testing was conducted between the Ericsson and the AT-CRC implementations, and work focussed on working the Ericsson MAP implementation with the Mobile node from AT-CRC. Some initial assumptions on the AT-CRC implementation had been revealed by the conformance testing, which previously had been confusing in the first attempt of interop testing. After correcting these, mobile node registrations were performed with map and a MIPv6-14 ha, and data was received from a MIPv6-14 correspondent node. Intra mobility domain movement was performed, and instrumented. Some of the test results are still to be analysed by our team because of the christmas holiday interruption. Greg From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:08:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01011 for ; Wed, 13 Feb 2002 23:08:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06157; Wed, 13 Feb 2002 21:08:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA10743; Wed, 13 Feb 2002 20:07:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJD020843 for ; Wed, 13 Feb 2002 19:41:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Vfia020423 for mobile-ip-dist; Wed, 13 Feb 2002 19:31:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Gd020208 for ; Wed, 13 Feb 2002 19:30:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16782 for ; Wed, 13 Feb 2002 19:19:13 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14001 for ; Wed, 13 Feb 2002 20:19:12 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Wed, 30 Jan 2002 14:03:45 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 985 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I did not mean that the nested Mobile Networks would necessarily lead us to > several RHs one after the other. I meant we want a single RH with as many > segments as nested networks, for the CoAs of the Mobile Routers and the CoA > of the final CN if any. > > Say that all the intermediate MRs exchange BUs with the CN, for example > using T. Ernst's proposal (draft-ernst-mobileip-v6-network). The CN could > recursively realizes that the Mobile Networks are nested, and builds a RH > accordingly. I do not necessarily favour that idea because of the burden on > the CN, the BU traffic involved, and the time to converge, but at least it's > possible. What do you think? We're deep in Monet land at the moment but I'll respond in any case. For the case when the whole path is route optimized you are right that the CN could construct a RH listing all the CoAs. But when only part of the path is optimized e.g. the CN knows what train the MN is in (the HoA of the MR) but it doesn't know the current location of the train (the CoA of the MR) then the CN can only construct something that goes to the HoA of the MR and the MR's HA will need to nest by including something which carries the CoA of the MR. If RH is used for all of this it seems like there might be multiple RH headers - but perhaps RH can't be used in this way because of path MTU issues and instead encapsulation must be used from the HA(MR) to the MR. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:09:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01113 for ; Wed, 13 Feb 2002 23:09:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28126; Wed, 13 Feb 2002 21:09:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17356; Wed, 13 Feb 2002 20:06:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJX020843 for ; Wed, 13 Feb 2002 19:41:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VQrB020412 for mobile-ip-dist; Wed, 13 Feb 2002 19:31:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5G1020208 for ; Wed, 13 Feb 2002 19:30:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16696 for ; Wed, 13 Feb 2002 19:18:50 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07367 for ; Wed, 13 Feb 2002 20:18:48 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15436.28017.39358.549788@thomasm-u1.cisco.com> Date: Mon, 21 Jan 2002 11:35:13 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <3C4C6A72.C11B6288@cisco.com> References: <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> <3C4C6A72.C11B6288@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 827 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alpesh Patel writes: [] Yet another oops. Can we *please* change this to not be reply-to: mobile-ip? Who is the list owner??? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:09:23 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01155 for ; Wed, 13 Feb 2002 23:09:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28173; Wed, 13 Feb 2002 21:09:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17437; Wed, 13 Feb 2002 20:07:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJ7020843 for ; Wed, 13 Feb 2002 19:41:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3e5A3020834 for mobile-ip-dist; Wed, 13 Feb 2002 19:40:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGd020453 for ; Wed, 13 Feb 2002 19:38:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04717 for ; Wed, 13 Feb 2002 19:18:20 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21929 for ; Wed, 13 Feb 2002 20:18:19 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <0DCC27458EB5D51181840002A507069EE30D88@orsmsx117.jf.intel.com> From: "Iyer, Prakash" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 07:13:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 470 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Was the consensus based on the number of companies. If so, as far as I remember there were only 2 or 3 companies driving NAT requirements and at least as many (if not more) interested in solving the VPN problem. I remember both George and James Kempf raising this issue for discussion and a couple of other vendors noting their interest on the [mobileip-nat-vpn] mailing list. As I had mentioned earlier there were requests on the IPSRA mailing list as well. Maybe the chairs can clarify the basis for this conclusion for the benefit of the working group. Thanks. -Prakash -----Original Message----- From: Phil Roberts [mailto:PRoberts@megisto.com] Sent: Monday, January 14, 2002 6:42 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Based on the feedback we'll be making draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt a working group item and waiting on the interoperation with VPN gateways until there is a larger constituency of interest in the WG. > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:09:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01337 for ; Wed, 13 Feb 2002 23:09:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28364; Wed, 13 Feb 2002 21:09:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17424; Wed, 13 Feb 2002 20:07:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIv020843 for ; Wed, 13 Feb 2002 19:41:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JnXN019790 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IEFh019674 for ; Wed, 13 Feb 2002 19:18:15 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12308 for ; Wed, 13 Feb 2002 19:17:59 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27953 for ; Wed, 13 Feb 2002 19:17:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Fri, 4 Jan 2002 16:17:45 -0800 (PST) From: Joe Lau Message-Id: <200201050017.QAA22017@strtio1.cup.hp.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD370@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 162 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. Yes. I should include Mobile IPv4 interoperation with VPN gateways as a WG item as well. Joe Lau From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:09:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01349 for ; Wed, 13 Feb 2002 23:09:50 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06694; Wed, 13 Feb 2002 21:09:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17489; Wed, 13 Feb 2002 20:07:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekId020843 for ; Wed, 13 Feb 2002 19:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dbuL020814 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcG9020453 for ; Wed, 13 Feb 2002 19:38:32 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04813 for ; Wed, 13 Feb 2002 19:18:36 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14929 for ; Wed, 13 Feb 2002 20:18:35 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIP v6 next steps Date: Thu, 17 Jan 2002 14:09:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 685 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, we've formed a small design team to close the open issues based on WG consensus for MIPv6. It consists of Jari Arkko, Gabriel Montenegro, and Erik Nordmark. The chairs and area advisor are monitoring what's going on there. The following open issues need to be closed based on WG consensus: 1) what strength of protection to use for BUs and the protocol mechanisms to make that happen, 2) how to protect against certain forms of attacks using routing headers, 3) how to protect against certain forms of attacks using the home address option, and 4)what to do about piggybacking. In the next couple of weeks threads will be started listing the possible options, there will be time for discussion, and the chairs will make working group consensus calls. The protection of BU description will probably be a new Internet Draft which will later be incorporated into the MIPv6 specification. We expect the description of the BU draft to be out by Feb 8, and to incorporate it and discussion items based on it in time to have a WG last call complete by the Friday of the Minneapolis meeting. Phil and Raj From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:09:52 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01361 for ; Wed, 13 Feb 2002 23:09:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28906; Wed, 13 Feb 2002 20:09:40 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17539; Wed, 13 Feb 2002 20:08:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJ5020843 for ; Wed, 13 Feb 2002 19:41:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JKCD019763 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HpFh019493 for ; Wed, 13 Feb 2002 19:17:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11573 for ; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21742 for ; Wed, 13 Feb 2002 20:17:51 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <933FADF5E673D411B8A30002A5608A0E014CC504@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Thu, 3 Jan 2002 11:24:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1947B.8B9DAFE0" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 73 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1947B.8B9DAFE0 Content-Type: text/plain; charset="iso-8859-1" Jari, There was a long offline argument about how a router would definitely know that it was the first hop router. I.e. how would it know to turn on the checks or not without configuration. The point was brought up about assymetric routing where outbound traffic goes through a set of egress routers and inbound comes in on ingress routers. The point was made that the outbound routers would likely not have a FIB flag set in cache indicating that node was a first hop. So it seems that in order to turn on some kind of check on the 1st hop automatically, we would need to find some other standardized means of turning the checks on. I think that if MAC anti-spoofing was mandated then the solution to mandate the filtering would be mute; however, the problem set is essentially the same in that you would still have to find a way to have the router detect automatigically that the anti-spoofing checks were needed - sort of a zeroconf solution. We could have the routers monitor the autoconfiguration messages and perhaps the DHCP messages or we could rely on an all routers multicast message to handle the situation with assymetric routes. This would be automagic yet I still suspect someone will complain about subnet bandwidth being used up with a new message, etc.. Even if such a thing were agreed we will get into the arguments about core routers also having hosts attached to them. Someone will likely take the stance that I don't want these core routers being bogged down; however, configuration via either subneting or simple configurable overrides would likely quell these arguments as well. This would certainly change the thinking from one of you have to configure the router to enable the filtering to that of you have to configure the router to disable the filtering. Anyway these were my thoughts about this. Thanks for bringing it up. I am hopeful that something could be done and agreed on this matter with IPv6 and perhaps even IPv4 for newer implementations or releases. Most of the core routers are configured in some fashion anyway. Thanks, Glenn > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, December 26, 2001 1:39 PM > To: Francis Dupont; ipng@sunroof.eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: IPv6 ingress filtering early access > > > > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-i > ngress-filtering-00.txt > > Nice draft, thanks for taking the time to write down the problems and > their alternative solutions. Hope you still had time for Christmas ;-) > > I have a few comments. > > First, it seems that the main alternatives we have is (a) > restrict MIPv6 > functionality by removing intermediate alternatives between > bidirectional > tunneling and route optimisation, or (b) deploy AAA to help > visited networks > figure out what are legal home addresses. > > It is interesting to note the different actors in these two > alternatives. In the > first alternative, it is the CN who is taking the > responsibility, and requiring > no help whatsoever from the firewalls in between. In the > second alternative, > we put all the trust on the firewalls/routers of sites, and > none of the CNs do > any worrying over this anymore. Both solutions work if > applied allover, and > the second solution allows the current MIPv6 flexibility, > being therefore the > preferred solution if seen feasible. > > However, I'm concerned about the "applied allover" part. > Specifically - while > I'm very much fond of the AAA solutions - I'm concerned > whether we can expect > all parts of the Internet to have an infrastructure that > really can figure out the > home addresses. What if there's a coin-operated (or Visa-) > airport WLAN? > With no connection to a global roaming association of who > owns what addresses. > What kind of filtering should that do? Prohibit everything > else expect bidirectional > tunneling, or allow home addresses to be used? If latter, > then the trusting > CNs don't have a clue that they could be used as reflectors... > > Finally, I seem to remember there was a discussion a long > time ago whether > we could somehow provide automatic, mandatory, ingress > filtering in IPv6. > If such a feature were possible, it would really make setting > up networks easier > and denial of service attacks easier to trace. Do you think > this would be > feasible? If yes, perhaps it should also be discussed in the > draft. Currently, > we are headed towards the same situation as in IPv4 where > ingress filtering > is only partially applied, and we keep coming up with "patch" > solutions such > as I-trace to help the situation. Interestingly, these > solutions typically need > changes to a large fraction of the routers in the Internet > which we already are > doing anyway to move to IPv6... > > Jari > > > > ------_=_NextPart_001_01C1947B.8B9DAFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: IPv6 ingress filtering early access

Jari,

There was a long offline argument about how a router = would definitely know that it was the first hop router. I.e. how would = it know to turn on the checks or not without configuration. The point = was brought up about assymetric routing where outbound traffic goes = through a set of egress routers and inbound comes in on  ingress = routers. The point was made that the outbound routers would likely not = have a FIB flag set in cache indicating that node was a first hop. =

So it seems that in order to turn on some kind of = check on the 1st hop automatically, we would need to find some other = standardized means of turning the checks on. I think that if MAC = anti-spoofing was mandated then the solution to mandate the filtering = would be mute; however, the problem set is essentially the same in that = you would still have to find a way to have the router detect = automatigically that the anti-spoofing checks were needed - sort of a = zeroconf solution.

We could have the routers monitor the = autoconfiguration messages and perhaps the DHCP messages or we could = rely on an all routers multicast message to handle the situation with = assymetric routes. This would be automagic yet I still suspect someone = will complain about subnet bandwidth being used up with a new message, = etc.. Even if such a thing were agreed we will get into the arguments = about core routers also having hosts attached to them. Someone will = likely take the stance that I don't want these core routers being = bogged down; however, configuration via either subneting or simple = configurable overrides would likely quell these arguments as well. =

This would certainly change the thinking from one of = you have to configure the router to enable the filtering to that of you = have to configure the router to disable the filtering.

Anyway these were my thoughts about this. Thanks for = bringing it up. I am hopeful that something could be done and agreed on = this matter with IPv6 and perhaps even IPv4 for newer implementations = or releases. Most of the core routers are configured in some fashion = anyway.

Thanks,

Glenn

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
> Sent: Wednesday, December 26, 2001 1:39 = PM
> To: Francis Dupont; = ipng@sunroof.eng.sun.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] Re: IPv6 ingress filtering = early access
>
>
> >
> ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupon= t-ipv6-i
> ngress-filtering-00.txt
>
> Nice draft, thanks for taking the time to write = down the problems and
> their alternative solutions. Hope you still had = time for Christmas ;-)
>
> I have a few comments.
>
> First, it seems that the main alternatives we = have is (a)
> restrict MIPv6
> functionality by removing intermediate = alternatives between
> bidirectional
> tunneling and route optimisation, or (b) deploy = AAA to help
> visited networks
> figure out what are legal home addresses. =
>
> It is interesting to note the different actors = in these two
> alternatives. In the
> first alternative, it is the CN who is taking = the
> responsibility, and requiring
> no help whatsoever from the firewalls in = between. In the
> second alternative,
> we put all the trust on the firewalls/routers = of sites, and
> none of the CNs do
> any worrying over this anymore. Both solutions = work if
> applied allover, and
> the second solution allows the current MIPv6 = flexibility,
> being therefore the
> preferred solution if seen feasible.
>
> However, I'm concerned about the "applied = allover" part.
> Specifically - while
> I'm very much fond of the AAA solutions - I'm = concerned
> whether we can expect
> all parts of the Internet to have an = infrastructure that
> really can figure out the
> home addresses. What if there's a coin-operated = (or Visa-)
> airport WLAN?
> With no connection to a global roaming = association of who
> owns what addresses.
> What kind of filtering should that do? Prohibit = everything
> else expect bidirectional
> tunneling, or allow home addresses to be used? = If latter,
> then the trusting
> CNs don't have a clue that they could be used = as reflectors...
>
> Finally, I seem to remember there was a = discussion a long
> time ago whether
> we could somehow provide automatic, mandatory, = ingress
> filtering in IPv6.
> If such a feature were possible, it would = really make setting
> up networks easier
> and denial of service attacks easier to trace. = Do you think
> this would be
> feasible? If yes, perhaps it should also be = discussed in the
> draft. Currently,
> we are headed towards the same situation as in = IPv4 where
> ingress filtering
> is only partially applied, and we keep coming = up with "patch"
> solutions such
> as I-trace to help the situation. = Interestingly, these
> solutions typically need
> changes to a large fraction of the routers in = the Internet
> which we already are
> doing anyway to move to IPv6...
>
> Jari
>
>
>
>

------_=_NextPart_001_01C1947B.8B9DAFE0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01419 for ; Wed, 13 Feb 2002 23:10:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06876; Wed, 13 Feb 2002 21:09:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17495; Wed, 13 Feb 2002 20:08:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJR020843 for ; Wed, 13 Feb 2002 19:41:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PSZ6020083 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFj019898 for ; Wed, 13 Feb 2002 19:24:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12306; Wed, 13 Feb 2002 19:19:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15113; Wed, 13 Feb 2002 20:19:03 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Thu, 24 Jan 2002 18:00:04 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 To: Alexandru Petrescu Cc: "Hesham Soliman (ERA)" , "Jari Arkko (LMF)" , "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 967 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > "The attack is certainly feasible without compromising a router"? As > I said earlier, attacker must not only generate fake RR messaging to > CN but it must also block true RR messages from CN to reach true HA. The "block" aspects may or may not be needed. For instance, in BU3WAY it is not needed; a MN receiving a BUC that has not sent a BUR will silently ignore the BUC. I think this is necessary to avoid DoS issues where an attacker sends spoofed BUC messages, potentially with a spoofed source address, in order to use create state on the MN. But I haven't thought about this in detail - but the point is that it might not be as trivial as it looks at first sight. But I'm not convinced the difference matters. Somebody that is on-path, whether connected to a multi-access link using ARP/ND or physically in a router or switch, is capable of sending and receiving packets as well as blocking packets from being forwarded. A possible case when this would not be the case is when the attacker has a passive leak/bleed (of the copper or optical wire) for receive and uses a completely different interface to transmit packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:15 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01431 for ; Wed, 13 Feb 2002 23:10:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA28961; Wed, 13 Feb 2002 20:09:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17445; Wed, 13 Feb 2002 20:07:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIV020843 for ; Wed, 13 Feb 2002 19:41:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JtkV019804 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HqFh019495; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12180; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13356; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-ID: <3C342515.10904@nomadiclab.com> Date: Thu, 03 Jan 2002 11:32:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO X-UID: 51 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:25 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01465 for ; Wed, 13 Feb 2002 23:10:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28000; Wed, 13 Feb 2002 21:09:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17540; Wed, 13 Feb 2002 20:08:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJr020843 for ; Wed, 13 Feb 2002 19:42:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PSKD020080 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFh019898 for ; Wed, 13 Feb 2002 19:24:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12296; Wed, 13 Feb 2002 19:19:03 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15106; Wed, 13 Feb 2002 20:19:02 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A949@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alexandru Petrescu'" , "Hesham Soliman (ERA)" Cc: "Jari Arkko (LMF)" , "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Thu, 24 Jan 2002 17:58:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => The attack is certainly feasible without compromising > > a router. In the 'Is RR only enough' thread, Erik > > also explained that it was feasible today. The difference > > was that you could (if you look at ARP caches) see it > > today. Whereas you wouldn't be able to see it with an > > attack on RR. Not a significant difference IMO. > > "The attack is certainly feasible without compromising a > router"? Status: RO X-UID: 958 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: => Yes. But please note, this is applicable to the cases where the HA does not participate in RR. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01506 for ; Wed, 13 Feb 2002 23:10:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07155; Wed, 13 Feb 2002 21:10:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17572; Wed, 13 Feb 2002 20:08:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJB020843 for ; Wed, 13 Feb 2002 19:41:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JnSH019796 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IHFh019684 for ; Wed, 13 Feb 2002 19:18:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16108; Wed, 13 Feb 2002 19:18:01 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21807; Wed, 13 Feb 2002 20:18:00 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Fri, 4 Jan 2002 04:04:14 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Is RR only enough ? To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "Hesham Soliman (ERA)" In-Reply-To: "Your message with ID" <15412.51261.418122.958215@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 112 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I thought we agreed that an man in the middle > which would need to be part of the network > (switch/router) was something we could ignore. As > in, if that happens, BU hijacking is just one of a > nearly infinite number of attacks you could mount > -- most of which have nothing to do with MIP. > > Now, if you can show an attack by an end host in > the CN's, MN's or anybody else's network which can > be mounted without requiring a compromised > router/switch I'll be the first one to change my > mind on this. One condition here though: if the > access router/switch can defeat the attack, and > it's localized to an attack on its networks (eg > another CN on the same network segment), it's not > unreasonable to expect that that be part of the > entire RR solution, IMO. Mike, An attacker (e.g. a host) on a multi-access link next to the CN, HA, or MN can lauch successful attacks against RR in general. (BU3WAY shows a scheme for preventing attacks on the link attached to the MN and the rest of the path between the MN and HA.) This does require that the multi-access link allows anybody to receive packets (e.g. non-switched Ethernets or 802.11) or using ND/ARP spoofing to become a MiTM on those links. But this isn't any worse than IPv4 today either - any host attached e.g. to a non-switched Ethernet next either of two communicating nodes can use ARP spoofing and/or snooping packets to become a MiTM for TCP connections and UDP "sessions". Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01518 for ; Wed, 13 Feb 2002 23:10:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29106; Wed, 13 Feb 2002 20:10:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17541; Wed, 13 Feb 2002 20:08:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJL020843 for ; Wed, 13 Feb 2002 19:41:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q1Vm020105 for mobile-ip-dist; Wed, 13 Feb 2002 19:26:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGB019898 for ; Wed, 13 Feb 2002 19:24:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12278 for ; Wed, 13 Feb 2002 19:19:02 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15094 for ; Wed, 13 Feb 2002 20:19:01 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 References: <4DA6EA82906FD511BE2F00508BCF053802C6A973@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 29 Jan 2002 22:04:15 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A973@Esealnt861.al.sw.ericsson.se> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 14 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 976 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "Hesham Soliman (ERA)" writes: > or by core network routing according to keys (in addresses). > > => Routing in the core network is never done > on the interface id anyway. Thanks Hesham for bringing this up. I'm wondering if the 64bit boundary for Interface ID is fixed. It seems to me that 000-prefixed addresses are about to be reserved exactly in order to allow prefix lengths longer than 64 (draft-ietf-ipngwg-addr-arch). I might be wrong, though. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:44 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01536 for ; Wed, 13 Feb 2002 23:10:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29176; Wed, 13 Feb 2002 20:10:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17577; Wed, 13 Feb 2002 20:08:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIb020843 for ; Wed, 13 Feb 2002 19:41:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3V9Wx020404 for mobile-ip-dist; Wed, 13 Feb 2002 19:31:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5G3020208 for ; Wed, 13 Feb 2002 19:30:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16473 for ; Wed, 13 Feb 2002 19:18:35 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14787 for ; Wed, 13 Feb 2002 20:18:22 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: Brian Haley USG Message-Id: <200201141942.AA04846@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com Subject: [mobile-ip] Changes to RA interval Date: Mon, 14 Jan 2002 14:42:02 -0500 X-Mts: smtp List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 512 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In draft 15 the minimum frequency of Router Advertisements was dropped to .05 seconds from .5 seconds, which a number of us already noticed. But I just realized that the maximum was never decreased from 1.5 seconds, so if I choose a random number between min and max, as RFC 2461 recommends, it will average out near the high end of the scale. Shouldn't the max be reduced to .15 seconds, which after looking at RFC 2461, falls into the "default" range of (min = .33 * max) ? I believe the reason behind the change was to help with movement detection, but it doesn't currently do that much better than draft 13. -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:10:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01535 for ; Wed, 13 Feb 2002 23:10:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28845; Wed, 13 Feb 2002 21:10:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17640; Wed, 13 Feb 2002 20:09:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJt020843 for ; Wed, 13 Feb 2002 19:42:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dWnQ020812 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcG7020453 for ; Wed, 13 Feb 2002 19:38:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04666 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02447 for ; Wed, 13 Feb 2002 19:18:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201090852.g098qsQ24582@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Charlie Perkins Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Thu, 03 Jan 2002 15:17:54 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C18D@Esealnt861.al.sw.ericsson.se> Date: Wed, 09 Jan 2002 09:52:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 294 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => you should recognize piggy-backing is less useful on an Ethernet > or a 802.11b/802.11a. I consider piggy-backing as an > over-optimization > (as RSVP in fact) in most cases, i.e. this really makes sense with > some link-layers which are very hard (i.e. too expensive) to improve > (this is the case of mobile phone in Europe, nobody wants to buy > a second license in some countries just to get more bandwidth :-). => It actually does NOT make any sense for the expensive, hard ..etc link layers. => my text is not clear enough, the "i.e. this really makes sense..." is more about RSVP than piggy-backing (you know I don't like piggy-backing at all). Regards Francis.Dupont@enst-bretagne.fr PS: > So the question is, where does this optimisation make sense ? => obviously not end-to-end (piggy-backing is end-to-end, so any link-layer argument in favor of it is weak). From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:11:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01580 for ; Wed, 13 Feb 2002 23:11:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29157; Wed, 13 Feb 2002 21:10:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17601; Wed, 13 Feb 2002 20:08:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIX020843 for ; Wed, 13 Feb 2002 19:41:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JJPR019764 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3IBFh019655 for ; Wed, 13 Feb 2002 19:18:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12268 for ; Wed, 13 Feb 2002 19:17:57 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14606 for ; Wed, 13 Feb 2002 20:17:56 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: Brian Haley USG Message-Id: <200201042102.AA17211@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] salt lake city draft meeting minutes Date: Fri, 04 Jan 2002 16:02:20 -0500 X-Mts: smtp List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 152 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -------------WG run out of time----------- > > 6. MIPv6 at ETSI Bakeoff Report 10 Mins Sebastien Barbin I was wondering if Sebastien could send this report to the mailing list. I know of a couple of issues that came up there, but maybe there were more? Thanks, -Brian P.S Why does this working group never get through it's agenda? I've attended the last 5 IETFs and don't think it's happened yet. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:11:19 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01602 for ; Wed, 13 Feb 2002 23:11:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28541; Wed, 13 Feb 2002 21:11:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17762; Wed, 13 Feb 2002 20:10:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJd020843 for ; Wed, 13 Feb 2002 19:41:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JWIP019777 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HxFh019570 for ; Wed, 13 Feb 2002 19:18:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11619 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13388 for ; Wed, 13 Feb 2002 20:17:54 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201041622.g04GMKQ03361@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 27 Dec 2001 14:52:32 +0200. <200112271252.OAA20990@burp.tkv.asdf.org> Date: Fri, 04 Jan 2002 17:22:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 129 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I may have missed some discussion due to high volume on this topic, but I like to inject one scenario of Home Address option use... If MN and CN have IPSEC session between them, then I suppose HAO within such session is safe. => this depends on what is an IPsec session (AH makes HAO safe, more details are needed for other cases). (I leave it open for now, whether the session should be between care of addresses or home addresses of MN and CN, but either should work?). => if the IPsec SA is with a care-of address it has to be rebuilt after each movement. But the ISAKMP SA can be with the care-of or the home address (i.e. IKE session can use the care-of or the home address) at the exception of the IKE session for a first home registration (i.e. before the home agent - mobile node tunnel is established, mobile IPv6 drafts have a MUST because of this case). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:11:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01615 for ; Wed, 13 Feb 2002 23:11:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA07720; Wed, 13 Feb 2002 21:11:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11003; Wed, 13 Feb 2002 20:10:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJj020843 for ; Wed, 13 Feb 2002 19:41:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dxek020825 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGZ020453 for ; Wed, 13 Feb 2002 19:38:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05102 for ; Wed, 13 Feb 2002 19:19:07 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13970 for ; Wed, 13 Feb 2002 20:19:06 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f To: Pekka Nikander Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> <3C4FC833.7020108@nomadiclab.com> From: Alexandru Petrescu Date: 24 Jan 2002 17:20:40 +0100 In-Reply-To: <3C4FC833.7020108@nomadiclab.com> Message-Id: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 956 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Pekka, Pekka Nikander writes: > You physically go to your target network (or tap to a link in > between), plug in your laptop, pretend to be your own HA, establish > a binding at the CN, go away, and later let the binding to expire. > If you have active communications going on when the binding expires > (e.g. a large file transfer), the packets start bombing to your > target, and you can even keep the TCP transfer to go on for some > time by carefully sending false ACKs. This looks indeed like a feasible attack. However this is hardly feasible if CN is required to drop bindings when receiving two differing BKE's (sorry I use BAKE terminology only because it's easier for me to put names on messages). One more thing, what is the fear of the above attack? That the target network gets bombed or that it's difficult to identify who provoked it? In the first case, you can always bomb something, no feasible defense at protocol level. Add new messages to secure something and then the new entities can be bombed. In the second case, err, I don't know, probably this kind of impersonation is a fact of life today, with faked source addresses in ICMP echo requests. I guess people find the true identities by verbal coordination, looking at log messages, etc. Please do not get me wrong, I'm not saying there's no need of protection in Mobile IPv6, just trying to identify what is genuinely new security flaw introduced by it. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:11:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01628 for ; Wed, 13 Feb 2002 23:11:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28793; Wed, 13 Feb 2002 21:11:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25969; Wed, 13 Feb 2002 20:11:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJV020843 for ; Wed, 13 Feb 2002 19:41:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Psbh020100 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGN019898 for ; Wed, 13 Feb 2002 19:24:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11800 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07035 for ; Wed, 13 Feb 2002 20:18:06 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201091127.g09BRKQ25043@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 12:54:01 CST. <933FADF5E673D411B8A30002A5608A0E01590CB4@zrc2c012.us.nortel.com> Date: Wed, 09 Jan 2002 12:27:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 302 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This sounds like a pretty good idea to me to remove the need for tunneling overhead. => I agree but you can also remove the routing header too, i.e. the tunneling overhead in the other way. This is named micro-mobility or mobility based on host routing, and is almost as applicable as Michael's proposal (i.e. it has exactly the same scalability issue, all involved ingress filtering devices must be configured, for micro mobility this is for all involved routers). Regards Francis.Dupont@enst-bretagne.fr PS: Michael's proposal is like a combination of path MTU discovery (ingress filter devices send back ICMP errors when they drop packets) and signaling (in order to punch holes in ingress filters). From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:11:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01647 for ; Wed, 13 Feb 2002 23:11:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28985; Wed, 13 Feb 2002 21:11:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17751; Wed, 13 Feb 2002 20:09:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJN020843 for ; Wed, 13 Feb 2002 19:41:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Jm3g019792 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I7Fh019631 for ; Wed, 13 Feb 2002 19:18:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11610 for ; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13381 for ; Wed, 13 Feb 2002 20:17:54 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C3438BF.5010304@nomadiclab.com> Date: Thu, 03 Jan 2002 12:55:59 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: msa@burp.tkv.asdf.org Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200112271252.OAA20990@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 53 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Markku Savela wrote: > I may have missed some discussion due to high volume on this topic, > but I like to inject one scenario of Home Address option use... > > If MN and CN have IPSEC session between them, then I > suppose HAO within such session is safe. (I leave it open for now, > whether the session should be between care of addresses or home > addresses of MN and CN, but either should work?). Well, that depends on _how_ exactly you have created the IPSEC session, and, as a consequence, how much you trust the MN. If you use something like opportunistic IPSEC (see http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic-04-change.txt) you certainly CANNOT trust the HAO any more than without IPSEC. On the other hand, if you have a closed user group with strong internal trust relationships, you may decide to trust the HAO without any explicit authorization. However, in the general case, when you create the IPSEC SA, you have to check that the MN is _authorized_ to use the Home Address. Only that makes it secure to trust on the HAO. As a side note, the CGA and RR methods are means to check an MN's authority to use a Home Address. Basically, RR relies on the assumption that if a host can answer to messages sent to an address, it is authorized to use that address. CGA, on the other hand, relies on that if a host possesses a private key that corresponds to the host ID part of an IPv6 address, it is assumed to be authorized to use that address. Neither is perfectly secure, but both are much better than nothing. (Well, what do I mean with "much better". In the RR case, much better means that the number of hosts able to foil the RR check is much smaller than the number of hosts in the Internet. In the CGA case, creating a private key that corresponds to a given IPv6 interface ID requires so large amounts of computational capasity that few attackers are likely willing to spend that much of resources.) --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:11:56 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01663 for ; Wed, 13 Feb 2002 23:11:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08177; Wed, 13 Feb 2002 21:11:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17858; Wed, 13 Feb 2002 20:10:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJ3020843 for ; Wed, 13 Feb 2002 19:41:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dluJ020818 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGR020453 for ; Wed, 13 Feb 2002 19:38:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05096 for ; Wed, 13 Feb 2002 19:19:04 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07435 for ; Wed, 13 Feb 2002 20:19:03 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Wed, 30 Jan 2002 11:35:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routes beyond /64 (Was: A threat RR doesn't solve ...) To: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 978 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > "Hesham Soliman (ERA)" writes: > > or by core network routing according to keys (in addresses). > > > > => Routing in the core network is never done > > on the interface id anyway. > > Thanks Hesham for bringing this up. > > I'm wondering if the 64bit boundary for Interface ID is fixed. It > seems to me that 000-prefixed addresses are about to be reserved > exactly in order to allow prefix lengths longer than 64 > (draft-ietf-ipngwg-addr-arch). I might be wrong, though. I think practical use of address in 0::/8 (such as the ipv4-mapped, ipv4-compatible, ipv4-translatable, loopback, unspecified) are not likely to cause routes to be advertised in the network for longer than a /96 (and that would be for the ipv4-mapped prefix when using a SIIT translator). So implementors *could* get away with /64 in many places - but DOOOOONT!!! While today /64 is used to do stateless address autoconfiguration it would be short-sighted to assume that this will always be the case. Twenty or fourty years from now we might need something different. Thus IMHO a prudent implementation would limit the places where the /64 boundary is known to a minimum. The best would be to only have this be known by the device driver for IP-over-foo. For instance, an Ethernet device driver would need to know that it should create a 64 bit Interface ID from the MAC address. Then it could pass this up to whatever entity implements RFC 2462 but that entity only needs to verify that the prefixes advertised by the routers plus the interface ID makes a total of 128 bits. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:12:00 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01680 for ; Wed, 13 Feb 2002 23:11:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29632; Wed, 13 Feb 2002 21:11:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17763; Wed, 13 Feb 2002 20:10:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIr020843 for ; Wed, 13 Feb 2002 19:41:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3dfCG020816 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGL020453 for ; Wed, 13 Feb 2002 19:38:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04713 for ; Wed, 13 Feb 2002 19:18:19 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13610 for ; Wed, 13 Feb 2002 20:18:19 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 09:41:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 469 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Based on the feedback we'll be making draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt a working group item and waiting on the interoperation with VPN gateways until there is a larger constituency of interest in the WG. > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:12:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01693 for ; Wed, 13 Feb 2002 23:12:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29720; Wed, 13 Feb 2002 21:11:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17808; Wed, 13 Feb 2002 20:10:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJZ020843 for ; Wed, 13 Feb 2002 19:41:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PoGO020096 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGH019898 for ; Wed, 13 Feb 2002 19:24:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11876 for ; Wed, 13 Feb 2002 19:18:20 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14767 for ; Wed, 13 Feb 2002 20:18:19 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs Date: Mon, 14 Jan 2002 11:46:30 -0500 Message-ID: Thread-Topic: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs Thread-Index: AcGdGn/NGH0eVdp3Sg6TktHEN4e0qwACSxGg From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0EGkY2Q029231 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 476 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit One more -----Original Message----- From: Alexis Olivereau [mailto:Alexis_Olivereau-AAO011@email.mot.com] Sent: Monday, January 14, 2002 10:40 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs I am interested in that topic, too. Phil Roberts wrote: > If you can get enough folks to post on the MIP list that they're > interested in VPN gateway traversal we can consider whether to pursue > a draft on it. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:12:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01695 for ; Wed, 13 Feb 2002 23:12:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29714; Wed, 13 Feb 2002 21:11:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17786; Wed, 13 Feb 2002 20:10:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIf020843 for ; Wed, 13 Feb 2002 19:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3e3n7020828 for mobile-ip-dist; Wed, 13 Feb 2002 19:40:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Fh020775 for ; Wed, 13 Feb 2002 19:39:02 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12599 for ; Wed, 13 Feb 2002 19:18:47 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28342 for ; Wed, 13 Feb 2002 19:18:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Sun, 20 Jan 2002 18:34:00 -0500 (EST) From: Young-Jun Lee To: IETF Mobile IP WG Subject: [mobile-ip] Multicast routing issue in MIP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 801 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think multicasting in mip is also an impportant issue. RFC2002 mentions multicasting simply thru only one page. But I could not find any discussion about that issue in this working group. Is this because there are lots of other important issues that wg should focus on? Or should this issue be handled by other wg? I'd appreciate it if anybody would explain about this situation. Regards, Young-Jun Lee Georgia Institute of Technology From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:12:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01717 for ; Wed, 13 Feb 2002 23:12:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29625; Wed, 13 Feb 2002 21:12:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17769; Wed, 13 Feb 2002 20:10:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJv020843 for ; Wed, 13 Feb 2002 19:42:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3IqeM019747 for mobile-ip-dist; Wed, 13 Feb 2002 19:18:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HnFh019486 for ; Wed, 13 Feb 2002 19:17:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04618; Wed, 13 Feb 2002 19:17:52 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21739; Wed, 13 Feb 2002 20:17:51 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C18E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Is RR only enough ? Date: Thu, 3 Jan 2002 15:29:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => I can't see how we can do RR only and still maintain > > that our requirement is "Add no harm". Connection > > hijacking can be considered "new harm" and RR will > > not stop it. IMHO (and I'm not a security expert) > > the combination of CGAs and RR is an excellent idea > > and will give quite a strong security. > > Any node on the path between two communicating entities today can be > MiTM for TCP connections and UDP "flows". If IPsec/TLS/etc > is not used those > MiTM can modify the content of the communication; otherwise they can > just cause a DoS by dropping packets (or modifying them and > having the > receipient drop then due to authentication failure). > > Adding MIPv6 a BU protected by RR doesn't seem to make this > any worse. > What am I missing? > Status: RO X-UID: 56 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: => Probably nothing, but consider this scenario and see if it is possible: A MiTM is performing an active attack by sending a BU to the CN to direct the MN's traffic to itself. Now this Bad Guy happens to be on the path between the CN and the HA. In this case, if RR (only) is used, Bad Guy will be able to steal all the MN connections with the CN, and her can keep refreshing the BU to disallow future communication with that particular Home address. However, if RR, combined with CGAs is used, this can not happen (well, or it becomes as hard as it is to generate a duplicate CGA). As far as I can see this situation is an 'addition of harm' compared to today's Internet, and is due to the BU. That's why I think RR and CGA are a good combination. Have I missed something ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:12:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01730 for ; Wed, 13 Feb 2002 23:12:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08632; Wed, 13 Feb 2002 21:12:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26410; Wed, 13 Feb 2002 20:12:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJJ020843 for ; Wed, 13 Feb 2002 19:41:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3e5gZ020832 for mobile-ip-dist; Wed, 13 Feb 2002 19:40:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGb020453 for ; Wed, 13 Feb 2002 19:38:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05070 for ; Wed, 13 Feb 2002 19:19:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15075 for ; Wed, 13 Feb 2002 20:18:59 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <01be01c1a4c2$c07f6670$ac5a4f82@ustrasbg.fr> From: "Christophe Jelger" To: References: <2E33960095B58E40A4D3345AB9F65EC102DB7F02@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [mobile-ip] Multicast routing issue in MIP Date: Thu, 24 Jan 2002 11:34:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 945 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I checked your slides a few days ago and also proposed a different solution in an Internet draft (draft-jelger-mssmsv6-00.txt) that has just been published yesterday. I hope you'll find some time to read it and to give me some feedback on that, especially as you have quite an experience when dealing with multicast in general. Christophe ----- Original Message ----- From: "Dave Thaler" To: Sent: Monday, January 21, 2002 1:51 AM Subject: RE: [mobile-ip] Multicast routing issue in MIP > After announcing it at the MIP WG, I gave a presentation in the MAGMA WG > at the IETF in SLC on this topic. It looks like the proceedings aren't > online yet. If you want a copy of my slides before they appear on the > ietf site, > let me know. > > In short: there are issues. The multicast language currently in the > MIPv6 spec should be ignored. There are a couple of possible solutions, > ranging from inefficient (e.g., always tunneling via Home Agent) to > complex (requiring a slight change to correspondent node behavior). > > -Dave > > > -----Original Message----- > > From: Young-Jun Lee [mailto:gte393q@prism.gatech.edu] > > Sent: Sunday, January 20, 2002 3:34 PM > > To: IETF Mobile IP WG > > Subject: [mobile-ip] Multicast routing issue in MIP > > > > I think multicasting in mip is also an impportant issue. > > RFC2002 mentions multicasting simply thru only one page. > > But I could not find any discussion about that issue in this > > working group. > > Is this because there are lots of other important issues that wg > should > > focus on? > > Or should this issue be handled by other wg? > > I'd appreciate it if anybody would explain about this situation. > > > > Regards, > > > > Young-Jun Lee > > Georgia Institute of Technology > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:13:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01751 for ; Wed, 13 Feb 2002 23:13:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08832; Wed, 13 Feb 2002 21:12:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17950; Wed, 13 Feb 2002 20:11:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJF020843 for ; Wed, 13 Feb 2002 19:41:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JjsV019787 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HuFh019529 for ; Wed, 13 Feb 2002 19:17:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11595; Wed, 13 Feb 2002 19:17:54 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02344; Wed, 13 Feb 2002 19:17:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Fri, 4 Jan 2002 03:51:34 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Re: Is RR only enough ? To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C18E@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 110 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => Probably nothing, but consider this scenario and see > if it is possible: > A MiTM is performing an active attack by sending a BU to > the CN to direct the MN's traffic to itself. > Now this Bad Guy happens to be on the path between the > CN and the HA. In this case, if RR (only) is used, > Bad Guy will be able to steal all the MN connections > with the CN, and her can keep refreshing the BU to disallow > future communication with that particular Home address. Yes this is a possible attack. But you seem to be implicitly claiming that this is worse than today's IPv4 network with an attacker on the path between the communicating nodes. That is the argument I don't understand i.e. why is this any more harmful than the MiTM attacking every TCP connection and UDP "session"? The MiTM is on the path between the communicating nodes. > However, if RR, combined with CGAs is used, this can not > happen (well, or it becomes as hard as it is to generate > a duplicate CGA). I fully agree that RR+CGA doesn't have this problem thus it is more secure. > As far as I can see this situation is an 'addition of harm' > compared to today's Internet, and is due to the BU. So why is it worse? Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:15:42 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01864 for ; Wed, 13 Feb 2002 23:15:42 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00575; Wed, 13 Feb 2002 20:13:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26499; Wed, 13 Feb 2002 20:12:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJh020843 for ; Wed, 13 Feb 2002 19:41:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JvEN019805 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3I1Fh019587; Wed, 13 Feb 2002 19:18:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04632; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14585; Wed, 13 Feb 2002 20:17:54 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Wed, 26 Dec 2001 21:38:53 +0200. <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> Date: Fri, 04 Jan 2002 16:37:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 125 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: However, I'm concerned about the "applied allover" part. Specifically - while I'm very much fond of the AAA solutions - I'm concerned whether we can expect all parts of the Internet to have an infrastructure that really can figure out the home addresses. What if there's a coin-operated (or Visa-) airport WLAN? => this is a problem of trust in the local/visited domain *and* in the remote/home domain. In your example if I understand the issue is the lack of trust in the local/visited domain, so one may reject traffic with home address options from it. Finally, I seem to remember there was a discussion a long time ago whether we could somehow provide automatic, mandatory, ingress filtering in IPv6. => my concern is that the "mandatory" term in a RFC is not enough to enforce it in the real world. Currently, we are headed towards the same situation as in IPv4 where ingress filtering is only partially applied, and we keep coming up with "patch" solutions such as I-trace to help the situation. => ingress filtering has more problems with IPv4, mainly because it was not considered from the beginning. But it is already a BCP and it seems that most ISPs use it (feedback from ISPs please). Interestingly, these solutions typically need changes to a large fraction of the routers in the Internet which we already are doing anyway to move to IPv6... => we can expect to avoid the same errors with IPv6. Unfortunately ingress filtering (like network management) is something where IPv6 is not yet at the same level than for IPv4 today. We hope this situation will be improved very fast. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:18:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01960 for ; Wed, 13 Feb 2002 23:18:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12185; Wed, 13 Feb 2002 21:18:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18705; Wed, 13 Feb 2002 20:17:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJp020843 for ; Wed, 13 Feb 2002 19:42:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VHvV020408 for mobile-ip-dist; Wed, 13 Feb 2002 19:31:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5G9020208 for ; Wed, 13 Feb 2002 19:30:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16648 for ; Wed, 13 Feb 2002 19:18:45 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07325 for ; Wed, 13 Feb 2002 20:18:44 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <01FAF65DEA16D4119B95009027E78F310930EF1D@il02exm26.comm.mot.com> From: Lewis Adam-CAL022 To: Mobile-IP working group Subject: [mobile-ip] HA redundancy in MIPv4 Date: Fri, 18 Jan 2002 15:31:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 776 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: What work is being done in this area? I know that Cisco has a solution which runs a HA redundancy protocol on top of HSRP, and 3Com seems to have a HA chassis solution that supports redundant HAs. Both these seem to be proprietery in nature. A draft not too long ago draft-chambless-mobileip-harp-00.txt talked about doing it, but I haven't seen any follow up activity to it. This seems to me like a critical problem to solve, does anybody have any further information on this relating to a standards activity? Maybe something similar to what Cisco does, but using VRRP instead? Thanks, adam From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:20:38 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02019 for ; Wed, 13 Feb 2002 23:20:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA03083; Wed, 13 Feb 2002 20:19:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17324; Wed, 13 Feb 2002 20:06:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIl020843 for ; Wed, 13 Feb 2002 19:41:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3V5Xr020402 for mobile-ip-dist; Wed, 13 Feb 2002 19:31:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5Fx020208 for ; Wed, 13 Feb 2002 19:30:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16679 for ; Wed, 13 Feb 2002 19:18:49 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02702 for ; Wed, 13 Feb 2002 19:18:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: Mon, 21 Jan 2002 22:37:37 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <15436.28017.39358.549788@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 832 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 21 Jan 2002, Michael Thomas wrote: > Yet another oops. Can we *please* change this to > not be reply-to: mobile-ip? Who is the list owner??? I fail to see how it would have changed the situation here? It seems more likely someone had a bad email shortcut. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:23:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02052 for ; Wed, 13 Feb 2002 23:23:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05381; Wed, 13 Feb 2002 21:23:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17820; Wed, 13 Feb 2002 20:10:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJ1020843 for ; Wed, 13 Feb 2002 19:41:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3VUMD020414 for mobile-ip-dist; Wed, 13 Feb 2002 19:31:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3U5GP020208 for ; Wed, 13 Feb 2002 19:30:28 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16674 for ; Wed, 13 Feb 2002 19:18:49 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28350 for ; Wed, 13 Feb 2002 19:18:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C4C6A72.C11B6288@cisco.com> Date: Mon, 21 Jan 2002 11:22:26 -0800 From: Alpesh Patel X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 825 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharath, Just to let you know, the code where I thought would be a problem was an oversight. That is the reason, I just asked if it was tested. I think Roy added this code, but would wait for him to respond -a Sharath Veldanda wrote: > Alpesh, > > Do you have the DDTS number handy ?? > > -S > > >Date: Mon, 21 Jan 2002 11:01:07 -0800 > >From: Alpesh Patel > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: mobileip-coders@cisco.com, mobileip-dt@cisco.com > >Subject: Questions about ipmobile_AddAddrTypeExt() in ipm_standby.c > >Content-Transfer-Encoding: 7bit > > > >Team, > > > >Wondering if the ddts that added the code related to the function > >ipmobile_AddAddrTypeExt() was tested /regression tested. > > > >If it was tested, the owner needs to work with a DT to add it into > >regression suite. > > > >-a > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:26:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28399 for ; Wed, 13 Feb 2002 22:27:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16120; Wed, 13 Feb 2002 20:27:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15178; Wed, 13 Feb 2002 19:27:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3QaFh020129 for ; Wed, 13 Feb 2002 19:26:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Qa1w020128 for mobile-ip-dist; Wed, 13 Feb 2002 19:26:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXJx019898 for ; Wed, 13 Feb 2002 19:26:30 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11674; Wed, 13 Feb 2002 19:18:01 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27967; Wed, 13 Feb 2002 19:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C385158.8010201@nomadiclab.com> Date: Sun, 06 Jan 2002 15:30:00 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 179 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, Hesham and others, On the question of whether RR alone could provide security that is in par with IPv4 security, I think I have came up with an attack scenario that RR alone does not block (see below). However, this attack is certainly fairly far fetched, and I _personally_ could imagine that being vulnerable to this one _might_ be acceptable. The attack scenario: Let us consider an attacker A, a corrensponding node CN, and a pre-selected mobile node MN whose home address is HoA. Now, A has decided to steal all traffic that CN will initiate towards MN. To do so, it somehow arranges itself _once_ to the path between CN and MN's HA. It may do this, for example, by visiting the network where CN is located, where MN's HA is located, or any network in between. While being at the path between CN and MN's HA, the attacker creates a binding (and a corresponding BSA) at CN. This will succeed, since A knows MN's home address and it can foil the RR test. As a result, CN believes that MN is currently located at the adddress given by A, and therefor whenever it sends packets to MN, it will send them to the attacker. Thus, A is able to steal all connections initiated by CN towards MN. Furthermore, if CN does not check the return routability of the MN's home address if there is already an existing BSA, then the attacker can keep up the faulty binding as long as it wishes, simply by renewing the binding and BSA periodically. To renew, it no longer needs to be at the path between the CN and the MN's HA. Discussion: This attack is not present in IPv4 since in this scenario the attacker steals all traffic _beforehand_, and does not need to be on the vulnerable path later when the communication session is actually initiated. Thus, there is a potential class of attackers that may be able to launch this attack but that could not attack under the current IPv4 architecture. This attack is most effective if the discussed MN is not actually a mobile node but a stationary node. In that case the node will never send binding updates or home address options. As a result, the attacker may be able to renew the faulty binding and BSA for long times. Furthermore, even if the node initiates a connection, the CN will send replies to the attacker, allowing the attacker to spy or DoS this connection as well. Still further, if the attacker performs the same attack against both parties, it may establish itself as full MitM for all future communications between the parties. In a way, this is a variant of the "future attack" that I described at the 50th IETF SAAG meeting, see http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf If we consider stationary nodes communicating with CNs, i.e. about generic non-mobile-ipv6 traffic, this attack appears to be most devious. Since the nodes do not assume their peer to have a binding for them, they have hard time in determining that there actually is one. If the attacker is careful enough, it may get along for long times. Thus, the only protection here is that the attacker actually needs _once_ to get access to the vulnerable path between the CN and the HoA. Let us consider this "_once_ at the vulnerable path requirement." If all the links involved are physically protected, i.e. if the links do not accept unauthenticated nodes, the only realistic threat that I see is the attacker breaking in into _some_other_ computer at one of the links. For example, if the CN is a web server at a DMZ, and the DMZ also contains e.g. a poorly administered Linux-login box, just breaking in to that Linux box could make it possible to initiate the required faulty bindings at the CN. As a consequence, once it is found out that the Linux box has been compromised, the CN must be cleared of any bindings, just to be sure. Whether this risk is considered large enough to mandate using CGAs, i.e. potentially IPR protected technology, goes beyond my apprehension. But I certainly think there seems to be reason to make CGAs a preferred and recommended practise, and to be recommended that bindings that have not been protected with CGA should have relatively short lifetime, and not be renewable without full RR test upon renewal. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 13 23:34:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02751 for ; Wed, 13 Feb 2002 23:34:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09465; Wed, 13 Feb 2002 21:33:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21308; Wed, 13 Feb 2002 20:33:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E4S3Fh025008 for ; Wed, 13 Feb 2002 20:28:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4S3ii025007 for mobile-ip-dist; Wed, 13 Feb 2002 20:28:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXH1019898 for ; Wed, 13 Feb 2002 19:25:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11789 for ; Wed, 13 Feb 2002 19:18:07 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07030 for ; Wed, 13 Feb 2002 20:18:06 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Date: 9 Jan 2002 12:12:57 +0800 Message-ID: <20020109121257.5782.qmail@eyou.com> From: "Weishuai Yang" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Any pointer on mobile ip simulators List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 289 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I'm trying to simulate Fast Handover on the base of Mobiwan contributed by Thierry. I successfully run it on Red Hat 7.2, although I really take pains to make it run. I'm reading Thierry's code right now. Best Regards, Weishuai Yang ÔÚÄúµÄÀ´ÐÅÖÐÌáµ½ >Well, you better use NS-2, it's free, you only need a PC (Linux, >Solaris), and most published papers have run simulations using NS. > >Mobile IPv4 has been contributed to NS-2 a long time ago and is part >of the official distribution. See ns-2 web page: >http://www.isi.edu/nsnam/ns/ > >As for Mobile IPv6, I have contributed code (called MobiWan), but it's >not part of the official distribution yet. It is designed with NS-2 >version b6. See my web page about MobiWan: >http://www.inrialpes.fr/planete/pub/mobiwan/ Be aware that it comes >with no guarantees and that some people that tried to use it had many >difficultites to make it run, and even to compile it. I think recent >compilers don't compile my code. Though, it compiles and run >perfectly on my Solaris OS, with a not-too-recent compiler, for my own >simulations. > >Depending on my availability, I may port the code to the >current version of NS-2 (b9), so that it becomes an official part of >the distribution. > >Hope this helps, >Thierry - WIDE Project. > > >> Hi all, >> >> Can anybody help me to get some light about simulators available for mobile >> ip and required equipment to run them. >> >> >> Thansk alot >> Ravikumar Kota > > > --http://www.eyou.com --Îȶ¨¿É¿¿µÄÃâ·Ñµç×ÓÐÅÏä ÓïÒôÓʼþ Òƶ¯ÊéÇ© ÈÕÀú·þÎñ ÍøÂç´æ´¢...ÒÚÓÊδ¾¡ From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 00:10:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03307 for ; Thu, 14 Feb 2002 00:10:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28299; Wed, 13 Feb 2002 22:10:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18281; Wed, 13 Feb 2002 21:10:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E595Id025535 for ; Wed, 13 Feb 2002 21:09:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E57gDo025522 for mobile-ip-dist; Wed, 13 Feb 2002 21:07:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0I5020775; Wed, 13 Feb 2002 19:40:12 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12552; Wed, 13 Feb 2002 19:18:34 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28245; Wed, 13 Feb 2002 19:18:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C216@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Cc: jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] How to move forward in the HAO & ingress filter d iscussion Date: Thu, 17 Jan 2002 15:17:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Also, waiting for AAA solutions to be available > (specified, implemeted, > > and deployed) before MIPv6 can be used seems to be > counter to our desire > > to finish up MIPv6 soon. > > > > => I never proposed to wait for AAA solutions (as I > ask only for network > > access control, not everywhere but enough to make HAO > spoofing unattractive). > > Are you proposing to wait until network access control > is available? > (specified, implemented, and deployed) > > => we don't need to wait because mobile IPv6 is not yet > fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls > with IPv6 support > (or do you suggest to stop IPv6 until they are implemented > and deployed?) Status: RO X-UID: 646 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: => Ah, now I now what you meant before by not needing a solution. But this is really scarey, are you saying we wait until last call ( or worse, proposed standard) and then bring this up again ? Some people don't like that Francis :-) How can we be sure that the 'paper solution' you refer to will be deployed by the time MIPv6 is, if ever ... Hesham > > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In > parallel (because > even if the triangular routing is killed there are still > similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for > instance a > new RADIUS attribute for IPv6 inner source address > declaration). IMHO > this second part is mainly not technical (i.e. out of the > scope of IETF). > > Seems like this requires a two-phase approach: phase 1 > before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in > a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, > IPv6 ingress > filtering, IPv6 firewalls, ... > > What am I missing? > > => mobile IPv6 is not yet in last call, in fact we don't > know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. > But I agree we have to know where we are going or we could lose more > than our time in this kind of discussions (i.e. > implementers don't like > to follow random moving specs). > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 00:12:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03367 for ; Thu, 14 Feb 2002 00:12:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18048; Wed, 13 Feb 2002 22:12:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18657; Wed, 13 Feb 2002 21:12:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5AmIf025578 for ; Wed, 13 Feb 2002 21:10:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E4lugl025407 for mobile-ip-dist; Wed, 13 Feb 2002 20:47:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3d0Hb020775; Wed, 13 Feb 2002 19:40:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12282; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14605; Wed, 13 Feb 2002 20:17:56 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <933FADF5E673D411B8A30002A5608A0E0152FC17@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Was Node Mobility a Requirement for IPng? Date: Fri, 4 Jan 2002 14:26:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1955E.25F9D900" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 151 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/plain; charset="iso-8859-1" Hello, Does anyone know if node mobility was a requirement for IPng during the debates among the proposals? If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on. I'm just trying to understand the thinking of the past and how each might be reason to affect the other. Thanks, Glenn ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/html; charset="iso-8859-1"
Hello,
 
Does anyone know if node mobility was a requirement for IPng during the debates among the proposals?
 
If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on.
 
I'm just trying to understand the thinking of the past and how each might be reason to affect the other.
 
Thanks,
 
Glenn
------_=_NextPart_001_01C1955E.25F9D900-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 00:13:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03394 for ; Thu, 14 Feb 2002 00:13:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19098; Wed, 13 Feb 2002 22:12:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18787; Wed, 13 Feb 2002 21:12:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5BbIb025697 for ; Wed, 13 Feb 2002 21:11:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5Baex025696 for mobile-ip-dist; Wed, 13 Feb 2002 21:11:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5BJIl025602 for ; Wed, 13 Feb 2002 21:11:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04604 for ; Wed, 13 Feb 2002 20:51:35 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13048 for ; Wed, 13 Feb 2002 21:51:34 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1E4pXe21714 for ; Wed, 13 Feb 2002 20:51:33 -0800 (PST) Message-ID: <013d01c1b513$0cd5f880$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <3C42EDE0.5D8720D4@iiic.ethz.ch> Subject: Re: [mobile-ip] IP address of new access router Date: Wed, 13 Feb 2002 20:49:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thomas, The Seamoby WG is looking at ways to do dynamic reverse address translation for candidate access routers. This would also include the prefix info. It is also possible to have this statically configured. jak ----- Original Message ----- From: "Thomas Heinis" To: Sent: Monday, January 14, 2002 6:40 AM Subject: [mobile-ip] IP address of new access router > Hi all, > I have got some problems concerning the Mobile Determined Handover > described in draft 3 for Fast Handovers for Mobile IPv6. The MN sends a > Router Solicitation for Proxy message to the old access router > containing the link local address of the new access router. After that, > the old access router is supposed to send a Handover Initiation to the > new access router. Wherefrom does the old access router know the IP > address of the new access router(unless NAR is a neighbour of the OAR)? > The OAR only has the link local address of NAR sent by MN in the Router > Solicitation for Proxy. > Furthermore I don't really see wherefrom OAR has the prefix information > about NAR it should send back to the MN in the Proxy Router > Advertisement? > > Please forgive me if this is the wrong mailing list or if these > questions have already been discussed(I've had a look at the archives > but didn't find anything). > > Regards > > Thomas > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 00:16:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03435 for ; Thu, 14 Feb 2002 00:16:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11805; Wed, 13 Feb 2002 21:16:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19349; Wed, 13 Feb 2002 21:16:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5EcIb025887 for ; Wed, 13 Feb 2002 21:14:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5Ecxi025886 for mobile-ip-dist; Wed, 13 Feb 2002 21:14:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXJJ019898; Wed, 13 Feb 2002 19:26:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11983; Wed, 13 Feb 2002 19:18:29 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07152; Wed, 13 Feb 2002 20:18:25 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <200201151504.g0FF4MQ52034@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 16:24:03 +0200. Date: Tue, 15 Jan 2002 16:04:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Status: RO X-UID: 563 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. In theory, yes. But the question is, does it really make that much of a difference as long as at least one way is "unoptimized"? => the same difference than when both ways are unoptimized or optimized. Difference in distance is the same, difference in byte overhead too. This is true for all points with one exception: protocol complexity because triangular routing has roughly the same complexity than bidirectional tunneling. Practice? I don't think there's much difference in bidir tunnel/triangular routing; I doubt e.g. TCP would be able to get much better performance from triangular than from bi-dir (and there are goals like hiding your origins that triangular cannot solve). => I can't see how TCP is involved. I believe your argument is different: if the traffic is very asymmetrical (more on one way than on the other), you prefer to have it on the optimized way... I am afraid the real argument against the triangular routing is this discussion itself because the main triangular routing advantage comes from the (future) fact that HAO is supported by every IPv6 nodes. With enough FUD this shall never become true and the advantage shall vanish... I'd like to get the opinion of IPv6 implementors (if they don't filter out this boring discussion) about HAO (for it, against it, will/won't implement it, will/won't enable it by default, etc). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 00:17:30 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03492 for ; Thu, 14 Feb 2002 00:17:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA00406; Wed, 13 Feb 2002 22:17:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19616; Wed, 13 Feb 2002 21:17:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E5EvIb025925 for ; Wed, 13 Feb 2002 21:14:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E5EvKu025924 for mobile-ip-dist; Wed, 13 Feb 2002 21:14:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXJj019898; Wed, 13 Feb 2002 19:26:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11673; Wed, 13 Feb 2002 19:18:00 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02394; Wed, 13 Feb 2002 19:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15413.58187.884431.562406@thomasm-u1.cisco.com> Date: Fri, 4 Jan 2002 09:15:55 -0800 (PST) To: Francis Dupont Cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> References: <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 136 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. RPF checks "work" mainly because they are so painless for ISP's to implement. Anything beyond that is likely to be a complete non-starter. Mike Francis Dupont writes: > In your previous mail you wrote: > > However, I'm concerned about the "applied allover" > part. Specifically - while I'm very much fond of the AAA solutions - > I'm concerned whether we can expect all parts of the Internet to have > an infrastructure that really can figure out the home addresses. What > if there's a coin-operated (or Visa-) airport WLAN? > > => this is a problem of trust in the local/visited domain *and* in the > remote/home domain. In your example if I understand the issue is the lack > of trust in the local/visited domain, so one may reject traffic with > home address options from it. > > Finally, I seem to remember there was a discussion a long time ago whether > we could somehow provide automatic, mandatory, ingress filtering in IPv6. > > => my concern is that the "mandatory" term in a RFC is not enough to > enforce it in the real world. > > Currently, we are headed towards the same situation as in IPv4 > where ingress filtering is only partially applied, and we keep coming > up with "patch" solutions such as I-trace to help the situation. > > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). > > Interestingly, these solutions typically need changes to a large > fraction of the routers in the Internet which we already are doing > anyway to move to IPv6... > > => we can expect to avoid the same errors with IPv6. Unfortunately > ingress filtering (like network management) is something where IPv6 > is not yet at the same level than for IPv4 today. We hope this situation > will be improved very fast. > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 01:30:59 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04261 for ; Thu, 14 Feb 2002 01:30:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA18237; Wed, 13 Feb 2002 22:30:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23126; Wed, 13 Feb 2002 22:30:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6TkKL028494 for ; Wed, 13 Feb 2002 22:29:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E6Tkp4028493 for mobile-ip-dist; Wed, 13 Feb 2002 22:29:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from opal.eng.sun.com (opal [129.146.86.88]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6TgKL028485 for ; Wed, 13 Feb 2002 22:29:42 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6TjjK115455 for ; Wed, 13 Feb 2002 22:29:45 -0800 (PST) Delivery-Date: Wed, 13 Feb 2002 22:28:08 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by opal.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6S7jK115411 for ; Wed, 13 Feb 2002 22:28:07 -0800 (PST) Received: from opal.eng.sun.com (opal [129.146.86.88]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6S3KL028461; Wed, 13 Feb 2002 22:28:03 -0800 (PST) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6S6jK115404; Wed, 13 Feb 2002 22:28:06 -0800 (PST) Message-Id: <200202140628.g1E6S6jK115404@opal.eng.sun.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.3 To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Cc: postmaster@sunroof.eng.sun.com Subject: [mobile-ip] sorry about that... X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Feb 2002 22:28:06 -0800 From: John Beck Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, Someone seems to have decided to re-send hundreds of old messages to your lists tonight. Fortunately, I was on duty and noticed a general problem, and one of your list mates (George Mitchell) was diligently paying attention and provided me with helpful details which greatly sped up my diagnosis. Anyway, the flood of the remaining 275 or so has been diverted and the offending site blocked, at least for now, though you may still get a trickle of messages that are still en route. I have also informed the postmaster of the problem site, as this sort of thing is usually a misconfiguration rather than someone being malicious. -- John Beck (postmaster@sunroof is one of my many hats) From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 02:25:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12539 for ; Thu, 14 Feb 2002 02:25:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19770; Thu, 14 Feb 2002 00:25:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17895; Wed, 13 Feb 2002 20:10:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekIn020843 for ; Wed, 13 Feb 2002 19:41:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PfZa020087 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFx019898 for ; Wed, 13 Feb 2002 19:24:38 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11797 for ; Wed, 13 Feb 2002 19:18:09 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28061 for ; Wed, 13 Feb 2002 19:18:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: From: "Lajos Zaccomer (ETH)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] bitstring for calculating Authentication Data Date: Wed, 9 Jan 2002 14:17:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 303 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Can anyone tell me, why does not the bitstring for calculating Authentication Data of a BA contain the reserved field? In case of BU, all the reserved octets are included. Including that mysterious octet in the bitstring would simplify calculation. Otherwise, the reserved field of BU should be removed either. Zacco From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 02:35:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12655 for ; Thu, 14 Feb 2002 02:35:29 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22560; Thu, 14 Feb 2002 00:35:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17579; Wed, 13 Feb 2002 20:08:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJl020843 for ; Wed, 13 Feb 2002 19:41:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Prk6020099 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXG7019898 for ; Wed, 13 Feb 2002 19:24:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12276 for ; Wed, 13 Feb 2002 19:19:02 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15093 for ; Wed, 13 Feb 2002 20:19:01 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-Id: <200201301001.g0UA1Lg37756@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 28 Jan 2002 10:21:01 PST. <3C55968D.3180DEC@iprg.nokia.com> Date: Wed, 30 Jan 2002 11:01:21 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Status: RO X-UID: 975 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I thought it was pretty obvious. the new destination option has to be before the fragment header and after the routing header. it makes no sense having it after the fragment header (if ever fragmentation is done for a packet). => I agree but this means there is no difference from the IPsec point of view between a new DO and a new RH type (i.e. this withdraws a possible argument in favour of a new DO). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 02:43:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12756 for ; Thu, 14 Feb 2002 02:43:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25066; Thu, 14 Feb 2002 00:43:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17913; Wed, 13 Feb 2002 20:11:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJT020843 for ; Wed, 13 Feb 2002 19:41:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3Q4aZ020110 for mobile-ip-dist; Wed, 13 Feb 2002 19:26:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXGR019898 for ; Wed, 13 Feb 2002 19:24:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12010 for ; Wed, 13 Feb 2002 19:18:36 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14882 for ; Wed, 13 Feb 2002 20:18:31 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f X-mProtect: Tue, 15 Jan 2002 08:35:06 -0800 Nokia Silicon Valley Messaging Protection Message-ID: <3C445A39.81EF4F15@iprg.nokia.com> Date: Tue, 15 Jan 2002 08:35:05 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ahmad Muhanna CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Changes to RFC2002bis (Vers 8) References: <6B49EDFE974BD51197D70002A56079D82AF65F@zrc2c013.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 569 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ahmad, Hello Ahmad, > Ahmad Muhanna wrote: > > Hello Basavaraj; > > Could you please brief us with the rationale behind the changes of the 1st > paragraph in section 2.3? > As far as I know, the Mobile Node as per RFC2002-bis and RFC1256 can send > Agent Solicitation message to either > 255.255.255.255 or 224.0.0.2. This is true. The rationale for putting the additional tex into RFC 2002bis was that I was asked to do so during Last Call for RFC 2002bis. Since it does not do any harm to the specification to have it, and since people thought it made the specification clearer, I was happy to put it in. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 02:57:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12874 for ; Thu, 14 Feb 2002 02:57:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24996; Thu, 14 Feb 2002 00:57:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17878; Wed, 13 Feb 2002 20:10:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJb020843 for ; Wed, 13 Feb 2002 19:41:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3PO7R020079 for mobile-ip-dist; Wed, 13 Feb 2002 19:25:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3OXFl019898 for ; Wed, 13 Feb 2002 19:24:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12212; Wed, 13 Feb 2002 19:18:55 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22269; Wed, 13 Feb 2002 20:18:53 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f To: Jari Arkko Cc: mobile-ip@sunroof.eng.sun.com, hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> From: Alexandru Petrescu Date: 23 Jan 2002 15:03:05 +0100 In-Reply-To: <3C4EB9E7.377A562D@lmf.ericsson.se> Message-Id: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 887 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alex Petrescu: > >An attacker on an intermediate router on CN-HA path could add a static > >host route to MN through an alternate path. Just add it, save > >configuration and leave. Next time packets from CN destined to MN > >will go on the alternate path, without attacker being there, right? > Jari Arkko writes: > Adding a static host route would require compromised router, > is this what you were thinking? Yes, I was thinking about compromised routers (or cutting cables). This is needed for the future attack to succeed against RR as described by Pekka. And if attacker can compromise routers or cut cables then he can launch a future attack in today's Internet too, by changing routing tables or putting his own router in between. Thus RR is no worse than v4. > I think a more likely threat model is someone plugging in > their laptop at an Ethernet somewhere, but not necessarily > being able to get in to the routers. (Of course it is possible > to get to the routers as well, just less likely.) This is indeed a more likely scenario. But without access to router, attacker can do less harm and is also in danger of being detected by its neighbours. Windows, Solaris and HP-UX already do that, I think. Besides, I do not think that the future attack against RR as described by Pekka is feasible only by plugging a laptop and using ND. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 02:58:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12892 for ; Thu, 14 Feb 2002 02:58:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29704; Thu, 14 Feb 2002 00:58:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17580; Wed, 13 Feb 2002 20:08:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJP020843 for ; Wed, 13 Feb 2002 19:41:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3drbK020821 for mobile-ip-dist; Wed, 13 Feb 2002 19:39:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3YcGX020453 for ; Wed, 13 Feb 2002 19:38:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04857 for ; Wed, 13 Feb 2002 19:18:40 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22140 for ; Wed, 13 Feb 2002 20:18:39 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f X-Delivered-For: X-mProtect: Thu, 17 Jan 2002 11:36:27 -0800 Nokia Silicon Valley Messaging Protection Message-ID: <3C4727BA.3787F298@iprg.nokia.com> Date: Thu, 17 Jan 2002 11:36:26 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIP v6 next steps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 690 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil and Raj, I want Francis Dupont included in the design team. He has probably more experience with Mobile IPv6 than most people in this WG. the design team you have selected does not make sense IMHO. you dont have anybody who has implemented MIPv6 on the design team. please correct me if I am wrong. Phil Roberts wrote: > > Hi, > > we've formed a small design team to close the open issues based on WG > consensus for MIPv6. > It consists of Jari Arkko, Gabriel Montenegro, and Erik Nordmark. The And would the mail archives and minutes from teleconferences made public? Vijay > chairs and area advisor > are monitoring what's going on there. The following open issues need to be > closed based on WG > consensus: > 1) what strength of protection to use for BUs and the protocol > mechanisms to make that happen, > 2) how to protect against certain forms of attacks using routing > headers, > 3) how to protect against certain forms of attacks using the home > address option, and > 4)what to do about piggybacking. > > In the next couple of weeks threads will be started listing the possible > options, there will be time for discussion, and the chairs will make working > group consensus calls. The protection of BU description will probably be a > new Internet Draft which will later be incorporated into the MIPv6 > specification. We expect the description of the BU draft to be out by Feb > 8, and to incorporate it and discussion items based on it in > time to have a WG last call complete by the Friday of the Minneapolis > meeting. > > Phil and Raj From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 03:00:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12938 for ; Thu, 14 Feb 2002 03:00:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00500; Thu, 14 Feb 2002 01:00:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17929; Wed, 13 Feb 2002 20:11:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3ekJ9020843 for ; Wed, 13 Feb 2002 19:41:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1E3JrHl019802 for mobile-ip-dist; Wed, 13 Feb 2002 19:19:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E3HsFh019514; Wed, 13 Feb 2002 19:17:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12187; Wed, 13 Feb 2002 19:17:53 -0800 (PST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13359; Wed, 13 Feb 2002 20:17:52 -0700 (MST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Message-ID: <3C342515.10904@nomadiclab.com> Date: Thu, 03 Jan 2002 11:32:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Status: RO X-UID: 52 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 05:12:22 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14577 for ; Thu, 14 Feb 2002 05:12:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14092; Thu, 14 Feb 2002 02:12:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27634; Thu, 14 Feb 2002 02:12:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EAAwKL029370 for ; Thu, 14 Feb 2002 02:10:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EAAwAH029369 for mobile-ip-dist; Thu, 14 Feb 2002 02:10:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EAAtKL029362 for ; Thu, 14 Feb 2002 02:10:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00366 for ; Thu, 14 Feb 2002 02:10:58 -0800 (PST) Received: from netdns.netas.com.tr ([195.155.2.162]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05801 for ; Thu, 14 Feb 2002 02:10:52 -0800 (PST) Received: from netas.com.tr (47.165.145.36 [47.165.145.36]) by netdns.netas.com.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1DZ65LP7; Thu, 14 Feb 2002 12:08:32 +0200 Message-ID: <3C6B8D5D.87028FCE@netas.com.tr> Date: Thu, 14 Feb 2002 12:11:42 +0200 From: Oner Tekin X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] ns2.1b6a tclPosixStr.patch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, Is there anyone who know that how tclPosixStr.patch is applied, manualy or automated? Thanks in advance. Oner Tekin. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 06:46:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15439 for ; Thu, 14 Feb 2002 06:46:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03590; Thu, 14 Feb 2002 04:33:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00268; Thu, 14 Feb 2002 03:33:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EBWKKL029517 for ; Thu, 14 Feb 2002 03:32:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EBWJI1029516 for mobile-ip-dist; Thu, 14 Feb 2002 03:32:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EBWFKL029509 for ; Thu, 14 Feb 2002 03:32:16 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EBWAM18268; Thu, 14 Feb 2002 12:32:10 +0100 (MET) Date: Thu, 14 Feb 2002 12:27:56 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] BU Authorization method: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, kempf@docomolabs-usa.com In-Reply-To: "Your message with ID" <200202131536.g1DFa6g09557@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => not only they exist but when the IKE phase 1 uses address identities > (very common, the default mode of every IKE implementations I know > because it is needed for pre-shared keys in main mode) the address > must be the subject(Alt)Name of the certificate. This is checked > for all compliant IKE implementations and all good implementations > check too if the address in the identity and the address used for IKE > messages are the same (a trivial attack if not performed). I having a hard time to parse the above. It seems like you are saying that when the IKE phase 1 uses address identities the addresses must be checked That seems very obvious and not surprising. But IKE can also be used with phase 1 address identities. For instance the IKE certs I use right now have Subject Name: Subject Alternative Names: email = nordmark@eng.sun.com The problem I've pointed out in the past is that I don't see how existing ways of doing PKIs can ensure that an IP address in the subject altname actually is actually the IP address assigned to the node and that can be tracked as the node and/or site renumbers etc. You are pointing out that should a PKI exist that can not only mechanically produce such certificates, but also guarantee that the subject altname IP address is assigned to the holder of the cert, they can be used. I believe both of the above are true and independent. So are we in violent agreement that while the mechanisms in IKE work when using such certificates I can't get such a useful certificate from existing commercial PKIs (like Verisign etc)? > Don't forget that the "road warrior" case is supported by many IPsec > implementations so this is more a question of how protocols are (mis)used > than about protocols themselves. What does that have to do with the subject at hand? My laptop certificate doesn't (and can't) use an IP address as a suject altname because the IP address is different depending on where I connect. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 09:22:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18702 for ; Thu, 14 Feb 2002 09:22:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27496; Thu, 14 Feb 2002 07:22:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21657; Thu, 14 Feb 2002 06:22:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EEL5KL029825 for ; Thu, 14 Feb 2002 06:21:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EEL5pH029824 for mobile-ip-dist; Thu, 14 Feb 2002 06:21:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EEKwKL029809; Thu, 14 Feb 2002 06:20:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14858; Thu, 14 Feb 2002 06:21:02 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14275; Thu, 14 Feb 2002 07:21:01 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1EEKxk28131; Thu, 14 Feb 2002 15:20:59 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA20289; Thu, 14 Feb 2002 15:20:59 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1EEKxg16494; Thu, 14 Feb 2002 15:20:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202141420.g1EEKxg16494@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 03 Jan 2002 11:32:05 +0200. <3C342515.10904@nomadiclab.com> Date: Thu, 14 Feb 2002 15:20:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished... => note the draft was finished and published. The draft is quite nice, thanks for writing it. => thanks for reading it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. => I assume you use AAA in its traditional meaning, i.e. network access control with something like RADIUS. Please don't make the confusion between network addresse control and full AAA with infrastructure, etc. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. => there are other options (look at the mobile-ip list) but it seems the two detailed proposals are ingress filtering using some kind/level of network access control and binding cache entry check. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) => I agree the zero-configuration is very fine and I don't believe into DHCPv6, i.e. something which tries to impose its idea of your address to you. But I make a distinction between to allow hosts to be plugged in and to allow hosts to freely access to the Internet. The device which provides the step between is the network access control. I don't want to enter into details about how to do it, the important notion is the trust/responsability, i.e. if you give some access to a node and something is going wrong, you accept to take the responsability to take care of the problem. IMHO this is more important than ingress filtering itself: without trust/responsability, the bad guy has no need to do source address spoofing. So, as I am perhaps (:-) in the people who disagree with you, what you propose if you get the role of a public access WLAN manager? Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. => this proves ingress filtering reachs its limits when an action is required... When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. => I agree: network access control doesn't imply good administration but usually it is simply part of a at least minimal administration (always better than nothing). For instance location of compromised hosts can be possible. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. => the issue is in the target: you'd like to secure the Internet, this is an admirable idea but, for some reasons you have just explained, not really feasible. My purpose is to get back to the previous situation, i.e. current IPv4 ingress filtering, so I prefer to stress the trust/ responsability stuff (what I called the "responsible usage of the network") because in fact the places where advanced ingress filtering won't work are the places where ingress filtering itself won't work. I have a lot of other arguments but they are already in the zillion of previous messages about the HAO security... BTW the design team proposed a recommendation based on the FUD against mobile IPv6 and selected the BCE check solution. I am very pessimist about the future of mobile IPv6 because the improvements over mobile IPv4 fully rely on the routing optimization: as someone explained, there are only two kinds of common correspondent nodes: web servers, but to deal with routing optimization with its security, hard state binding cache, etc, is too expensive so shan't be done, and mobile terminals (handsets, PDAs, (robust) laptops), the problem is the design team didn't consider this special case (aka mobile to mobile)... We are trying to save something but most of the marvellous promises of mobile IPv6 can already be considered as hype. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 09:44:30 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22985 for ; Thu, 14 Feb 2002 09:44:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25326; Thu, 14 Feb 2002 06:44:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01514; Thu, 14 Feb 2002 06:44:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EEgtKL029961 for ; Thu, 14 Feb 2002 06:42:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EEgtDD029957 for mobile-ip-dist; Thu, 14 Feb 2002 06:42:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EEgoKL029947 for ; Thu, 14 Feb 2002 06:42:51 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EEgdM02199; Thu, 14 Feb 2002 15:42:40 +0100 (MET) Date: Thu, 14 Feb 2002 15:38:20 +0100 (CET) From: Erik Nordmark Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202132203.g1DM3Eg12079@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => basically BCE state will become hard state. Per what definition of hard and soft state? There is a definition of soft state in RFC 2205 which says: o Soft state Control state in hosts and routers that will expire if not refreshed within a specified amount of time. Since binding cache entries expire if not refreshed they seem to be soft state per the above definition. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 10:32:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24303 for ; Thu, 14 Feb 2002 10:32:43 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29769; Thu, 14 Feb 2002 08:32:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12774; Thu, 14 Feb 2002 07:32:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFV4KL000186 for ; Thu, 14 Feb 2002 07:31:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EFV4lT000185 for mobile-ip-dist; Thu, 14 Feb 2002 07:31:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EFUuKL000168; Thu, 14 Feb 2002 07:30:56 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EFUoM07516; Thu, 14 Feb 2002 16:30:50 +0100 (MET) Date: Thu, 14 Feb 2002 16:26:34 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202141420.g1EEKxg16494@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I am very pessimist about the future of mobile IPv6 > because the improvements over mobile IPv4 fully rely on the routing > optimization: as someone explained, there are only two kinds of common > correspondent nodes: web servers, but to deal with routing optimization > with its security, hard state binding cache, etc, is too expensive so > shan't be done, and mobile terminals (handsets, PDAs, (robust) laptops), > the problem is the design team didn't consider this special case (aka > mobile to mobile)... We are trying to save something but most of the > marvellous promises of mobile IPv6 can already be considered as hype. Francis, I don't share you pessimism. I think the claim that there are only two types of CNs that matter for mobile IPv6 (Web servers and mobile terminals) is a bit odd. That is similar to saying that since most of the traffic on the internet is http why don't be build an http network instead of an IP network? The point is that the value of the Internet comes from service/application independence - people can build new services and applications and have them run on the Internet today - no need to upgrade things in the middle to deploy new things. So building a http + voip network is the wrong thing to do and the above statement sounds like it would be the right approach which is why I disagree with it rather strongly. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 11:30:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26302 for ; Thu, 14 Feb 2002 11:30:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19055; Thu, 14 Feb 2002 09:30:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16105; Thu, 14 Feb 2002 08:30:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EGTGKL000586 for ; Thu, 14 Feb 2002 08:29:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EGTGAa000585 for mobile-ip-dist; Thu, 14 Feb 2002 08:29:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EGTCKL000578 for ; Thu, 14 Feb 2002 08:29:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EGTBM14664; Thu, 14 Feb 2002 17:29:11 +0100 (MET) Date: Thu, 14 Feb 2002 17:24:58 +0100 (CET) From: Erik Nordmark Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation To: jari.arkko@kolumbus.fi Cc: Brian Haley USG , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <032701c1b4ac$ec24e4e0$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Don't a lot of firewalls today drop ICMP packets? How is the MN > > supposed to know the CN even got the packet if it's behind one, > > it might just keep retrying, until it eventually stops trying to > > communicate (figures the CN is dead), or falls-back to reverse-tunneling > > through its HA. Good point. But this ICMP error is to handle error cases. If a CN accept a BU with a 2 minute lifetime it should keep it around for that long. Of course, if the CN crashes and reboots it will loose the BCE, and in that error the ICMP error would be sent. So if the ICMP error is only used to signal more or less catastrophic state loss and the maximum lifetime for a binding created using RR-security is a few minutes (in order to minimize the exposure to future bombing attacks) then it seems like we might be able to live with the risk of the firewall blocking the ICMP error? > As an alternative we could also specify a MIPv6 specific message > to say the same thing as the ICMP ;-) which sounds a bit like the > arguments in the RH case. Except this time the fear is ICMP, not > RH. Could Binding Request be used for this purpose, with some flag? Or, instead of overloading the request, specify a new binding nak/reject/error message for MIPv6? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 11:50:29 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27290 for ; Thu, 14 Feb 2002 11:50:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13066; Thu, 14 Feb 2002 09:50:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21664; Thu, 14 Feb 2002 08:49:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EGmlKL000725 for ; Thu, 14 Feb 2002 08:48:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EGmlX5000724 for mobile-ip-dist; Thu, 14 Feb 2002 08:48:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EGmeKL000709; Thu, 14 Feb 2002 08:48:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16453; Thu, 14 Feb 2002 08:48:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19605; Thu, 14 Feb 2002 09:48:41 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1EGmdk17150; Thu, 14 Feb 2002 17:48:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA24312; Thu, 14 Feb 2002 17:48:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1EGmdg18727; Thu, 14 Feb 2002 17:48:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202141648.g1EGmdg18727@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 14 Feb 2002 16:26:34 +0100. Date: Thu, 14 Feb 2002 17:48:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I don't share you pessimism. => I'd prefer to be wrong... I think the claim that there are only two types of CNs that matter for mobile IPv6 (Web servers and mobile terminals) is a bit odd. => this is not my claim but this is clearly the vision of the Internet by many players in Europe (worse in France where the Internet is the super Minitel, brrr...) That is similar to saying that since most of the traffic on the internet is http why don't be build an http network instead of an IP network? => Brian Carpenter argues this can become the future of the Internet. Of course we don't want that, but remember I've begun by "I am pessimistic" and there is somthing named SOAP... The point is that the value of the Internet comes from service/application independence - people can build new services and applications and have them run on the Internet today - no need to upgrade things in the middle to deploy new things. => you don't need to convince me and I'm afraid the folks we should convince don't read these lists. So building a http + voip network is the wrong thing to do and => if you replace http by WAP (not an improvement) this is exactly what they are trying to do (I don't add a smile because this is *not* funny). the above statement sounds like it would be the right approach which is why I disagree with it rather strongly. => there is what we'd like and there is what it is (look better in French)... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:22:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00117 for ; Thu, 14 Feb 2002 12:22:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08714; Thu, 14 Feb 2002 10:22:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23982; Thu, 14 Feb 2002 09:22:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHLAKL000950 for ; Thu, 14 Feb 2002 09:21:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHLA0s000949 for mobile-ip-dist; Thu, 14 Feb 2002 09:21:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHL6KL000942 for ; Thu, 14 Feb 2002 09:21:06 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHL6M20400; Thu, 14 Feb 2002 18:21:06 +0100 (MET) Date: Thu, 14 Feb 2002 18:16:51 +0100 (CET) From: Erik Nordmark Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E020AACD9@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I disagree with this conclusion and I find it very sad indeed that the IETF > has knelt before the link layers. Especially when the link layers won't even > do the route optimization as a mandate. You might was well move the MIP > work to one of the other SDO's if this kind of decision making continues. > > Very very sad indeed. Shame on the DT, IMHO. > There is no technical merit to the DT's conclusion. As such they need to > find some before a vote is done. Glenn, I think the above statements are neither fair, productive, nor get us any closer to getting to rough consensus. That said, the design team is trying to untangle the relationships that involve at least the following factors: - piggybacking or not - how are BU/RR related message carried (using DOs or something else) - using IPsec or something else to secure home registrations - using IPsec (we don't know an alternative) to be able to selectively secure BU/RR messages between the HA and MN - optional use of IPsec between MNs and CNs We were hoping we could try to untangle the above by first asking the chairs to see if there is any WG consensus around piggybacking. So far not many WG participants have commented on the issue (but there is a fair amount of heat and no light). So perhaps we need to tack the whole tangled mess above in one fell swoop. Would that make more sense to you? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:26:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00390 for ; Thu, 14 Feb 2002 12:26:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21424; Thu, 14 Feb 2002 10:26:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24984; Thu, 14 Feb 2002 09:26:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHPnKL001015 for ; Thu, 14 Feb 2002 09:25:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHPneJ001014 for mobile-ip-dist; Thu, 14 Feb 2002 09:25:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHPiKL001007 for ; Thu, 14 Feb 2002 09:25:45 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHPjM20814; Thu, 14 Feb 2002 18:25:45 +0100 (MET) Date: Thu, 14 Feb 2002 18:21:29 +0100 (CET) From: Erik Nordmark Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202131945.g1DJjkg11258@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => yes, I look at the code (I checked with ipf) and the IPv4 option > filter code was translated into an IPv6 header filter code. > IMHO you may insult the authors, this is really laziness! > BTW it seems there will be a good majority for can live with ADA, > agree with RH type 2. This lazyness factor is part of my concern (that others disagree with). There is a risk (how big it is can be debated) that IPv6 firewalls assume that IPv6 routing headers = IPv4 source routing and have a single on/off knob. If we instead have ADA (and HOA) as DOs there are probably going to be IPv6 firewalls that have a single on/off knob for IPv6 destination options. But in that case the firewall implementors, as well as users, might be a tad less likely to have it be turned off by default partly because destination options is new compared to IPv4 and they might actually read something which says destination options is used e.g. for mobile IPv6 and think before disabling it. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:34:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00649 for ; Thu, 14 Feb 2002 12:34:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25630; Thu, 14 Feb 2002 10:34:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27160; Thu, 14 Feb 2002 09:34:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHX7KL001076 for ; Thu, 14 Feb 2002 09:33:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHX7IZ001075 for mobile-ip-dist; Thu, 14 Feb 2002 09:33:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHX3KL001068 for ; Thu, 14 Feb 2002 09:33:04 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHX4M21979; Thu, 14 Feb 2002 18:33:04 +0100 (MET) Date: Thu, 14 Feb 2002 18:28:48 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <00bd01c1b4c7$fc8e99a0$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > If changes are required in IPsec, then I think we ought > to ask for them. How long do you suggest we should delay MIPv6 while waiting for such changes to IPsec specifications? I think Jeff Schiller already pointed out (but I could misremember) that MIPv6 BUs don't fit with the available IPsec selectors which would seem like a hint that we shouldn't expect IPsec to change. So I'm having a hard time seeing how to move forward at the moment. > > (b) We recommend that when IPsec protection is used, it is > > always used in *addition* to RR (or CGA) methods, not as > > a replacement. Thus RR (or CGA) methods would be used to > > protect MN - CN Route optimization procedures even when IPsec > > is used. > > > > DISAGREE. Requring RR for BU security if the BU is between > the MN and an AR or LMM agent in the local foreign network > will have serious performance impact. Requiring just CGA or > something similar would probably have less impact. In any > case, the MN should be able to establish a BSA when it > enters the foreign network and use that to secure any routing > update signaling with entities in the foreign network. I don't think the DT intended to make a statement about how LMM should be secured but instead focus on how MIPv6 should be secured. It might very well be that LMM has both different performance constraints as well as the ability to rely on some infrastructure local to an operator. So apart from the LMM concerns, do you still disagree with the above? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:35:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00697 for ; Thu, 14 Feb 2002 12:35:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12054; Thu, 14 Feb 2002 10:35:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27437; Thu, 14 Feb 2002 09:34:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHXxKL001111 for ; Thu, 14 Feb 2002 09:33:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHXwqm001110 for mobile-ip-dist; Thu, 14 Feb 2002 09:33:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHXtKL001103 for ; Thu, 14 Feb 2002 09:33:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20739 for ; Thu, 14 Feb 2002 09:33:58 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00790 for ; Thu, 14 Feb 2002 09:33:58 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA15461; Thu, 14 Feb 2002 09:33:53 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1EHXq518637; Thu, 14 Feb 2002 09:33:52 -0800 X-mProtect:  Thu, 14 Feb 2002 09:33:52 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRSrkby; Thu, 14 Feb 2002 09:33:50 PST Message-ID: <3C6BF4FE.6F8DE551@iprg.nokia.com> Date: Thu, 14 Feb 2002 09:33:50 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com, gmorrow@nortelnetworks.com Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, Erik Nordmark wrote: > ... the design team is trying to untangle the relationships that > involve at least the following factors: > - piggybacking or not > - how are BU/RR related message carried (using DOs or something else) > - using IPsec or something else to secure home registrations > - using IPsec (we don't know an alternative) to be able to selectively > secure BU/RR messages between the HA and MN > - optional use of IPsec between MNs and CNs > > We were hoping we could try to untangle the above by first asking the chairs > to see if there is any WG consensus around piggybacking. > So far not many WG participants have commented on the issue (but there is > a fair amount of heat and no light). First, I think that we have indeed had a reasonable number of working group members commenting on piggybacking. Without going back and checking, I can remember James Kempf, Glenn Morrow, Hesham Soliman, Behcet Sarikaya, Brian Haley, and Francis Dupont, in addition to members of the design team. That's not bad for a few days discussion. I have tried to be very precise and technical in my discussion about piggybacking. I have set out quite a few technical points (and logical points) that I had hoped would enable further discussion on the matter. Maybe you are over-generalizing, but if you truly feel that my discussion was all heat and no light, then I have to object, and I very much want to ask you to take another look. I tried to avoid the heat syndrome. If I have failed at certain times, then I can try to do better, but I very much believe that my discussion on this point is practically all oriented just towards the technical benefits of piggybacking. Please let me know. Better yet, please let me know your responses to my discussion points on piggybacking. I still owe Francis a reply. > So perhaps we need to tack the whole tangled mess above in one fell swoop. > Would that make more sense to you? I know that you didn't ask me, but I think that we can proceed along the path that has been started, considering the issues separately as much as possible. In the case of piggybacking, this is particularly important, as it should be clearly disentangled from any considerations about security. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:37:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00820 for ; Thu, 14 Feb 2002 12:37:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17709; Thu, 14 Feb 2002 10:37:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28365; Thu, 14 Feb 2002 09:37:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHakKL001200 for ; Thu, 14 Feb 2002 09:36:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHaki0001199 for mobile-ip-dist; Thu, 14 Feb 2002 09:36:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHagKL001192 for ; Thu, 14 Feb 2002 09:36:42 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHagM22325; Thu, 14 Feb 2002 18:36:43 +0100 (MET) Date: Thu, 14 Feb 2002 18:32:27 +0100 (CET) From: Erik Nordmark Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation To: haley@zk3.dec.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202132014.AA03564@dogbert.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > How can the DT recognize there is a *potential* benefit, but decide > to kill piggybacking? Brian, There is a potential benefit it lots of things - I can envision benefits in carry BUs as XML over http (but there might be some disadvantages as well :-) The issue is the engineering tradeoff. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:43:56 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01018 for ; Thu, 14 Feb 2002 12:43:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17278; Thu, 14 Feb 2002 10:43:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29895; Thu, 14 Feb 2002 09:43:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHgYKL001272 for ; Thu, 14 Feb 2002 09:42:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHgYp4001271 for mobile-ip-dist; Thu, 14 Feb 2002 09:42:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHgTKL001264 for ; Thu, 14 Feb 2002 09:42:30 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHgUM23012; Thu, 14 Feb 2002 18:42:30 +0100 (MET) Date: Thu, 14 Feb 2002 18:38:15 +0100 (CET) From: Erik Nordmark Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202132232.g1DMWrg12196@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => mobile to mobile communication with simultaneous movement > (BUs never reach peers until a fallback path though a HA is used). This can actually be avoided as is examplified by BU3WAY - the BU/RR related packets by-pass any binding cache entry on the sending node. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:44:06 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01030 for ; Thu, 14 Feb 2002 12:44:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00931; Thu, 14 Feb 2002 10:43:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29923; Thu, 14 Feb 2002 09:43:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHgfKL001282 for ; Thu, 14 Feb 2002 09:42:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHgfa6001281 for mobile-ip-dist; Thu, 14 Feb 2002 09:42:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHgbKL001274 for ; Thu, 14 Feb 2002 09:42:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04741 for ; Thu, 14 Feb 2002 09:42:40 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16642 for ; Thu, 14 Feb 2002 10:42:40 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 92DE5351E; Thu, 14 Feb 2002 12:42:39 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id D5F88DB0; Thu, 14 Feb 2002 09:42:38 -0800 (PST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1EHgcR17218; Thu, 14 Feb 2002 12:42:38 -0500 (EST) From: Brian Haley USG Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1EHgcb19549; Thu, 14 Feb 2002 12:42:38 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA04610; Thu, 14 Feb 2002 12:42:37 -0500 Message-Id: <200202141742.AA04610@dogbert.zk3.dec.com> To: Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation Date: Thu, 14 Feb 2002 12:42:37 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > Don't a lot of firewalls today drop ICMP packets? > > Good point. > But this ICMP error is to handle error cases. If a CN accept a BU with > a 2 minute lifetime it should keep it around for that long. It should, but it doesn't have to. > Of course, if the CN crashes and reboots it will loose the BCE, > and in that error the ICMP error would be sent. Right, this was the case that came to mind - my CN either crashed or decided to throw-out my binding to create another one. I guess if packets seem to be getting blackholed, the MN just starts reverse-tunneling again, and when it finally gets a response from the CN through the HA-MN tunnel, it knows it needs to send a BU again. Let's document this issue exists with HAOs if the consensus stays on this track of requiring BCEs. > So if the ICMP error is only used to signal more or less catastrophic state > loss and the maximum lifetime for a binding created using RR-security > is a few minutes (in order to minimize the exposure to future bombing attacks) > then it seems like we might be able to live with the risk of the firewall > blocking the ICMP error? Short-lived bindings would certainly lower the risk of this happening. > > As an alternative we could also specify a MIPv6 specific message > > to say the same thing as the ICMP ;-) which sounds a bit like the > > arguments in the RH case. Except this time the fear is ICMP, not > > RH. Could Binding Request be used for this purpose, with some flag? > > Or, instead of overloading the request, specify a new binding nak/reject/error > message for MIPv6? In this case we weren't sending a BU in the packet, just a HAO, so a BNak doesn't seem appropriate. Even a BR doesn't seem right, since it's just another form of the redirect attack. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:45:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01081 for ; Thu, 14 Feb 2002 12:45:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09113; Thu, 14 Feb 2002 09:45:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00223; Thu, 14 Feb 2002 09:44:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHhbKL001318 for ; Thu, 14 Feb 2002 09:43:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHhbgY001317 for mobile-ip-dist; Thu, 14 Feb 2002 09:43:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHhXKL001307 for ; Thu, 14 Feb 2002 09:43:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05135 for ; Thu, 14 Feb 2002 09:43:36 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24410 for ; Thu, 14 Feb 2002 09:43:36 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16049 for ; Thu, 14 Feb 2002 09:43:36 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1EHhZi32295 for ; Thu, 14 Feb 2002 09:43:35 -0800 X-mProtect:  Thu, 14 Feb 2002 09:43:35 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrRsPpe; Thu, 14 Feb 2002 09:43:34 PST Message-ID: <3C6BF746.DAA1103B@iprg.nokia.com> Date: Thu, 14 Feb 2002 09:43:34 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, Erik Nordmark wrote: > This lazyness factor is part of my concern (that others disagree with). > > There is a risk (how big it is can be debated) that IPv6 firewalls > assume that > IPv6 routing headers = IPv4 source routing > and have a single on/off knob. It seems pretty unlikely to me that IPv6 firewall designers, would be on the one hand too lazy to check for another Routing Header type, but at the same time so diligent as to check for a wholly new destination option which is harder to detect, since it would be a particular option within the Destination Options header. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:49:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01167 for ; Thu, 14 Feb 2002 12:49:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20524; Thu, 14 Feb 2002 10:48:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01641; Thu, 14 Feb 2002 09:48:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHlgKL001616 for ; Thu, 14 Feb 2002 09:47:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHlguE001615 for mobile-ip-dist; Thu, 14 Feb 2002 09:47:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHlcKL001608 for ; Thu, 14 Feb 2002 09:47:39 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHlcM23520; Thu, 14 Feb 2002 18:47:39 +0100 (MET) Date: Thu, 14 Feb 2002 18:43:23 +0100 (CET) From: Erik Nordmark Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C6AE681.4060504@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => DISAGREE (R3): this kind of requirement is *not* in the scope > of the mobile-ip WG. It is clearly the job of the IPv6 WG. > The only acceptable thing is a recommendation from the mobile-ip WG > to the IPv6 WG to consider such a requirement for all IPv6 nodes. It would seem to be useful to determine whether we have rough concensus in the MIP WG to mandate this *before* we ask the IPv6 WG (as well as the rest of the IETF community) for their opinions. I take it your DISAGREE in due to the procedural concerns. Do you agree or disagree that the MIP WG should recommend to the IPv6 WG that we think this should be mandatory in all IPv6 nodes? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:51:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01215 for ; Thu, 14 Feb 2002 12:51:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22358; Thu, 14 Feb 2002 10:51:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02456; Thu, 14 Feb 2002 09:51:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHoXKL001717 for ; Thu, 14 Feb 2002 09:50:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHoXTl001716 for mobile-ip-dist; Thu, 14 Feb 2002 09:50:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHoTKL001709 for ; Thu, 14 Feb 2002 09:50:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12832; Thu, 14 Feb 2002 09:50:32 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24908; Thu, 14 Feb 2002 10:50:31 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EHoPV21127; Thu, 14 Feb 2002 11:50:26 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <15N0M1TP>; Thu, 14 Feb 2002 11:50:25 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0210AB33@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Thu, 14 Feb 2002 11:50:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B580.11D66870" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B580.11D66870 Content-Type: text/plain; charset="ISO-8859-1" Erik, We are human and I admit that this was not exactly politically correct but I do think it was constructive criticism. I do agree that we need to focus on the technical aspects at this point and I have certainly tried to in my subsequent contributions to the list. Thanks, Glenn > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Thursday, February 14, 2002 11:17 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com > Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > > > I disagree with this conclusion and I find it very sad > indeed that the IETF > > has knelt before the link layers. Especially when the link > layers won't even > > do the route optimization as a mandate. You might was well > move the MIP > > work to one of the other SDO's if this kind of decision > making continues. > > > > Very very sad indeed. Shame on the DT, IMHO. > > > There is no technical merit to the DT's conclusion. As such > they need to > > find some before a vote is done. > > Glenn, > > I think the above statements are neither fair, productive, > nor get us any > closer to getting to rough consensus. > > That said, the design team is trying to untangle the > relationships that > involve at least the following factors: > - piggybacking or not > - how are BU/RR related message carried (using DOs or something else) > - using IPsec or something else to secure home registrations > - using IPsec (we don't know an alternative) to be able to > selectively > secure BU/RR messages between the HA and MN > - optional use of IPsec between MNs and CNs > > We were hoping we could try to untangle the above by first > asking the chairs > to see if there is any WG consensus around piggybacking. > So far not many WG participants have commented on the issue > (but there is > a fair amount of heat and no light). > > So perhaps we need to tack the whole tangled mess above in > one fell swoop. > Would that make more sense to you? > > Erik > > ------_=_NextPart_001_01C1B580.11D66870 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Erik,

We are human and I admit that this was not exactly = politically correct but I do think it was constructive = criticism.

I do agree that we need to focus on the technical = aspects at this point and I have certainly tried to in my subsequent = contributions to the list.

Thanks,

Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
> Sent: Thursday, February 14, 2002 11:17 = AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking = - DT recommendation]
>
>
> >
> > I disagree with this conclusion and I find = it very sad
> indeed that the IETF
> > has knelt before the link layers. = Especially when the link
> layers won't even
> > do the route optimization as a = mandate.  You might was well
> move the MIP
> > work to one of the other SDO's if this = kind of decision
> making continues.
> >
> > Very very sad indeed. Shame on the DT, = IMHO.
>
> > There is no technical merit to the DT's = conclusion. As such
> they need to
> > find some before a vote is done.
>
> Glenn,
>
> I think the above statements are neither fair, = productive,
> nor get us any
> closer to getting to rough consensus.
>
> That said, the design team is trying to = untangle the
> relationships that
> involve at least the following factors:
>  - piggybacking or not
>  - how are BU/RR related message carried = (using DOs or something else)
>  - using IPsec or something else to secure = home registrations
>  - using IPsec (we don't know an = alternative) to be able to
> selectively
>    secure BU/RR messages between = the HA and MN
>  - optional use of IPsec between MNs and = CNs
>
> We were hoping we could try to untangle the = above by first
> asking the chairs
> to see if there is any WG consensus around = piggybacking.
> So far not many WG participants have commented = on the issue
> (but there is
> a fair amount of heat and no light).
>
> So perhaps we need to tack the whole tangled = mess above in
> one fell swoop.
> Would that make more sense to you?
>
>   Erik
>
>

------_=_NextPart_001_01C1B580.11D66870-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:55:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01330 for ; Thu, 14 Feb 2002 12:55:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27877; Thu, 14 Feb 2002 10:55:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14575; Thu, 14 Feb 2002 09:55:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHsBKL001777 for ; Thu, 14 Feb 2002 09:54:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHsBB6001776 for mobile-ip-dist; Thu, 14 Feb 2002 09:54:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHs7KL001769 for ; Thu, 14 Feb 2002 09:54:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28334; Thu, 14 Feb 2002 09:54:11 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07372; Thu, 14 Feb 2002 10:54:10 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EHs8V22056; Thu, 14 Feb 2002 11:54:08 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8C2A1>; Thu, 14 Feb 2002 11:54:08 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0210AB48@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com Subject: RE: (ISSUE) [mobile-ip] Home Address Option: design team recommen dation Date: Thu, 14 Feb 2002 11:54:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B580.99585970" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B580.99585970 Content-Type: text/plain; charset="iso-8859-1" Shouldn't the CN report the error to the MN's care of address. If it doesn't, wouldn't that still result in a reflector spoofing? Thanks for the clarification, Glenn > -----Original Message----- > From: Brian Haley USG [mailto:haley@zk3.dec.com] > Sent: Thursday, February 14, 2002 11:43 AM > To: Erik.Nordmark@eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team > recommendation > > > > > > Don't a lot of firewalls today drop ICMP packets? > > > > Good point. > > But this ICMP error is to handle error cases. If a CN > accept a BU with > > a 2 minute lifetime it should keep it around for that long. > > It should, but it doesn't have to. > > > Of course, if the CN crashes and reboots it will loose the BCE, > > and in that error the ICMP error would be sent. > > Right, this was the case that came to mind - my CN either crashed or > decided to throw-out my binding to create another one. I guess if > packets seem to be getting blackholed, the MN just starts > reverse-tunneling > again, and when it finally gets a response from the CN > through the HA-MN > tunnel, it knows it needs to send a BU again. > > Let's document this issue exists with HAOs if the consensus stays > on this track of requiring BCEs. > > > So if the ICMP error is only used to signal more or less > catastrophic state > > loss and the maximum lifetime for a binding created using > RR-security > > is a few minutes (in order to minimize the exposure to > future bombing attacks) > > then it seems like we might be able to live with the risk > of the firewall > > blocking the ICMP error? > > Short-lived bindings would certainly lower the risk of this happening. > > > > As an alternative we could also specify a MIPv6 specific message > > > to say the same thing as the ICMP ;-) which sounds a bit like the > > > arguments in the RH case. Except this time the fear is ICMP, not > > > RH. Could Binding Request be used for this purpose, with > some flag? > > > > Or, instead of overloading the request, specify a new > binding nak/reject/error > > message for MIPv6? > > In this case we weren't sending a BU in the packet, just a HAO, so > a BNak doesn't seem appropriate. Even a BR doesn't seem right, since > it's just another form of the redirect attack. > > -Brian > > ------_=_NextPart_001_01C1B580.99585970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (ISSUE) [mobile-ip] Home Address Option: design team = recommendation

Shouldn't the CN report the error to the MN's care of = address. If it doesn't, wouldn't that still result in a reflector = spoofing?

Thanks for the clarification,

Glenn

> -----Original Message-----
> From: Brian Haley USG [mailto:haley@zk3.dec.com]
> Sent: Thursday, February 14, 2002 11:43 = AM
> To: Erik.Nordmark@eng.sun.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: (ISSUE) [mobile-ip] Home Address = Option: design team
> recommendation
>
>
> > > > Don't a lot of firewalls today = drop ICMP packets?
> >
> > Good point.
> > But this ICMP error is to handle error = cases. If a CN
> accept a BU with
> > a 2 minute lifetime it should keep it = around for that long.
>
> It should, but it doesn't have to.
>
> > Of course, if the CN crashes and reboots = it will loose the BCE,
> > and in that error the ICMP error would be = sent.
>
> Right, this was the case that came to mind - my = CN either crashed or
> decided to throw-out my binding to create = another one.  I guess if
> packets seem to be getting blackholed, the MN = just starts
> reverse-tunneling
> again, and when it finally gets a response from = the CN
> through the HA-MN
> tunnel, it knows it needs to send a BU = again.
>
> Let's document this issue exists with HAOs if = the consensus stays
> on this track of requiring BCEs.
>
> > So if the ICMP error is only used to = signal more or less
> catastrophic state
> > loss and the maximum lifetime for a = binding created using
> RR-security
> > is a few minutes (in order to minimize the = exposure to
> future bombing attacks)
> > then it seems like we might be able to = live with the risk
> of the firewall
> > blocking the ICMP error?
>
> Short-lived bindings would certainly lower the = risk of this happening.
>
> > > As an alternative we could also = specify a MIPv6 specific message
> > > to say the same thing as the ICMP ;-) = which sounds a bit like the
> > > arguments in the RH case. Except this = time the fear is ICMP, not
> > > RH. Could Binding Request be used for = this purpose, with
> some flag?
> >
> > Or, instead of overloading the request, = specify a new
> binding nak/reject/error
> > message for MIPv6?
>
> In this case we weren't sending a BU in the = packet, just a HAO, so
> a BNak doesn't seem appropriate.  Even a = BR doesn't seem right, since
> it's just another form of the redirect = attack.
>
> -Brian
>
>

------_=_NextPart_001_01C1B580.99585970-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:55:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01352 for ; Thu, 14 Feb 2002 12:55:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28173; Thu, 14 Feb 2002 10:55:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14656; Thu, 14 Feb 2002 09:55:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHs6KL001767 for ; Thu, 14 Feb 2002 09:54:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHs6gR001766 for mobile-ip-dist; Thu, 14 Feb 2002 09:54:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHs2KL001759 for ; Thu, 14 Feb 2002 09:54:03 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHrvM23850; Thu, 14 Feb 2002 18:53:57 +0100 (MET) Date: Thu, 14 Feb 2002 18:49:41 +0100 (CET) From: Erik Nordmark Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, gmorrow@nortelnetworks.com In-Reply-To: "Your message with ID" <3C6BF4FE.6F8DE551@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I have tried to be very precise and technical in my discussion about > piggybacking. I have set out quite a few technical points (and > logical points) that I had hoped would enable further discussion > on the matter. Maybe you are over-generalizing, but if you truly > feel that my discussion was all heat and no light, then I have to > object, and I very much want to ask you to take another look. Nobody has brought up any new points (well, except perhaps Kempf's point about i-mode using something akin to piggybacking but I don't know if that is a link-layer type thing or an e2e thing) this time around. Thus there is no more light shining on the issue than there was after the last round of discussions. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 12:57:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02397 for ; Thu, 14 Feb 2002 12:57:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26164; Thu, 14 Feb 2002 10:57:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15724; Thu, 14 Feb 2002 09:57:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHuwKL001846 for ; Thu, 14 Feb 2002 09:56:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHuvKc001845 for mobile-ip-dist; Thu, 14 Feb 2002 09:56:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHusKL001838 for ; Thu, 14 Feb 2002 09:56:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09994 for ; Thu, 14 Feb 2002 09:56:58 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01518 for ; Thu, 14 Feb 2002 09:56:56 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1EHuthM001160 for ; Thu, 14 Feb 2002 18:56:55 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Feb 14 18:56:54 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Feb 2002 18:56:15 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803258898@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 18:56:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I'm having a hard time understanding why you disagree since you don't explain. If this topic is just a 'voting' one then I understand your email. The chairs can clarify. Some comments below: > DISAGREE. The tendency in the MIP group in the past > has been to avoid facing up to cases where the properties of > wired networks and wireless networks are different enough > that changes are required to efficiently support IP on > wireless networks. I think this is another such case. => I've tried to show several times that the best way to support MIPv6 signalling on a link with QoS support is to separate the signalling packets form the normal traffic. If anyone thinks this is unreasonable then please explain why. As for links with no QoS: Does it matter? Why? They usually are so overdimensioned that it isn't an issue. > > As I mentioned previously, DoCoMo uses piggybacking > to good effect in i-mode, that indicates to me that it > is likely to be useful. Without further analysis, of course, > it is hard to say how useful and whether the tradeoff > is worth it, => Exactly! imode is a _completely_ different architecture from what we're discussing here. but it is one implementation data point. It has > been mentioned before that Cedric and Charlie's draft > (which I admit to not having read) also lists some possible > benefits of piggypacking. => The only reasons I'm continuing with this is a 'hope' to convert this from a religious argument to a technical one. Your statement above seems to belong to the former. Please read it and consider the earlier discussion and tell us what you think. We know that claims were made, but we need to really analyse and understand these claims and then decide whether we 'believe' in them. > If changes are required in IPsec, then I think we ought > to ask for them. => I'm not sure about the practicality of that option. > > > (b) We recommend that when IPsec protection is used, it is > > always used in *addition* to RR (or CGA) methods, not as > > a replacement. Thus RR (or CGA) methods would be used to > > protect MN - CN Route optimization procedures even when IPsec > > is used. > > > > DISAGREE. Requring RR for BU security if the BU is between > the MN and an AR or LMM agent in the local foreign network > will have serious performance impact. Requiring just CGA or > something similar would probably have less impact. In any > case, the MN should be able to establish a BSA when it > enters the foreign network and use that to secure any routing > update signaling with entities in the foreign network. => A BSA would only exist if an appropriate mechanism was used. I think that can be done with RR+CGA. Just because you have an IPsec SA, doesn't mean you are authorised to send the BU. It's an address ownership problem and that's why we need RR. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 13:01:13 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02551 for ; Thu, 14 Feb 2002 13:01:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13641; Thu, 14 Feb 2002 10:00:58 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17116; Thu, 14 Feb 2002 10:00:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHxxKL001938 for ; Thu, 14 Feb 2002 09:59:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EHxxkp001937 for mobile-ip-dist; Thu, 14 Feb 2002 09:59:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EHxsKL001930 for ; Thu, 14 Feb 2002 09:59:55 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EHxtM24411; Thu, 14 Feb 2002 18:59:56 +0100 (MET) Date: Thu, 14 Feb 2002 18:55:40 +0100 (CET) From: Erik Nordmark Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C6BF746.DAA1103B@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Hello Erik, > It seems pretty unlikely to me that IPv6 firewall designers, > would be on the one hand too lazy to check for another Routing > Header type, but at the same time so diligent as to check for > a wholly new destination option which is harder to detect, > since it would be a particular option within the Destination > Options header. I certainly didn't mean to imply that the firewall know about individual destination options but I see my writing wasn't very exact. I meant to say that the firewall knows about the destination options header type and it might just have a single on/off knob for that header. A firewall needs this and it probably needs to be able to look at the header (tcp, udp, whatever) that comes after the destination options header as well. Does that make more sense? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 13:02:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03113 for ; Thu, 14 Feb 2002 13:02:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02578; Thu, 14 Feb 2002 11:02:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17716; Thu, 14 Feb 2002 10:02:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EI1aKL001986 for ; Thu, 14 Feb 2002 10:01:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EI1Zds001985 for mobile-ip-dist; Thu, 14 Feb 2002 10:01:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EI1VKL001974 for ; Thu, 14 Feb 2002 10:01:32 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EI1WM24666; Thu, 14 Feb 2002 19:01:32 +0100 (MET) Date: Thu, 14 Feb 2002 18:57:16 +0100 (CET) From: Erik Nordmark Subject: RE: (ISSUE) [mobile-ip] Home Address Option: design team recommen dation To: Glenn Morrow Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E0210AB48@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Shouldn't the CN report the error to the MN's care of address. If it > doesn't, wouldn't that still result in a reflector spoofing? Yes, any such error needs to be sent to the source address which would be the CoA in this case. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 13:05:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04482 for ; Thu, 14 Feb 2002 13:05:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14207; Thu, 14 Feb 2002 11:05:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18999; Thu, 14 Feb 2002 10:05:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EI4PKL002040 for ; Thu, 14 Feb 2002 10:04:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EI4ORb002039 for mobile-ip-dist; Thu, 14 Feb 2002 10:04:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EI4KKL002032 for ; Thu, 14 Feb 2002 10:04:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EI4LM25069; Thu, 14 Feb 2002 19:04:21 +0100 (MET) Date: Thu, 14 Feb 2002 19:00:06 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <01f301c1b4e1$0bb7a2f0$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The i-mode network piggybacks signalling with data traffic, > specifically with HTTP. What I intended to say is that > this is one data point that piggybacking is useful for radio > networks. That's all I intended to say. Jim, Do you know if this piggybacking is end-to-end in the i-mode network i.e. the signalling is delivered to the http server? Or do they just share the same packet over the radio link with the signalling message being delivered to some other entity? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 13:48:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05878 for ; Thu, 14 Feb 2002 13:48:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06705; Thu, 14 Feb 2002 11:48:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06837; Thu, 14 Feb 2002 10:48:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EIlJKL002229 for ; Thu, 14 Feb 2002 10:47:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EIlJT7002228 for mobile-ip-dist; Thu, 14 Feb 2002 10:47:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EIlFKL002221 for ; Thu, 14 Feb 2002 10:47:16 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1EIlEM29652; Thu, 14 Feb 2002 19:47:14 +0100 (MET) Date: Thu, 14 Feb 2002 19:42:59 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: vijayd@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C6AB6E4.3080505@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Additional signaling, of course. If an IPSec SA were enough, > I wouldnt want to do RR messages, especially during a handoff. > This is a big gain (not having to do RR, whenever possible). > > Also another reason why I objected was, this is a piggybacking > recommendation. Why does a piggybacking recommendation have > to say that IPSec SA would never be enough and should be used > always in addition to RR. Shouldnt we take that up separately? I agree it would have been better to keep that separately. > Now something about the IPSec SA itself. > > If the IPSec SA were created by AAA, PKI or some future > infrastructure method, I think it would be enough for > securing the BUs without having to do RR. And I also see > a static SA created between my MN and my friend's MN very > realistic and possible. It depends on what authority you associate with the IPsec SA i.e. the policy associated with it. If your are associated with some certificate authority that you trust and that CA signs a certificate for attacks-r-us.example.com (after verifying that such an entity in fact exists and is legit) does that mean that a CN should accept BUs arriving over a SA that was created using the above certificate? Does it mean that the CN should accept it for the Home Address of my laptop? Of course not. So the HA-MN use of IPsec is easy because part of the configuration on the HA (when using IKE a certificates in this example, which isn't required in general) could be to associate the home address with a certificate. This could be done by as part of the configuration of the relationship on the HA i.e. certificate name nordmark@eng.sun.com can do BUs for 1:2:3::220:afff:fe8d:b2d6 And the same relationship can be manually created on a few select CNs, but it doesn't scale doing this for a large number of CNs. So this is the motivation for saying that in general IPsec need to be used in addition to RR. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 13:57:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06178 for ; Thu, 14 Feb 2002 13:57:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27387; Thu, 14 Feb 2002 10:57:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19133; Thu, 14 Feb 2002 10:57:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EIuAKL002309 for ; Thu, 14 Feb 2002 10:56:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EIuAXH002308 for mobile-ip-dist; Thu, 14 Feb 2002 10:56:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EIu6KL002301 for ; Thu, 14 Feb 2002 10:56:06 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20941 for ; Thu, 14 Feb 2002 10:56:08 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29385 for ; Thu, 14 Feb 2002 10:56:07 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EIw0Q18918 for ; Thu, 14 Feb 2002 12:58:00 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 12:56:06 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 12:56:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 12:56:05 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12700@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Piggybacking - DT recommendation Thread-Index: AcG1fcyQMH+wyRIpRnCrRVwxN0uFYgAC2vpQ To: , X-OriginalArrivalTime: 14 Feb 2002 18:56:06.0198 (UTC) FILETIME=[41C9DD60:01C1B589] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1EIu7KL002302 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit >Jim, > >> If changes are required in IPsec, then I think we ought >> to ask for them. > We can ask for whatever we want, but at the expense of having a dependency on getting the MIPv6 spec, which could then be stretched out for a much longer time. >How long do you suggest we should delay MIPv6 while waiting for such changes >to IPsec specifications? I think we (thanks to the DT efforts) have a very good possibility of geting the MIPv6 spec done by the next IETF (optimistically :) Hence I would be very much opposed to asking the IPsec WG to make changes to the specs. > >I think Jeff Schiller already pointed out (but I could misremember) >that MIPv6 BUs don't fit with the available IPsec selectors which would seem >like a hint that we shouldn't expect IPsec to change. >So I'm having a hard time seeing how to move forward at the moment. > I remember similar suggestions from Jeff. I do believe that one of the ground rules we set forth for the DT was to not expect IPsec to make changes. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:01:36 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06438 for ; Thu, 14 Feb 2002 14:01:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13646; Thu, 14 Feb 2002 12:01:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20159; Thu, 14 Feb 2002 11:01:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJ0JKL002405 for ; Thu, 14 Feb 2002 11:00:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJ0Jse002404 for mobile-ip-dist; Thu, 14 Feb 2002 11:00:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJ0GKL002397 for ; Thu, 14 Feb 2002 11:00:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26443; Thu, 14 Feb 2002 11:00:18 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08997; Thu, 14 Feb 2002 11:00:17 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EJ0He16846; Thu, 14 Feb 2002 11:00:17 -0800 (PST) Message-ID: <015f01c1b589$9ed9b7a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 10:58:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > > > If changes are required in IPsec, then I think we ought > > to ask for them. > > How long do you suggest we should delay MIPv6 while waiting for such changes > to IPsec specifications? > If we don't start now, it will take even longer to get the change. I don't understand why we couldn't simply allow piggybacking with the caveat that you shouldn't use it with IPSec, then start working with the IPSec group to come up with a solution that will work. The MN doesn't have to send the BU as part of an IPSec secured TCP stream, it could send it separately. > I think Jeff Schiller already pointed out (but I could misremember) > that MIPv6 BUs don't fit with the available IPsec selectors which would seem > like a hint that we shouldn't expect IPsec to change. > So I'm having a hard time seeing how to move forward at the moment. > Sorry, since I wasn't part of the DT, I'm not up on the specifics of this. What is the problem with simply specifying that the BU header is within the authenticated or encrypted part of the packet covered by the AH or ESP header? > > > (b) We recommend that when IPsec protection is used, it is > > > always used in *addition* to RR (or CGA) methods, not as > > > a replacement. Thus RR (or CGA) methods would be used to > > > protect MN - CN Route optimization procedures even when IPsec > > > is used. > > > > > > > DISAGREE. Requring RR for BU security if the BU is between > > the MN and an AR or LMM agent in the local foreign network > > will have serious performance impact. Requiring just CGA or > > something similar would probably have less impact. In any > > case, the MN should be able to establish a BSA when it > > enters the foreign network and use that to secure any routing > > update signaling with entities in the foreign network. > > I don't think the DT intended to make a statement about how LMM should > be secured but instead focus on how MIPv6 should be secured. > It might very well be that LMM has both different performance constraints > as well as the ability to rely on some infrastructure local to > an operator. So apart from the LMM concerns, do you still disagree with > the above? > I can't see any problem with it in general, just with respect to LMM solutions that depend on route optimization. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:09:05 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06692 for ; Thu, 14 Feb 2002 14:09:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17589; Thu, 14 Feb 2002 12:08:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22076; Thu, 14 Feb 2002 11:08:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJ7lKL002469 for ; Thu, 14 Feb 2002 11:07:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJ7lN3002468 for mobile-ip-dist; Thu, 14 Feb 2002 11:07:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJ7iKL002461 for ; Thu, 14 Feb 2002 11:07:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13854 for ; Thu, 14 Feb 2002 11:07:46 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06838 for ; Thu, 14 Feb 2002 12:07:45 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EJ7je17229 for ; Thu, 14 Feb 2002 11:07:45 -0800 (PST) Message-ID: <018c01c1b58a$a99e6950$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053803258898@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 11:06:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > => I've tried to show several times that the best > way to support MIPv6 signalling on a link with > QoS support is to separate the signalling packets > form the normal traffic. If anyone thinks > this is unreasonable then please explain why. > Sure, radio links would all work *much* better if we got to use a special channel for IP signaling. Maybe someday this will happen, but the fact of the matter is, today it doesn't. > As for links with no QoS: Does it matter? > Why? They usually are so overdimensioned that > it isn't an issue. > Not on the radio. > => A BSA would only exist if an appropriate mechanism > was used. I think that can be done with RR+CGA. > Just because you have an IPsec SA, doesn't mean you > are authorised to send the BU. It's an address > ownership problem and that's why we need RR. > How long do you think a handover would take if the MN had to do RR in order to update a binding at a MAP? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:11:42 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06761 for ; Thu, 14 Feb 2002 14:11:41 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01172; Thu, 14 Feb 2002 11:11:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22941; Thu, 14 Feb 2002 11:11:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJAQKL002513 for ; Thu, 14 Feb 2002 11:10:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJAQlq002512 for mobile-ip-dist; Thu, 14 Feb 2002 11:10:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJANKL002505 for ; Thu, 14 Feb 2002 11:10:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22646 for ; Thu, 14 Feb 2002 11:10:25 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08249 for ; Thu, 14 Feb 2002 12:10:24 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EJANe17373; Thu, 14 Feb 2002 11:10:23 -0800 (PST) Message-ID: <019a01c1b58b$07c7f0f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 11:08:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Do you know if this piggybacking is end-to-end in the i-mode network > i.e. the signalling is delivered to the http server? > Or do they just share the same packet over the radio link with > the signalling message being delivered to some other entity? > The signaling is delivered to the i-mode server which is a proxy that converts the HTTP message from the proprietary TCP-like protocol that is optimized for PDC into regular TCP. I don't know if the signaling is used by the i-mode server or not, but it is certainly not used by the IP network. If you want, I can try to find out more details. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:16:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06901 for ; Thu, 14 Feb 2002 14:16:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11787; Thu, 14 Feb 2002 12:16:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24026; Thu, 14 Feb 2002 11:16:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJEkKL002566 for ; Thu, 14 Feb 2002 11:14:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJEks0002565 for mobile-ip-dist; Thu, 14 Feb 2002 11:14:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJEiKL002558 for ; Thu, 14 Feb 2002 11:14:44 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18536 for ; Thu, 14 Feb 2002 14:14:46 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA29795 for mobile-ip@sunroof.eng.sun.com; Thu, 14 Feb 2002 14:15:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1E6fCKL028629 for ; Wed, 13 Feb 2002 22:41:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA00183 for ; Wed, 13 Feb 2002 22:41:14 -0800 (PST) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09253 for ; Wed, 13 Feb 2002 23:41:14 -0700 (MST) Received: from user-11206b8.dsl.mindspring.com ([66.32.25.104] helo=arc.nasa.gov) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16bFZx-0003aj-00; Thu, 14 Feb 2002 01:41:13 -0500 Message-ID: <3C6B5CA0.1070400@arc.nasa.gov> Date: Wed, 13 Feb 2002 22:43:44 -0800 From: Jerry Toung User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: =?EUC-KR?B?v8C47civ?= Subject: Re: [mobile-ip] Looking for mobile-ip sources.. References: <004101c1b4ff$0c7292e0$442ebca8@ce.cnu.ac.kr> Content-Type: multipart/alternative; boundary="------------000707080005080507080300" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------000707080005080507080300 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit This should get you started: http://www.sfc.wide.ad.jp/InternetCAR http://www.cs.hut.fi/Research/Dynamics/software.html http://comet.columbia.edu/micromobility/ ¿À¸íȯ wrote: > Hello there. > I'm a student, studying the mobile-ip related works. > I've been trying to find moible-ip related sources. but I couldn't > find proper one. > I'm looking for MIP source including 'ROUTE OPIMIZATION'. > If there were anybody who has MIP-route optimized source or knows > where i could find that, > Could you give me some information about it? > Thanks for your patience and I hope i could get your help :p > > -------------------------------------------------------------- > Myoung-Hwan Oh. > Graduate Student Distributed System Lab. > Department of Computer Engineering, Chungnam National University > 220 Kung Dong, Taejon 305764, Korea > TEL:+82-42-823-6049 FAX:+82-42-822-4997 > E-mail: mhoh@ce.cnu.ac.kr > > --------------000707080005080507080300 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 8bit This should get you started:
http://www.sfc.wide.ad.jp/InternetCAR

http://www.cs.hut.fi/Research/Dynamics/software.html


http://comet.columbia.edu/micromobility/


¿À¸íȯ wrote:
Hello there.
I'm a student, studying the mobile-ip related works.
I've been trying to find moible-ip related sources. but I couldn't find proper one.
I'm looking for MIP source including 'ROUTE OPIMIZATION'.
If there were anybody who has MIP-route optimized source or knows where i could find that,
Could you give me some information about it?
Thanks for your patience and I hope i could get your help :p
 
 
 
--------------------------------------------------------------
Myoung-Hwan Oh.
Graduate Student Distributed System Lab.
Department of Computer Engineering, Chungnam National University
220 Kung Dong, Taejon 305764, Korea
TEL:+82-42-823-6049 FAX:+82-42-822-4997
E-mail: mhoh@ce.cnu.ac.kr
 

 

--------------000707080005080507080300-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:31:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07497 for ; Thu, 14 Feb 2002 14:31:26 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19277; Thu, 14 Feb 2002 12:31:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28022; Thu, 14 Feb 2002 11:31:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJTZKL002817 for ; Thu, 14 Feb 2002 11:29:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJTZna002816 for mobile-ip-dist; Thu, 14 Feb 2002 11:29:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJTWKL002809 for ; Thu, 14 Feb 2002 11:29:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03642; Thu, 14 Feb 2002 11:29:34 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03667; Thu, 14 Feb 2002 12:29:32 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EJTUV28036; Thu, 14 Feb 2002 13:29:30 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H22CRF>; Thu, 14 Feb 2002 13:29:30 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0210ADA6@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark , "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Thu, 14 Feb 2002 13:29:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B58D.EA94EFD0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B58D.EA94EFD0 Content-Type: text/plain; charset="iso-8859-1" Actually there is something new - some proposed decisions of the other DTs. Apparently some have found that this proposed decison is somehow being use to say we can't do piggybacking. I suggest that people may not understand exactly what this reasoning is and that the persons who believe in this excuse not to do piggybacking detail, with a precise and hopefully concise example, the exact scenario they are thinking of. They need to answer the question of "why do you need a BSA to use piggybacking?". I have also seen euphemisms such as "this makes me sick", etc.. referenced by IPv6 WG members to whom it is well known that they do not see value in MIP anyway much less RO'd MIP. While this could also be seen as constructive criticism, I believe or rather hope, that the persons on this mail list do see value in it and the "sick" reference refers to the persons inability to see value in MIP itself, let alone the piggybacking and Route Optimization. The fact that the security PDU portions of a binding are no longer associated with IPSEC, allows piggybacking to work and makes the technical portion of the arguments against piggybacking false. So it seems to me that there is no true technical excuse for not allowing piggybacking and I can only infer logically that some deal making has been done in order to progress the standard on some sort of deadline self-imposed by some conflicting external SDOs. This prompted my initial criticism in that I wanted to remind people that this is the IETF and we are supposed to deal with the IP problem space - not the least common denominator link layer. I hope you see this as constructive and not a bantor. Thanks, Glenn > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Thursday, February 14, 2002 11:50 AM > To: Charles E. Perkins > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com; Morrow, Glenn > [RICH2:C330:EXCH] > Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > > I have tried to be very precise and technical in my discussion about > > piggybacking. I have set out quite a few technical points (and > > logical points) that I had hoped would enable further discussion > > on the matter. Maybe you are over-generalizing, but if you truly > > feel that my discussion was all heat and no light, then I have to > > object, and I very much want to ask you to take another look. > > Nobody has brought up any new points (well, except perhaps > Kempf's point > about i-mode using something akin to piggybacking but I don't know > if that is a link-layer type thing or an e2e thing) this time around. > > Thus there is no more light shining on the issue than there was > after the last round of discussions. > > Erik > > > ------_=_NextPart_001_01C1B58D.EA94EFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Actually there is something new - some proposed = decisions of the other DTs. Apparently some have found that this = proposed decison is somehow being use to say we can't do = piggybacking.

I suggest that people may not understand exactly what = this reasoning is and that the persons who believe in this excuse not = to do piggybacking detail, with a precise and hopefully concise = example, the exact scenario they are thinking of. They need to answer = the question of "why do you need a BSA to use = piggybacking?".

I have also seen euphemisms such as "this makes = me sick", etc.. referenced by IPv6 WG members to whom it is well = known that they do not see value in MIP anyway much less RO'd MIP. = While this could also be seen as constructive criticism, I believe or = rather hope, that the persons on this mail list do see value in it and = the "sick" reference refers to the persons inability to see = value in MIP itself, let alone the piggybacking and Route Optimization. = The fact that the security PDU portions of a binding are no longer = associated with IPSEC, allows piggybacking to work and makes the = technical portion of the arguments against piggybacking = false.

So it seems to me that there is no true technical = excuse for not allowing piggybacking and I can only infer logically = that some deal making has been done in order to progress the standard = on some sort of deadline self-imposed by some conflicting external = SDOs. This prompted my initial criticism in that I wanted to remind = people that this is the IETF and we are supposed to deal with the IP = problem space - not the least common denominator link layer.

I hope you see this as constructive and not a = bantor.

Thanks,

Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
> Sent: Thursday, February 14, 2002 11:50 = AM
> To: Charles E. Perkins
> Cc: Erik Nordmark; = mobile-ip@sunroof.eng.sun.com; Morrow, Glenn
> [RICH2:C330:EXCH]
> Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking = - DT recommendation]
>
>
>
> > I have tried to be very precise and = technical in my discussion about
> > piggybacking.  I have set out quite a = few technical points (and
> > logical points) that I had hoped would = enable further discussion
> > on the matter.  Maybe you are = over-generalizing, but if you truly
> > feel that my discussion was all heat and = no light, then I have to
> > object, and I very much want to ask you to = take another look.
>
> Nobody has brought up any new points (well, = except perhaps
> Kempf's point
> about i-mode using something akin to = piggybacking but I don't know
> if that is a link-layer type thing or an e2e = thing) this time around.
>
> Thus there is no more light shining on the = issue than there was
> after the last round of discussions.
>
>   Erik
>
>
>

------_=_NextPart_001_01C1B58D.EA94EFD0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:32:33 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07580 for ; Thu, 14 Feb 2002 14:32:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19956; Thu, 14 Feb 2002 12:32:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28389; Thu, 14 Feb 2002 11:32:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJVFKL002844 for ; Thu, 14 Feb 2002 11:31:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJVFRO002839 for mobile-ip-dist; Thu, 14 Feb 2002 11:31:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJUvKL002832 for ; Thu, 14 Feb 2002 11:30:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05011 for ; Thu, 14 Feb 2002 11:31:00 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21533 for ; Thu, 14 Feb 2002 11:30:59 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24486; Thu, 14 Feb 2002 11:30:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1EJUwN02470; Thu, 14 Feb 2002 11:30:58 -0800 X-mProtect:  Thu, 14 Feb 2002 11:30:58 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdG0POmu; Thu, 14 Feb 2002 11:30:56 PST Message-ID: <3C6C1070.17B532B3@iprg.nokia.com> Date: Thu, 14 Feb 2002 11:30:56 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Erik Nordmark , James Kempf Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <015f01c1b589$9ed9b7a0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, James Kempf wrote: > If we don't start now, it will take even longer to get the change. I > don't > understand why we couldn't simply allow piggybacking > with the caveat that you shouldn't use it with IPSec, then start > working with the IPSec group to come up with a solution that will work. > The MN doesn't have to send the BU as part of an IPSec secured > TCP stream, it could send it separately. I think this is a very realistic answer, which I fully support. Since it provides what everyone wants, I think it is the consensus-building approach, and should be endorsed by the design team. > Sorry, since I wasn't part of the DT, I'm not up on the specifics of > this. What is the problem with simply specifying that the BU header > is within the authenticated or encrypted part of the packet covered > by the AH or ESP header? If the payload requires a different security policy than the Binding Update authentication, then the BU can include the Binding Authentication Data suboption, and all is well. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:39:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07692 for ; Thu, 14 Feb 2002 14:39:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21226; Thu, 14 Feb 2002 12:39:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08186; Thu, 14 Feb 2002 11:38:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJc0KL002969 for ; Thu, 14 Feb 2002 11:38:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJc0Yw002968 for mobile-ip-dist; Thu, 14 Feb 2002 11:38:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJbvKL002961 for ; Thu, 14 Feb 2002 11:37:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29897 for ; Thu, 14 Feb 2002 11:37:59 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22761 for ; Thu, 14 Feb 2002 12:37:58 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EJbve18614 for ; Thu, 14 Feb 2002 11:37:57 -0800 (PST) Message-ID: <021b01c1b58e$e20ef8a0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <697DAA22C5004B4596E033803A7CEF44A12700@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 11:36:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Raj, > >> If changes are required in IPsec, then I think we ought > >> to ask for them. > > > > We can ask for whatever we want, but at the expense of having a > dependency on getting the MIPv6 spec, which could then be stretched out > for a much longer time. > Would it not be possible to put some MUSTs in the RFC stating how piggybacking should be used and how not? > >How long do you suggest we should delay MIPv6 while waiting for such changes > >to IPsec specifications? > > I think we (thanks to the DT efforts) have a very good possibility of > geting the MIPv6 spec done by the next IETF (optimistically :) > Hence I would be very much opposed to asking the IPsec WG to make > changes to the specs. > I certainly agree, and I'm sorry if Erik and others felt I was making a religious argument, I wasn't trying to. I feel the design team has done an excellent job with a hard topic, and I have been most encouraged about the quality of the technical discussion. I really wish we could get that quality on other mailing lists that I'm on. And, I was not proposing that we wait on the IPSec WG to complete their work. > > > >I think Jeff Schiller already pointed out (but I could misremember) > >that MIPv6 BUs don't fit with the available IPsec selectors which would seem > >like a hint that we shouldn't expect IPsec to change. > >So I'm having a hard time seeing how to move forward at the moment. > > > > I remember similar suggestions from Jeff. I do believe that one of the > ground rules we set forth for the DT was to not expect IPsec to make > changes. > Ever? Or just prior to taking MIPv6 to RFC? Would Jeff be open to explicit MUSTs and MUST NOTs that limited how piggybacking could be used with IPSec, until a better solution can be worked out? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:50:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07929 for ; Thu, 14 Feb 2002 14:50:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08654; Thu, 14 Feb 2002 12:50:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12348; Thu, 14 Feb 2002 11:50:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJkPKL003045 for ; Thu, 14 Feb 2002 11:46:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJkPDW003043 for mobile-ip-dist; Thu, 14 Feb 2002 11:46:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJkMKL003035 for ; Thu, 14 Feb 2002 11:46:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08228 for ; Thu, 14 Feb 2002 11:46:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24175 for ; Thu, 14 Feb 2002 11:46:23 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA25575; Thu, 14 Feb 2002 11:46:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1EJkIT26963; Thu, 14 Feb 2002 11:46:18 -0800 X-mProtect:  Thu, 14 Feb 2002 11:46:18 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWWYrgL; Thu, 14 Feb 2002 11:46:17 PST Message-ID: <3C6C1409.A0203AEE@iprg.nokia.com> Date: Thu, 14 Feb 2002 11:46:17 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <200202140005.g1E05Sg12722@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Francis, First, I would like to see if you have responses to the discussion points I raised on this recommendation. Francis Dupont wrote: > => for quick comments before reading the 35 other messages of the thread! I am also stumbling under this burden. > => I wrote and presented at the last IETF a generalize multi-payload > proposal for IPv6 (draft-dupont-ipv6-payload-00.txt) in order to > get opinions from the IPv6 folk (they were no, kill that, I become sick, > etc). There are crucial differences between the generalized approach, and the existing approach: - The existing approach does not introduce any new IPv6 features other than what is needed to process the specific Destination Option. Approaches using IPv6 extension headers that specifically prevent piggybacking will, essentially, have to block this generally useful feature. - Your point here is not against Binding Update + payload specifically, but against generalized multi-payloads. The problems with multi-payloads are not particularly applicable to Binding Update + payload. Thus, I think this counts as a straw-man argument. However, I do agree that your points are valid otherwise, and that there is work that should eventually be done in order to have a multi-payload option. - Binding Updates are NOT just any old piece of packet data. They are crucial for correct operation of Mobile IPv6, which is a network-layer protocol. Thus, they belong to be as part of IP processing, and that makes them into IP options, which by IPv6 design are quite amenable to being sent along with payload. > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. > > => AGREE (you may not put two things in the same packet when policies > for the two things can be different. IPsec is just an example > of this basic problem). This really amounts to a statement that the security policies may be different. That problem is already solved by use of the Binding Authentication Data suboption. > 2. Specify that piggybacking always be an option. > > => DISAGREE > > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > > => DISAGREE: this argument only proves the piggy-backing "optimization" > should be done by the link-layer. Since the nature of the improvements do not depend on the link-layer (only the percentage improvement), I do not think this is a fair characterization. I hope this is enough to begin a small dialogue with you on the mailing list. Perhaps we can come to agreement. Perhaps you will agree that it is O.K. to allow some senders to do the piggybacking, as long as we don't mandate it for all senders! I will be interested to also see your comments on my previous mail, if you have time to make comments. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:52:56 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07992 for ; Thu, 14 Feb 2002 14:52:56 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11245; Thu, 14 Feb 2002 11:52:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13358; Thu, 14 Feb 2002 11:52:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJpcKL003112 for ; Thu, 14 Feb 2002 11:51:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJpcDX003111 for mobile-ip-dist; Thu, 14 Feb 2002 11:51:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJpYKL003101 for ; Thu, 14 Feb 2002 11:51:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12978 for ; Thu, 14 Feb 2002 11:51:37 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15216 for ; Thu, 14 Feb 2002 12:51:35 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EJpWV04399; Thu, 14 Feb 2002 13:51:32 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CJP1>; Thu, 14 Feb 2002 13:51:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0210AE3C@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , James Kempf Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 13:51:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B591.00426080" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B591.00426080 Content-Type: text/plain; charset="iso-8859-1" I agree too. > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, February 14, 2002 1:31 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Erik Nordmark; James Kempf > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > Hello folks, > > James Kempf wrote: > > > If we don't start now, it will take even longer to get the change. I > > don't > > understand why we couldn't simply allow piggybacking > > with the caveat that you shouldn't use it with IPSec, then start > > working with the IPSec group to come up with a solution > that will work. > > The MN doesn't have to send the BU as part of an IPSec secured > > TCP stream, it could send it separately. > > I think this is a very realistic answer, which I fully support. > Since it provides what everyone wants, I think it is the > consensus-building approach, and should be endorsed by the > design team. > > > Sorry, since I wasn't part of the DT, I'm not up on the specifics of > > this. What is the problem with simply specifying that the BU header > > is within the authenticated or encrypted part of the packet covered > > by the AH or ESP header? > > If the payload requires a different security policy than the > Binding Update authentication, then the BU can include the > Binding Authentication Data suboption, and all is well. > > > Regards, > Charlie P. > ------_=_NextPart_001_01C1B591.00426080 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Piggybacking - DT recommendation

I agree too.

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Thursday, February 14, 2002 1:31 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Erik Nordmark; James Kempf
> Subject: Re: [mobile-ip] Piggybacking - DT recommendation
>
>
> Hello folks,
>
> James Kempf wrote:
>
> > If we don't start now, it will take even longer to get the change. I
> > don't
> > understand why we couldn't simply allow piggybacking
> > with the caveat that you shouldn't use it with IPSec, then start
> > working with the IPSec group to come up with a solution
> that will work.
> > The MN doesn't have to send the BU as part of an IPSec secured
> > TCP stream, it could send it separately.
>
> I think this is a very realistic answer, which I fully support.
> Since it provides what everyone wants, I think it is the
> consensus-building approach, and should be endorsed by the
> design team.
>
> > Sorry, since I wasn't part of the DT, I'm not up on the specifics of
> > this. What is the problem with simply specifying that the BU header
> > is within the authenticated or encrypted part of the packet covered
> > by the AH or ESP header?
>
> If the payload requires a different security policy than the
> Binding Update authentication, then the BU can include the
> Binding Authentication Data suboption, and all is well.
>
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C1B591.00426080-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 14:53:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08044 for ; Thu, 14 Feb 2002 14:53:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28452; Thu, 14 Feb 2002 12:53:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13727; Thu, 14 Feb 2002 11:53:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJp2KL003080 for ; Thu, 14 Feb 2002 11:51:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EJp2hY003079 for mobile-ip-dist; Thu, 14 Feb 2002 11:51:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EJoxKL003072 for ; Thu, 14 Feb 2002 11:50:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03001 for ; Thu, 14 Feb 2002 11:51:01 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27019 for ; Thu, 14 Feb 2002 12:51:01 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id <1L6R3GVG>; Thu, 14 Feb 2002 14:44:38 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark , "Charles E. Perkins" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Thu, 14 Feb 2002 14:44:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B590.093EFAC8" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B590.093EFAC8 Content-Type: text/plain seems to me that there is no true technical excuse for not allowing piggybacking and I can only infer logically that some deal making has been done Wow. in order to progress the standard on some sort of deadline self-imposed by some conflicting external SDOs. This prompted my initial criticism in that I wanted to remind people that this is the IETF and we are supposed to deal with the IP problem space - not the least common denominator link layer. Just to play devil's advocate - isn't the need for piggybacking tied to a particular kind of link-layer (low bandwidth but with enough headroom to stick in a few more bytes)? Just curious. I hope you see this as constructive and not a bantor. That is difficult for some parts of your message. Thanks, Glenn > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com ] > Sent: Thursday, February 14, 2002 11:50 AM > To: Charles E. Perkins > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com; Morrow, Glenn > [RICH2:C330:EXCH] > Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > > I have tried to be very precise and technical in my discussion about > > piggybacking. I have set out quite a few technical points (and > > logical points) that I had hoped would enable further discussion > > on the matter. Maybe you are over-generalizing, but if you truly > > feel that my discussion was all heat and no light, then I have to > > object, and I very much want to ask you to take another look. > > Nobody has brought up any new points (well, except perhaps > Kempf's point > about i-mode using something akin to piggybacking but I don't know > if that is a link-layer type thing or an e2e thing) this time around. > > Thus there is no more light shining on the issue than there was > after the last round of discussions. > > Erik > > > ------_=_NextPart_001_01C1B590.093EFAC8 Content-Type: text/html Message
 
seems to me that there is no true technical excuse for not allowing piggybacking and I can only infer logically that some deal making has been done 
 
Wow.
 
  in order to progress the standard on some sort of deadline self-imposed by some conflicting external SDOs. This prompted my initial criticism in that I wanted to remind people that this is the IETF and we are supposed to deal with the IP problem space - not the least common denominator link layer. 
 
Just to play devil's advocate - isn't the need for piggybacking tied to a particular kind of link-layer (low bandwidth but with enough
headroom to stick in a few more bytes)?  Just curious.
 

I hope you see this as constructive and not a bantor.  

That is difficult for some parts of your message. 

Thanks,

Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> Sent: Thursday, February 14, 2002 11:50 AM
> To: Charles E. Perkins
> Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com; Morrow, Glenn
> [RICH2:C330:EXCH]
> Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]
>
>
>
> > I have tried to be very precise and technical in my discussion about
> > piggybacking.  I have set out quite a few technical points (and
> > logical points) that I had hoped would enable further discussion
> > on the matter.  Maybe you are over-generalizing, but if you truly
> > feel that my discussion was all heat and no light, then I have to
> > object, and I very much want to ask you to take another look.
>
> Nobody has brought up any new points (well, except perhaps
> Kempf's point
> about i-mode using something akin to piggybacking but I don't know
> if that is a link-layer type thing or an e2e thing) this time around.
>
> Thus there is no more light shining on the issue than there was
> after the last round of discussions.
>
>   Erik
>
>
>

------_=_NextPart_001_01C1B590.093EFAC8-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 15:07:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08429 for ; Thu, 14 Feb 2002 15:07:12 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04690; Thu, 14 Feb 2002 13:07:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18406; Thu, 14 Feb 2002 12:06:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EK62KL003266 for ; Thu, 14 Feb 2002 12:06:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EK62BG003265 for mobile-ip-dist; Thu, 14 Feb 2002 12:06:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EK5xKL003258 for ; Thu, 14 Feb 2002 12:05:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18008 for ; Thu, 14 Feb 2002 12:06:01 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21573 for ; Thu, 14 Feb 2002 13:06:00 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1EK5xe20050; Thu, 14 Feb 2002 12:05:59 -0800 (PST) Message-ID: <026701c1b592$cc90d120$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Erik Nordmark" , "Charles E. Perkins" References: Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Thu, 14 Feb 2002 12:04:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil, > Just to play devil's advocate - isn't the need for piggybacking tied to a > particular kind of link-layer (low bandwidth but with enough > headroom to stick in a few more bytes)? Just curious. > > Yes, bandwidth is one issue. The solution some have proposed is to stuff more than one IP packet into an L2 frame, but this is hardly viable if the L2 frames are on the order of 40 bytes, as is typically the case with these kinds of low bandwidth link layers. Cedric and Charlie also have some argument that piggybacking helps improve jitter. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 15:11:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08535 for ; Thu, 14 Feb 2002 15:11:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09257; Thu, 14 Feb 2002 13:11:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19573; Thu, 14 Feb 2002 12:11:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EKAvKL003347 for ; Thu, 14 Feb 2002 12:10:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EKAvNe003346 for mobile-ip-dist; Thu, 14 Feb 2002 12:10:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EKAsKL003339 for ; Thu, 14 Feb 2002 12:10:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19441; Thu, 14 Feb 2002 12:10:57 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06103; Thu, 14 Feb 2002 12:10:56 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EKAsV24996; Thu, 14 Feb 2002 14:10:54 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CJX4>; Thu, 14 Feb 2002 14:10:54 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0210AEC3@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , "Charles E. Perkins" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Thu, 14 Feb 2002 14:10:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B593.B4809470" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B593.B4809470 Content-Type: text/plain; charset="iso-8859-1" My comments on the DT should not be constued as personal attacks on the members. They should be constued as constructive criticism to the pressures of external SDOs on them. I can't see how someone could not see the advantages of bundling at all irrespective of the access and particular form of communication going on. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Thursday, February 14, 2002 1:45 PM To: 'mobile-ip@sunroof.eng.sun.com'; Erik Nordmark; Charles E. Perkins Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] seems to me that there is no true technical excuse for not allowing piggybacking and I can only infer logically that some deal making has been done Wow. in order to progress the standard on some sort of deadline self-imposed by some conflicting external SDOs. This prompted my initial criticism in that I wanted to remind people that this is the IETF and we are supposed to deal with the IP problem space - not the least common denominator link layer. Just to play devil's advocate - isn't the need for piggybacking tied to a particular kind of link-layer (low bandwidth but with enough headroom to stick in a few more bytes)? Just curious. I hope you see this as constructive and not a bantor. That is difficult for some parts of your message. Thanks, Glenn > -----Original Message----- > From: Erik Nordmark [ mailto:Erik.Nordmark@eng.sun.com ] > Sent: Thursday, February 14, 2002 11:50 AM > To: Charles E. Perkins > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com; Morrow, Glenn > [RICH2:C330:EXCH] > Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > > I have tried to be very precise and technical in my discussion about > > piggybacking. I have set out quite a few technical points (and > > logical points) that I had hoped would enable further discussion > > on the matter. Maybe you are over-generalizing, but if you truly > > feel that my discussion was all heat and no light, then I have to > > object, and I very much want to ask you to take another look. > > Nobody has brought up any new points (well, except perhaps > Kempf's point > about i-mode using something akin to piggybacking but I don't know > if that is a link-layer type thing or an e2e thing) this time around. > > Thus there is no more light shining on the issue than there was > after the last round of discussions. > > Erik > > > ------_=_NextPart_001_01C1B593.B4809470 Content-Type: text/html; charset="iso-8859-1" Message
My comments on the DT should not be constued as personal attacks on the members. They should be constued as constructive criticism to the pressures of external SDOs on them.
 
I can't see how someone could not see the advantages of bundling at all irrespective of the access and particular form of communication going on.
 
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Thursday, February 14, 2002 1:45 PM
To: 'mobile-ip@sunroof.eng.sun.com'; Erik Nordmark; Charles E. Perkins
Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]

 
seems to me that there is no true technical excuse for not allowing piggybacking and I can only infer logically that some deal making has been done 
 
Wow.
 
  in order to progress the standard on some sort of deadline self-imposed by some conflicting external SDOs. This prompted my initial criticism in that I wanted to remind people that this is the IETF and we are supposed to deal with the IP problem space - not the least common denominator link layer. 
 
Just to play devil's advocate - isn't the need for piggybacking tied to a particular kind of link-layer (low bandwidth but with enough
headroom to stick in a few more bytes)?  Just curious.
 

I hope you see this as constructive and not a bantor.  

That is difficult for some parts of your message. 

Thanks,

Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> Sent: Thursday, February 14, 2002 11:50 AM
> To: Charles E. Perkins
> Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com; Morrow, Glenn
> [RICH2:C330:EXCH]
> Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]
>
>
>
> > I have tried to be very precise and technical in my discussion about
> > piggybacking.  I have set out quite a few technical points (and
> > logical points) that I had hoped would enable further discussion
> > on the matter.  Maybe you are over-generalizing, but if you truly
> > feel that my discussion was all heat and no light, then I have to
> > object, and I very much want to ask you to take another look.
>
> Nobody has brought up any new points (well, except perhaps
> Kempf's point
> about i-mode using something akin to piggybacking but I don't know
> if that is a link-layer type thing or an e2e thing) this time around.
>
> Thus there is no more light shining on the issue than there was
> after the last round of discussions.
>
>   Erik
>
>
>

------_=_NextPart_001_01C1B593.B4809470-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 15:46:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09248 for ; Thu, 14 Feb 2002 15:46:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22102; Thu, 14 Feb 2002 12:46:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20867; Thu, 14 Feb 2002 12:46:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EKeQKL003521 for ; Thu, 14 Feb 2002 12:40:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EKeQ2X003520 for mobile-ip-dist; Thu, 14 Feb 2002 12:40:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EKeMKL003513 for ; Thu, 14 Feb 2002 12:40:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28268 for ; Thu, 14 Feb 2002 12:40:25 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08628 for ; Thu, 14 Feb 2002 13:40:24 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EKeMV02016; Thu, 14 Feb 2002 14:40:22 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CK1W>; Thu, 14 Feb 2002 14:40:22 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0210AFB0@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, haley@zk3.dec.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 14:40:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B597.D27D4A00" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B597.D27D4A00 Content-Type: text/plain; charset="iso-8859-1" Why can't we just leave these engineering tradeoffs to particular products? > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Thursday, February 14, 2002 11:32 AM > To: haley@zk3.dec.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation > > > > How can the DT recognize there is a *potential* benefit, but decide > > to kill piggybacking? > > Brian, > > There is a potential benefit it lots of things - I can > envision benefits > in carry BUs as XML over http (but there might be some > disadvantages as well > :-) > > The issue is the engineering tradeoff. > > Erik > > ------_=_NextPart_001_01C1B597.D27D4A00 Content-Type: text/html; charset="iso-8859-1" RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Why can't we just leave these engineering tradeoffs to particular products?

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> Sent: Thursday, February 14, 2002 11:32 AM
> To: haley@zk3.dec.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
>
>
> > How can the DT recognize there is a *potential* benefit, but decide
> > to kill piggybacking?
>
> Brian,
>
> There is a potential benefit it lots of things - I can
> envision benefits
> in carry BUs as XML over http (but there might be some
> disadvantages as well
> :-)
>
> The issue is the engineering tradeoff.
>
>   Erik
>
>

------_=_NextPart_001_01C1B597.D27D4A00-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 17:05:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11174 for ; Thu, 14 Feb 2002 17:05:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11836; Thu, 14 Feb 2002 15:05:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26807; Thu, 14 Feb 2002 14:04:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EM3wKL003835 for ; Thu, 14 Feb 2002 14:03:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EM3vGi003834 for mobile-ip-dist; Thu, 14 Feb 2002 14:03:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EM3sKL003827 for ; Thu, 14 Feb 2002 14:03:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26526 for ; Thu, 14 Feb 2002 14:03:56 -0800 (PST) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27484 for ; Thu, 14 Feb 2002 15:03:56 -0700 (MST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id WAA03378 for ; Thu, 14 Feb 2002 22:03:55 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021414063709908 for ; Thu, 14 Feb 2002 14:06:37 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1YPARR7T>; Thu, 14 Feb 2002 14:03:55 -0800 Message-ID: From: "Narjala, Ranjit S" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] NAI Extension - implementation questions Date: Thu, 14 Feb 2002 14:03:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: All, We have been trying to implement the NAI extension for MIPv4 as per RFC 2794, but have run into a few fundamental questions. Please do let me know if these questions have already been asked (and answered) before. I would appreciate any help/pointers. Thanks in advance! Question 1 --------------- Consider the case when a mobile node (MN) is statically configured with its home address, and does not require the NAI extension to obtain one. If this MN starts up on its home subnet, its default behaviour will be to de-register with the HomeAgent (HA) using its home address (which will kill all the bindings on the HA for this MN). Now consider the case when an MN is not statically configured with its home address, and needs to use the NAI extension to obtain one. If this MN starts up in its home subnet (meaning it has not yet had a chance to use the NAI extension to acquire a home address from the HomeAgent (HA)), what is its expected behavior? The MN must deregister with the HA, but also needs to obtain its home address from the HA. How does it achieve this? a) Can the MN de-register with the HA, setting the home address field in the RREQ to 0.0.0.0, and include an NAI extension in the RREQ to obtain a home address? Will the HA correctly process the de-registration request using the MN's NAI, and return a home address to use in the registration reply? b) If not, what would be the appropriate behaviour? Question 2 ---------------- Assume that an MN has successfully obtained its home address using the NAI extension, and is currently using this home address (say on a foreign subnet). When the MN changes its point of attachment (say to another foreign subnet), and needs to reregister with the HA, should it use the NAI extension again in the RREQ, or can it reuse the home address it obtained from its previous registration using NAI (seeing that this is the same "session", after all)? Thanks for your help! - Ranjit From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 17:39:30 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11815 for ; Thu, 14 Feb 2002 17:39:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26778; Thu, 14 Feb 2002 15:39:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26372; Thu, 14 Feb 2002 14:39:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EMc0KL003945 for ; Thu, 14 Feb 2002 14:38:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1EMc0NC003944 for mobile-ip-dist; Thu, 14 Feb 2002 14:38:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EMbwKL003937 for ; Thu, 14 Feb 2002 14:37:58 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06991 for ; Thu, 14 Feb 2002 17:38:00 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA00069 for mobile-ip@sunroof.eng.sun.com; Thu, 14 Feb 2002 17:38:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1EMQVKL003921 for ; Thu, 14 Feb 2002 14:26:32 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18136 for ; Thu, 14 Feb 2002 14:26:34 -0800 (PST) Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [217.109.184.17]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07475 for ; Thu, 14 Feb 2002 14:26:33 -0800 (PST) Received: from lul-imc-01.europe.corp.microsoft.com ([157.58.150.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 23:26:31 +0100 Received: from 157.58.150.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Feb 2002 23:26:31 +0100 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 23:26:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 22:26:31 -0000 Message-ID: <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> Thread-Topic: Re: [mobile-ip] Piggybacking - DT recommendation Thread-Index: AcG1pqbHU8jG8zrARq2t4MVEZiYFpw== From: "Michael Roe" To: X-OriginalArrivalTime: 14 Feb 2002 22:26:31.0578 (UTC) FILETIME=[A719F7A0:01C1B5A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1EMQWKL003922 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think that these were the wrong questions to be asking: 1. The size of a binding update depends on which authorization method is being used. In some of the CGA schemes, binding updates are hundreds of bytes long, because they contain public keys and so on. The decision to allow or disallow piggybacking is partly dependent on how big the piggybacked object is going to be, so it's hard to answer this question independently of the authorization scheme. 2. IPSec > We recommend that when IPsec protection is used, it is > always used in *addition* to RR (or CGA) methods, not as > a replacement. Thus RR (or CGA) methods would be used to > protect MN - CN Route optimization procedures even when IPsec > is used. There seem to be two separate authorization checks that are needed before accepting a binding update: (a) Check that the sender is authorized to use the HoA (b) Check that the sender is authorized to the the CoA As far as I can see, an IPsec SA established using, for example, X.509 certificates with IP addresses (not DNS names) in them is perfectly adequate for checking HoA authorization. It's not so good for checking CoA authorization, because at the time the certificate is issued you don't know what CoA the node is going to be using. My current view is that: - you have to do RR for the CoA in all cases; - if you have an IPSec SA, you don't need RR for the HoA; - if the HoA is cryptographically generated, you still need to check that it's RR Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 18:41:59 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12765 for ; Thu, 14 Feb 2002 18:41:59 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22868; Thu, 14 Feb 2002 16:41:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27683; Thu, 14 Feb 2002 15:41:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ENeSKL004528 for ; Thu, 14 Feb 2002 15:40:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1ENeSMe004527 for mobile-ip-dist; Thu, 14 Feb 2002 15:40:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ENePKL004520 for ; Thu, 14 Feb 2002 15:40:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16620 for ; Thu, 14 Feb 2002 15:40:28 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06826 for ; Thu, 14 Feb 2002 16:40:27 -0700 (MST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.30 2002/02/09 00:16:23 root Exp $) with ESMTP id g1ENddL29377 for ; Thu, 14 Feb 2002 23:39:39 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.12 2002/02/09 00:15:52 root Exp $) with SMTP id g1ENdiW08182 for ; Thu, 14 Feb 2002 23:39:44 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021415395506633 for ; Thu, 14 Feb 2002 15:39:55 -0800 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1Y3YGBA2>; Thu, 14 Feb 2002 15:40:25 -0800 Message-ID: From: "Narjala, Ranjit S" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] NAI Extension - implementation questions Date: Thu, 14 Feb 2002 15:40:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, Thanks a lot for your suggestions! My comments are below, within & <\Ranjit>. Regards, - Ranjit -----Original Message----- From: Alpesh S. Patel [mailto:alpesh@cisco.com] Sent: Thursday, February 14, 2002 2:18 PM To: ranjit.s.narjala@intel.com Subject: Re: [mobile-ip] NAI Extension - implementation questions Ranjit, Inserts: "Narjala, Ranjit S" wrote: > All, > > We have been trying to implement the NAI extension for MIPv4 as per RFC > 2794, but have run into a few fundamental questions. Please do let me know > if these questions have already been asked (and answered) before. I would > appreciate any help/pointers. Thanks in advance! > > Question 1 > --------------- > Consider the case when a mobile node (MN) is statically configured with its > home address, and does not require the NAI extension to obtain one. If this > MN starts up on its home subnet, its default behaviour will be to > de-register with the HomeAgent (HA) using its home address (which will kill > all the bindings on the HA for this MN). > > Now consider the case when an MN is not statically configured with its home > address, and needs to use the NAI extension to obtain one. If this MN starts > up in its home subnet (meaning it has not yet had a chance to use the NAI > extension to acquire a home address from the HomeAgent (HA)), what is its > expected behavior? > > The MN must deregister with the HA, but also needs to obtain its home > address from the HA. How does it achieve this? > > a) Can the MN de-register with the HA, setting the home address field in the > RREQ to 0.0.0.0, and include an NAI extension in the RREQ to obtain a home > address? Will the HA correctly process the de-registration request using the > MN's NAI, and return a home address to use in the registration reply? > b) If not, what would be the appropriate behaviour? > When MN first comes, it needs to register before it deregisters. Thus, it should to register with home addr == 0 and NAI. < Ranjit > In that case, the source IP address of the 1st registration will have to be the DHCP address (colocated) that the MN got on the home subnet. Once the MN gets the home address via the 1st registration, it can then procedd to deregister (the source IP address of the packet will now be the MN's home address). This is assuming the home subnet has DHCP support. This will not work if there is not DHCP support on the home subnet, right? If the MN does not acquire a DHCP address on the home subnet, what will it use as the source IP address in the RREQ packet? < \Ranjit > > > Question 2 > ---------------- > Assume that an MN has successfully obtained its home address using the NAI > extension, and is currently using this home address (say on a foreign > subnet). When the MN changes its point of attachment (say to another foreign > subnet), and needs to reregister with the HA, should it use the NAI > extension again in the RREQ, or can it reuse the home address it obtained > from its previous registration using NAI (seeing that this is the same > "session", after all)? > MN should use its home address and NAI when renewing registration. One reason (among others) is that the FA may be serving multiple visitors with same IP (private) addresses. < Ranjit > Since the MN is including a NAI along with the home address in the registration, could the HA potentially send back a home address (in the reply) that is different from the one sent by the MN in the registration request? Or is that possibility ruled out? < \Ranjit > These are my thoughts. Please wait to hear back from some client implementors too. -a > > Thanks for your help! > - Ranjit From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 18:45:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12829 for ; Thu, 14 Feb 2002 18:45:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09133; Thu, 14 Feb 2002 16:45:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29201; Thu, 14 Feb 2002 15:45:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ENi4KL004740 for ; Thu, 14 Feb 2002 15:44:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1ENi4x7004739 for mobile-ip-dist; Thu, 14 Feb 2002 15:44:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ENi0KL004732 for ; Thu, 14 Feb 2002 15:44:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17750 for ; Thu, 14 Feb 2002 15:44:03 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28505 for ; Thu, 14 Feb 2002 15:44:03 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1ENhsZ11161; Thu, 14 Feb 2002 15:43:54 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW92957; Thu, 14 Feb 2002 15:43:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA27826; Thu, 14 Feb 2002 15:44:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.19393.193839.79@thomasm-u1.cisco.com> Date: Thu, 14 Feb 2002 15:44:01 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Francis.Dupont@enst-bretagne.fr Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation In-Reply-To: References: <200202132203.g1DM3Eg12079@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > > => basically BCE state will become hard state. > > Per what definition of hard and soft state? > > There is a definition of soft state in RFC 2205 which says: > o Soft state > > Control state in hosts and routers that will expire if not > refreshed within a specified amount of time. > > Since binding cache entries expire if not refreshed they seem to be > soft state per the above definition. In fact, there are three different kinds of state: 1) cached state 2) soft state 3) hard state Route optimization was in class (1). Requiring that HAO's not be accepted until there be a RR etc test first pushes it into class (2). It was my mistake at last IETF to claim that they were hard state (3) such as TCP state, as Thomas Narten correctly pointed out. However, moving from (1) to (2) is still quite a significant change. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 18:59:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12987 for ; Thu, 14 Feb 2002 18:59:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22548; Thu, 14 Feb 2002 16:58:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23308; Thu, 14 Feb 2002 15:58:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ENvAKL004843 for ; Thu, 14 Feb 2002 15:57:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1ENv962004842 for mobile-ip-dist; Thu, 14 Feb 2002 15:57:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ENv6KL004835 for ; Thu, 14 Feb 2002 15:57:06 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10347 for ; Thu, 14 Feb 2002 15:57:09 -0800 (PST) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14012 for ; Thu, 14 Feb 2002 15:57:06 -0800 (PST) Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id XAA08824 for ; Thu, 14 Feb 2002 23:57:05 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021415561305350 for ; Thu, 14 Feb 2002 15:56:13 -0800 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id <1Y3Z9PRM>; Thu, 14 Feb 2002 15:57:05 -0800 Message-ID: From: "Narjala, Ranjit S" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] NAI Extension - implementation questions Date: Thu, 14 Feb 2002 15:56:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Oops, I apologize for the mistake in the name - I meant Alpesh. I'm sorry. -----Original Message----- From: Narjala, Ranjit S [mailto:ranjit.s.narjala@intel.com] Sent: Thursday, February 14, 2002 3:40 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] NAI Extension - implementation questions Alper, Thanks a lot for your suggestions! My comments are below, within & <\Ranjit>. Regards, - Ranjit -----Original Message----- From: Alpesh S. Patel [mailto:alpesh@cisco.com] Sent: Thursday, February 14, 2002 2:18 PM To: ranjit.s.narjala@intel.com Subject: Re: [mobile-ip] NAI Extension - implementation questions Ranjit, Inserts: "Narjala, Ranjit S" wrote: > All, > > We have been trying to implement the NAI extension for MIPv4 as per RFC > 2794, but have run into a few fundamental questions. Please do let me know > if these questions have already been asked (and answered) before. I would > appreciate any help/pointers. Thanks in advance! > > Question 1 > --------------- > Consider the case when a mobile node (MN) is statically configured with its > home address, and does not require the NAI extension to obtain one. If this > MN starts up on its home subnet, its default behaviour will be to > de-register with the HomeAgent (HA) using its home address (which will kill > all the bindings on the HA for this MN). > > Now consider the case when an MN is not statically configured with its home > address, and needs to use the NAI extension to obtain one. If this MN starts > up in its home subnet (meaning it has not yet had a chance to use the NAI > extension to acquire a home address from the HomeAgent (HA)), what is its > expected behavior? > > The MN must deregister with the HA, but also needs to obtain its home > address from the HA. How does it achieve this? > > a) Can the MN de-register with the HA, setting the home address field in the > RREQ to 0.0.0.0, and include an NAI extension in the RREQ to obtain a home > address? Will the HA correctly process the de-registration request using the > MN's NAI, and return a home address to use in the registration reply? > b) If not, what would be the appropriate behaviour? > When MN first comes, it needs to register before it deregisters. Thus, it should to register with home addr == 0 and NAI. < Ranjit > In that case, the source IP address of the 1st registration will have to be the DHCP address (colocated) that the MN got on the home subnet. Once the MN gets the home address via the 1st registration, it can then procedd to deregister (the source IP address of the packet will now be the MN's home address). This is assuming the home subnet has DHCP support. This will not work if there is not DHCP support on the home subnet, right? If the MN does not acquire a DHCP address on the home subnet, what will it use as the source IP address in the RREQ packet? < \Ranjit > > > Question 2 > ---------------- > Assume that an MN has successfully obtained its home address using the NAI > extension, and is currently using this home address (say on a foreign > subnet). When the MN changes its point of attachment (say to another foreign > subnet), and needs to reregister with the HA, should it use the NAI > extension again in the RREQ, or can it reuse the home address it obtained > from its previous registration using NAI (seeing that this is the same > "session", after all)? > MN should use its home address and NAI when renewing registration. One reason (among others) is that the FA may be serving multiple visitors with same IP (private) addresses. < Ranjit > Since the MN is including a NAI along with the home address in the registration, could the HA potentially send back a home address (in the reply) that is different from the one sent by the MN in the registration request? Or is that possibility ruled out? < \Ranjit > These are my thoughts. Please wait to hear back from some client implementors too. -a > > Thanks for your help! > - Ranjit From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 19:07:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13102 for ; Thu, 14 Feb 2002 19:07:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04212; Thu, 14 Feb 2002 17:07:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26272; Thu, 14 Feb 2002 16:07:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F065KL004921 for ; Thu, 14 Feb 2002 16:06:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F065Qb004920 for mobile-ip-dist; Thu, 14 Feb 2002 16:06:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F061KL004913 for ; Thu, 14 Feb 2002 16:06:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01225 for ; Thu, 14 Feb 2002 16:06:04 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25999 for ; Thu, 14 Feb 2002 17:06:03 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1F05sZ20466 for ; Thu, 14 Feb 2002 16:05:54 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW93442; Thu, 14 Feb 2002 16:05:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA27835; Thu, 14 Feb 2002 16:06:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.20713.545419.976029@thomasm-u1.cisco.com> Date: Thu, 14 Feb 2002 16:06:01 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation In-Reply-To: <200202131629.AA03164@dogbert.zk3.dec.com> References: <200202131629.AA03164@dogbert.zk3.dec.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley USG writes: > > 2.4. ALLOW HAOS ONLY WITH EXISTING BINDINGS > > I guess I could live with this, performance will suffer of course, > but... > > > A HAO with no matching BCE entry generates an ICMP error > > message. The message is sent to the source of the packet, > > i.e. the CoA. This guarantees that there will be no additional > > reflection problems because of this. > > Don't a lot of firewalls today drop ICMP packets? How is the MN > supposed to know the CN even got the packet if it's behind one, > it might just keep retrying, until it eventually stops trying to > communicate (figures the CN is dead), or falls-back to reverse-tunneling > through its HA. Brian -- In my draft draft-thomas-mobileip-bu-sec-00 which describes a RR only solution, I stayed away from ICMP mainly so that it was a self contained protocol which was either permitted across firewalls or denied. What you point out is yet another reason why bifurcation of route optimiztion into two protocols is probably not a good idea. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 19:45:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13765 for ; Thu, 14 Feb 2002 19:45:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08559; Thu, 14 Feb 2002 16:45:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18555; Thu, 14 Feb 2002 16:45:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F0iHKL005142 for ; Thu, 14 Feb 2002 16:44:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F0iHOB005141 for mobile-ip-dist; Thu, 14 Feb 2002 16:44:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F0iDKL005134 for ; Thu, 14 Feb 2002 16:44:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20897 for ; Thu, 14 Feb 2002 16:44:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01252 for ; Thu, 14 Feb 2002 17:44:16 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA16650 for ; Thu, 14 Feb 2002 16:44:16 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1F0iGG14464 for ; Thu, 14 Feb 2002 16:44:16 -0800 X-mProtect:  Thu, 14 Feb 2002 16:44:16 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJV6dJ8; Thu, 14 Feb 2002 16:44:12 PST Message-ID: <3C6C597B.37821942@iprg.nokia.com> Date: Thu, 14 Feb 2002 16:42:35 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Home Address Option: design team recommendation References: <3C684E38.9070406@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, In a few minutes, I will send out a messgae describing how to eliminate the vulnerability associated with the Home Address destination option. For the purposes of understanding my responses to the recommendation, just imagine that it is possible to eliminate the threat. Jari Arkko wrote: > We would also like folks to state for each of our three > separate recommendations whether they AGREE, CAN TOLERATE, or > DISAGREE with them. In case of DISAGREE, please explain why. > > 1. INTRODUCTION > =============== > > The main problem with the Home Address Option (HAO) is its > potential to be used as a part of Denial-of-Service > attacks. More precisely, the Home Address Option helps > the attacker to conceal his or hers location. This is the threat that can be eliminated. > 2. ALTERNATIVES > =============== > > The alternative decisions we can arrive at are the following: > > (a) Decide that the threat is not significant. Can live with. > (b) Apply infrastructure-based ingress filtering Agree. > (c) Apply infrastructure-less ingress filtering Agree. > (d) Allow HAOs only in conjunction of existing bindings (or > IPsec SAs) Disagree. > (e) Additional information copied to the reflected packet Agree. > > > 2.1. THREAT IS NOT SIGNIFICANT > > While the exact nature and seriousness of the threat may be > discussed, it seems that the "do no harm" principle is not > fulfilled. This is because the threat appears harder than the > one caused by regular source address spoofing. I think that the threat is significant, but not drastically significant. I think that, even without remedy, no self-respecting Internet wrecker would mess with it, since there are other better and more effective ways to go about it. > 2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS > > In this alternative, a traceback of the attacker is performed > by having the CN include additional information in the > reflected packets. In particular, the CN could include the > claimed source address of the original packet in the response, > e.g. in the "OAH Destination Option". > > This approach is an easy one to provide within the MIPv6 > specifications. A disadvantage is that it helps mainly for > traceback, and does not help as much prevention -- for > instance the victim's ISP could not filter the attacker's > packets using IP source address, but would have to look at the > option. (Prevention may still be possible, but could require > additional functionality in e.g. routers and filtering > firewalls.) A larger drawback of this scheme is that there are > IPv6 socket API implications, at least for UDP applications, > in order to ensure that the response sent due to a request > containing a HAO always contains a OAH option. Please look at the note my other note on this subject. I think it is better to design a good solution based on this, rather than to eliminate useful functionality. > > 3. DISCUSSION > ============= > > The design team feels that the a great danger for MIPv6 > deployment is that it is perceived as insecure. This is > particularly true after the widely known events that have > taken place in the IETF for MIPv6 since December 2000. Any > special conditions regarding what service providers need to > get in order to allow MIPv6 securely in their networks is > likely going to reduce the number of MIPv6 users. Therefore, > we feel that potential dangers in HAO should be considered. Agreed. They have been considered. > The design team does not feel IFB solutions are acceptable as > a condition for MIPv6's use. MIPv6 will have the largest user > base if it doesn't require additional infrastructure in the > visited locations or in the home networks. We don't have to require them, but we can show how they might be useful. > > 4. RECOMMENDATION > ================= > > The design team notes that the resolution to this seemingly > small issue has major ramifications to the MIPv6 architecture. > It affects the topology of the routes the packets take; it has > a node vs. router functionality decision; it has an IFB > vs. IFL decision. > > The design team recommends alternative d to be applied (R1). > We expect MIPv6 deployment to be soonest and largest if we > choose d. This is the easiest choice except unless one wishes to preserve functionality. Thus, I disagree, and think we should make some extra effort. I'll suggest a good method in another note. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 20:16:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14153 for ; Thu, 14 Feb 2002 20:16:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29003; Thu, 14 Feb 2002 18:16:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28532; Thu, 14 Feb 2002 17:16:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1F1KL005272 for ; Thu, 14 Feb 2002 17:15:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F1F1Hk005271 for mobile-ip-dist; Thu, 14 Feb 2002 17:15:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1EvKL005264 for ; Thu, 14 Feb 2002 17:14:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18344 for ; Thu, 14 Feb 2002 17:15:01 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11717 for ; Thu, 14 Feb 2002 18:15:00 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1F1F0h18095; Thu, 14 Feb 2002 17:15:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAW94937; Thu, 14 Feb 2002 17:14:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA27840; Thu, 14 Feb 2002 17:14:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15468.24850.600770.337107@thomasm-u1.cisco.com> Date: Thu, 14 Feb 2002 17:14:58 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: "Francis Dupont" , "Erik Nordmark" , "Vijay Devarapalli" , "Jari Arkko" , Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-Reply-To: <008701c1b4b5$19315bf0$7e6015ac@T23KEMPF> References: <008701c1b4b5$19315bf0$7e6015ac@T23KEMPF> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf writes: > I agree that the difference in message traffic between AAA-based SA > establishment and IKE or Son of IKE based SA establishment is probably > going to be in the level of percent and not orders of magnitude. The > major > attraction of AAA-based SA establishment is that ISPs have existing > AAA infrastructure that one could see being upgraded to support > AAA-based SA establishment In fact, IPsec can leverage AAA in two ways: 1) XAUTH 2) KINK The former is deployed, but the latter is a lot cleaner. Recall that it's the subscriber database that's actually important. There is no fundamental reason you couldn't put a Kerberos protocol head on an existing AAA database, just like you can put a DIAMETER protocol head on that database. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 20:26:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14319 for ; Thu, 14 Feb 2002 20:26:55 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02914; Thu, 14 Feb 2002 18:26:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01778; Thu, 14 Feb 2002 17:26:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1PTKL005385 for ; Thu, 14 Feb 2002 17:25:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F1PTnI005384 for mobile-ip-dist; Thu, 14 Feb 2002 17:25:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1PQKL005377 for ; Thu, 14 Feb 2002 17:25:26 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19345 for ; Thu, 14 Feb 2002 17:25:30 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12965 for ; Thu, 14 Feb 2002 17:25:30 -0800 (PST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1F1PTt10824 for ; Thu, 14 Feb 2002 17:25:29 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-97.cisco.com [128.107.163.97]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABT02227; Thu, 14 Feb 2002 17:25:10 -0800 (PST) Message-ID: <3C6C6391.A939122E@cisco.com> Date: Thu, 14 Feb 2002 17:25:38 -0800 From: "Alpesh S. Patel" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI Extension - implementation questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ranjit, Inserts: "Narjala, Ranjit S" wrote: > Oops, I apologize for the mistake in the name - I meant Alpesh. > I'm sorry. > > -----Original Message----- > From: Narjala, Ranjit S [mailto:ranjit.s.narjala@intel.com] > Sent: Thursday, February 14, 2002 3:40 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] NAI Extension - implementation questions > > Alper, > > Thanks a lot for your suggestions! > My comments are below, within & <\Ranjit>. > > Regards, > - Ranjit > > -----Original Message----- > From: Alpesh S. Patel [mailto:alpesh@cisco.com] > Sent: Thursday, February 14, 2002 2:18 PM > To: ranjit.s.narjala@intel.com > Subject: Re: [mobile-ip] NAI Extension - implementation questions > > Ranjit, > Inserts: > > "Narjala, Ranjit S" wrote: > > > All, > > > > We have been trying to implement the NAI extension for MIPv4 as per RFC > > 2794, but have run into a few fundamental questions. Please do let me know > > if these questions have already been asked (and answered) before. I would > > appreciate any help/pointers. Thanks in advance! > > > > Question 1 > > --------------- > > Consider the case when a mobile node (MN) is statically configured with > its > > home address, and does not require the NAI extension to obtain one. If > this > > MN starts up on its home subnet, its default behaviour will be to > > de-register with the HomeAgent (HA) using its home address (which will > kill > > all the bindings on the HA for this MN). > > > > Now consider the case when an MN is not statically configured with its > home > > address, and needs to use the NAI extension to obtain one. If this MN > starts > > up in its home subnet (meaning it has not yet had a chance to use the NAI > > extension to acquire a home address from the HomeAgent (HA)), what is its > > expected behavior? > > > > The MN must deregister with the HA, but also needs to obtain its home > > address from the HA. How does it achieve this? > > > > a) Can the MN de-register with the HA, setting the home address field in > the > > RREQ to 0.0.0.0, and include an NAI extension in the RREQ to obtain a home > > address? Will the HA correctly process the de-registration request using > the > > MN's NAI, and return a home address to use in the registration reply? > > b) If not, what would be the appropriate behaviour? > > > > When MN first comes, it needs to register before it deregisters. Thus, it > should > to > register with home addr == 0 and NAI. > > < Ranjit > > In that case, the source IP address of the 1st registration will have to be > the DHCP address (colocated) that the MN got on the home subnet. > Once the MN gets the home address via the 1st registration, it can then > procedd to deregister (the source IP address of the packet will now be the > MN's home address). > > This is assuming the home subnet has DHCP support. This will not work if > there is not DHCP support on the home subnet, right? If the MN does not > acquire a DHCP address on the home subnet, what will it use as the source IP > address in the RREQ packet? > < \Ranjit > MN can use source address of 0. Why would there be no DHCP support? > > > > > > Question 2 > > ---------------- > > Assume that an MN has successfully obtained its home address using the NAI > > extension, and is currently using this home address (say on a foreign > > subnet). When the MN changes its point of attachment (say to another > foreign > > subnet), and needs to reregister with the HA, should it use the NAI > > extension again in the RREQ, or can it reuse the home address it obtained > > from its previous registration using NAI (seeing that this is the same > > "session", after all)? > > > > MN should use its home address and NAI when renewing registration. One > reason (among others) is that the FA may be serving multiple visitors with > same > IP (private) addresses. > > < Ranjit > > Since the MN is including a NAI along with the home address in the > registration, could the HA potentially send back a home address (in the > reply) that is different from the one sent by the MN in the registration > request? Or is that possibility ruled out? > < \Ranjit > HA should check if there is an existing binding and if so assign same address. HA would not give another address. Again, my own interpretation. -a > > > These are my thoughts. Please wait to hear back from some client > implementors > too. > -a > > > > > Thanks for your help! > > - Ranjit From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 20:35:21 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14469 for ; Thu, 14 Feb 2002 20:35:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA17271; Thu, 14 Feb 2002 17:35:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23131; Thu, 14 Feb 2002 17:35:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1YNKL005462 for ; Thu, 14 Feb 2002 17:34:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F1YNuO005461 for mobile-ip-dist; Thu, 14 Feb 2002 17:34:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1YKKL005454 for ; Thu, 14 Feb 2002 17:34:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23994 for ; Thu, 14 Feb 2002 17:34:23 -0800 (PST) Received: from web10704.mail.yahoo.com (web10704.mail.yahoo.com [216.136.130.212]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA18553 for ; Thu, 14 Feb 2002 18:34:23 -0700 (MST) Message-ID: <20020215013422.81060.qmail@web10704.mail.yahoo.com> Received: from [165.213.0.2] by web10704.mail.yahoo.com via HTTP; Thu, 14 Feb 2002 17:34:22 PST Date: Thu, 14 Feb 2002 17:34:22 -0800 (PST) From: Suvidh Mathur Subject: [mobile-ip] Mobile IP implementation To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hi, I'm doing some research on mobility implementations in IPv6 (Linux). Can some one please direct me to the possible ways of doing so, and a comparision between them. I have come up with four ways: 1. Kernel Module through Netfilter hooks 2. Firewalling - IP tables 3. Divert sockets 4. Direct modification of IP code, e.g. forcing a lookup of binding cache for each outgoing packet (there might be some problems here) In each of the above cases (except DIVERT) communication with MIP daemon running in user space can be done through netlink sockets. Please advise me of the suitable way and also if i have missed some other means. thanks regards suvidh __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 20:43:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14642 for ; Thu, 14 Feb 2002 20:43:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04336; Thu, 14 Feb 2002 18:43:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24780; Thu, 14 Feb 2002 17:43:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1gBKL005521 for ; Thu, 14 Feb 2002 17:42:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F1gAmV005520 for mobile-ip-dist; Thu, 14 Feb 2002 17:42:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F1g7KL005513 for ; Thu, 14 Feb 2002 17:42:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07624 for ; Thu, 14 Feb 2002 17:42:09 -0800 (PST) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17319 for ; Thu, 14 Feb 2002 17:42:08 -0800 (PST) Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.50 2002/02/08 23:45:02 root Exp $) with SMTP id BAA19237 for ; Fri, 15 Feb 2002 01:42:08 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002021417471324538 for ; Thu, 14 Feb 2002 17:47:13 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id <1YPKKVLS>; Thu, 14 Feb 2002 17:42:08 -0800 Message-ID: From: "Narjala, Ranjit S" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] NAI Extension - implementation questions Date: Thu, 14 Feb 2002 17:42:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks, Alpesh. Your suggestions are very reasonable. The reason I mentioned that there might not be DHCP support on the home subnet is this: MNs on the home subnet will only use the home address, and never the address acquired via DHCP. If there aren't any nodes on the home subnet except for mobile nodes, DHCP support on that subnet is unnecessary. The MNs can be statically confgured with their home address, or if the NAI extension is being used for dynamic home address assignment, the HAs can be configured with a pool of addresses to manage and hand out to MNs. Regards, - Ranjit -----Original Message----- From: Alpesh S. Patel [mailto:alpesh@cisco.com] Sent: Thursday, February 14, 2002 5:26 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NAI Extension - implementation questions Ranjit, Inserts: "Narjala, Ranjit S" wrote: > Oops, I apologize for the mistake in the name - I meant Alpesh. > I'm sorry. > > -----Original Message----- > From: Narjala, Ranjit S [mailto:ranjit.s.narjala@intel.com] > Sent: Thursday, February 14, 2002 3:40 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] NAI Extension - implementation questions > > Alper, > > Thanks a lot for your suggestions! > My comments are below, within & <\Ranjit>. > > Regards, > - Ranjit > > -----Original Message----- > From: Alpesh S. Patel [mailto:alpesh@cisco.com] > Sent: Thursday, February 14, 2002 2:18 PM > To: ranjit.s.narjala@intel.com > Subject: Re: [mobile-ip] NAI Extension - implementation questions > > Ranjit, > Inserts: > > "Narjala, Ranjit S" wrote: > > > All, > > > > We have been trying to implement the NAI extension for MIPv4 as per RFC > > 2794, but have run into a few fundamental questions. Please do let me know > > if these questions have already been asked (and answered) before. I would > > appreciate any help/pointers. Thanks in advance! > > > > Question 1 > > --------------- > > Consider the case when a mobile node (MN) is statically configured with > its > > home address, and does not require the NAI extension to obtain one. If > this > > MN starts up on its home subnet, its default behaviour will be to > > de-register with the HomeAgent (HA) using its home address (which will > kill > > all the bindings on the HA for this MN). > > > > Now consider the case when an MN is not statically configured with its > home > > address, and needs to use the NAI extension to obtain one. If this MN > starts > > up in its home subnet (meaning it has not yet had a chance to use the NAI > > extension to acquire a home address from the HomeAgent (HA)), what is its > > expected behavior? > > > > The MN must deregister with the HA, but also needs to obtain its home > > address from the HA. How does it achieve this? > > > > a) Can the MN de-register with the HA, setting the home address field in > the > > RREQ to 0.0.0.0, and include an NAI extension in the RREQ to obtain a home > > address? Will the HA correctly process the de-registration request using > the > > MN's NAI, and return a home address to use in the registration reply? > > b) If not, what would be the appropriate behaviour? > > > > When MN first comes, it needs to register before it deregisters. Thus, it > should > to > register with home addr == 0 and NAI. > > < Ranjit > > In that case, the source IP address of the 1st registration will have to be > the DHCP address (colocated) that the MN got on the home subnet. > Once the MN gets the home address via the 1st registration, it can then > procedd to deregister (the source IP address of the packet will now be the > MN's home address). > > This is assuming the home subnet has DHCP support. This will not work if > there is not DHCP support on the home subnet, right? If the MN does not > acquire a DHCP address on the home subnet, what will it use as the source IP > address in the RREQ packet? > < \Ranjit > MN can use source address of 0. Why would there be no DHCP support? > > > > > > Question 2 > > ---------------- > > Assume that an MN has successfully obtained its home address using the NAI > > extension, and is currently using this home address (say on a foreign > > subnet). When the MN changes its point of attachment (say to another > foreign > > subnet), and needs to reregister with the HA, should it use the NAI > > extension again in the RREQ, or can it reuse the home address it obtained > > from its previous registration using NAI (seeing that this is the same > > "session", after all)? > > > > MN should use its home address and NAI when renewing registration. One > reason (among others) is that the FA may be serving multiple visitors with > same > IP (private) addresses. > > < Ranjit > > Since the MN is including a NAI along with the home address in the > registration, could the HA potentially send back a home address (in the > reply) that is different from the one sent by the MN in the registration > request? Or is that possibility ruled out? > < \Ranjit > HA should check if there is an existing binding and if so assign same address. HA would not give another address. Again, my own interpretation. -a > > > These are my thoughts. Please wait to hear back from some client > implementors > too. > -a > > > > > Thanks for your help! > > - Ranjit From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 21:41:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16051 for ; Thu, 14 Feb 2002 21:41:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25249; Thu, 14 Feb 2002 18:41:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02621; Thu, 14 Feb 2002 18:40:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F2ctKL005688 for ; Thu, 14 Feb 2002 18:38:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F2ct3d005687 for mobile-ip-dist; Thu, 14 Feb 2002 18:38:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F2cqKL005680 for ; Thu, 14 Feb 2002 18:38:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08019 for ; Thu, 14 Feb 2002 18:38:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02349 for ; Thu, 14 Feb 2002 18:38:51 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA23736 for ; Thu, 14 Feb 2002 18:38:51 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1F2cos21458 for ; Thu, 14 Feb 2002 18:38:50 -0800 X-mProtect:  Thu, 14 Feb 2002 18:38:50 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOKUT7O; Thu, 14 Feb 2002 18:38:48 PST Message-ID: <3C6C74B9.37EC6315@iprg.nokia.com> Date: Thu, 14 Feb 2002 18:38:49 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] FMIPv6 - Handover Capabilities Extension Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, a question regarding the Handover Capabilties Extension (HOCAP) option in the Fast MIPv6 draft 03. should this option be included in ProxyRtrSol and ProxyRtrAdv messages? thats what it says in Section 5.1.1 and Section 5.1.2. but why? for ProxyRtrAdv it makes sense including it when the mobile node is about to roam into a coverage area with different handover capability. and for ProxyRtrSol too, I am not sure we need to include it every time. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 21:54:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16225 for ; Thu, 14 Feb 2002 21:54:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24255; Thu, 14 Feb 2002 19:54:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04580; Thu, 14 Feb 2002 18:54:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F2qMKL005803 for ; Thu, 14 Feb 2002 18:52:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F2qMIC005802 for mobile-ip-dist; Thu, 14 Feb 2002 18:52:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F2qJKL005795 for ; Thu, 14 Feb 2002 18:52:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25722 for ; Thu, 14 Feb 2002 18:52:22 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23702 for ; Thu, 14 Feb 2002 19:52:21 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA24235 for ; Thu, 14 Feb 2002 18:52:21 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1F2qKT29338 for ; Thu, 14 Feb 2002 18:52:20 -0800 X-mProtect:  Thu, 14 Feb 2002 18:52:20 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMOzNue; Thu, 14 Feb 2002 18:52:18 PST Message-ID: <3C6C7780.4CFAA7B4@iprg.nokia.com> Date: Thu, 14 Feb 2002 18:50:40 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] A new proposal for handling Home Address destination options Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I would like to make the following proposal to enable use of the Home Address option in certain cases even when there is no current Binding Cache entry containing the care-of address. ================================================================== The Home Address option allows a correspondent node to correctly associate a mobile node's home address with ongoing protocol operations in higher level protocols. It is important, for cases where a correspondent node should be able to receive packets from a mobile node without going through a home agent. The current design team recommendation precludes the use of the home address option except in cases where there is a valid Binding Cache entry available at the correspondent node to verify that the care-of address is valid. This is too restrictive. I suggest a mechanism by which packets from the correspondent node are to be tagged with the presumed care-of address of the mobile node. This allows the home agent, without much additional effort, to drop packets that have an invalid care-of address. In order to make a good design, we must first distinguish between a verifiable Home Address options (vHAO), and unverifiable Home Address options (UnvHAO). A vHAO is a home address option that contains a care-of address that can be matched up to the care-of address in a Binding Cache entry for a mobile node's home address. UnvHAOss cannot be so verified, typically because the correspondent node doesn't have any Binding Cache entry for the mobile node. The design team recommendation for the vHAOs is good, and should be incorporated into the specification. For the rest of this note, I only consider UnvHAOs. For UnVCoAs, more care is needed. We can make some simple improvements to the way that correspondent nodes handle UnvHAOs that will substantially reduce or eliminate any residual threat of a viable reflector attack. The first weapon in the arsenal against these attacks is to tag outgoing packets with the unverifiable care-of address. These packets will then reach the home agent. The home agent has to look up its Binding Cache entry for the mobile node. If the care-of address does not match the care-of address tagged by the correspondent node, then the home agent can begin diagnostics or tracing for a possible attacker, and then it would drop such packets. If the care-of address matches, then we are back to good, with much better security. Typically, along with tagging the packet, the correspondent node would also take action to establish a Binding Cache entry so that the care-of address would become verifiable. The other simple mechanisms which further reduce or eliminate vulnerability to the reflector attack are simple rate and capacity limitations at the correspondent node. Any correspondent node should only have a limited capacity for such UnvHOAs (perhaps 5 or so, but configurable and perhaps larger for big servers). Similarly, most correspondent nodes should not make new entries into this UnvHOA cache at a rate of more than one or two per second. Some high-volume correspondent nodes could enlarge their capacity, or their input acceptance rate. Such measures should at least rate-limit messages coming from particular care-of addresses. In any case, a limit of one unverified care-of address per home address should be enforced. There is a very simple firewall policy that will add a lot of protection for general networks. That is, a firewall can drop packets that have the care-of address tag, if there is no reasonable home agent which might tunnel such a packet to a mobile node. This will add further protection, in addition to the traceability of the care-of address. The additional effort to implement this procedure requires that the correspondent node set up a flagged entry in its Binding Cache for the mobile node. This Binding Cache entry does not yet allow the use of the care-of address for (e.g.) a Routing Header, and it does require insertion of the tag containing the care-of address. It would have a short lifetime, on the order of single digits of seconds. I believe that at the time it is created, we should also imagine that the process has been started to create a "regular" Binding Cache entry, perhaps by using Return Routability (RR). Thus, this procedure represents an initiation of a several step process, and in this way enables much smoother and faster communications with the mobile node. This would be particularly important when the mobile node has to supply timely data to the correspondent node at a time when the Binding Cache entry does not yet exist. ================================================================= I hope that this will be sufficient to persuade the design team members to endorse continued operation of the Home Address Option, and thus to maintain the improvements in performance which would be lost if reverse tunneling were always required until a Binding Cache entry could be established. That process could take hundreds of milliseconds, amounting to a quite noticeable loss of responsivity. Furthermore, if a correspondent node loses its Binding Cache entry for any reason, then packets from the mobile node would be black-holed. This is intolerable, especially because it is guaranteed that somewhere, sometime, we will see correspondent nodes losing their cache entries. My proposed mechanism will represent a much more robust way to handle this problem. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 22:03:00 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16332 for ; Thu, 14 Feb 2002 22:02:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12590; Thu, 14 Feb 2002 20:02:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05707; Thu, 14 Feb 2002 19:02:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F31qKL005925 for ; Thu, 14 Feb 2002 19:01:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F31qlZ005924 for mobile-ip-dist; Thu, 14 Feb 2002 19:01:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F31nKL005917 for ; Thu, 14 Feb 2002 19:01:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05592 for ; Thu, 14 Feb 2002 19:01:51 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12268 for ; Thu, 14 Feb 2002 20:01:50 -0700 (MST) Received: from T23KEMPF (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1F31me05044 for ; Thu, 14 Feb 2002 19:01:48 -0800 (PST) Message-ID: <002101c1b5cc$e374c100$956015ac@T23KEMPF> From: "James Kempf" To: References: <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 14 Feb 2002 19:00:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, Some questions. > > My current view is that: > - you have to do RR for the CoA in all cases; Even if the CoA is cryptographically generated? > - if you have an IPSec SA, you don't need RR for the HoA; OK. > - if the HoA is cryptographically generated, you still need to check > that > it's RR > Always? That is, can you do it once then not? Otherwise, I don't see much point in using cryptographically generated addresses. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 14 22:24:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16583 for ; Thu, 14 Feb 2002 22:24:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04210; Thu, 14 Feb 2002 20:24:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16514; Thu, 14 Feb 2002 19:24:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F3NBKL006011 for ; Thu, 14 Feb 2002 19:23:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F3NBDf006010 for mobile-ip-dist; Thu, 14 Feb 2002 19:23:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F3N7KL006003 for ; Thu, 14 Feb 2002 19:23:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16296 for ; Thu, 14 Feb 2002 19:23:10 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17388 for ; Thu, 14 Feb 2002 20:23:09 -0700 (MST) Received: from T23KEMPF (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1F3N7e05667 for ; Thu, 14 Feb 2002 19:23:07 -0800 (PST) Message-ID: <007701c1b5cf$ddcafcd0$956015ac@T23KEMPF> From: "James Kempf" To: References: <3C6C74B9.37EC6315@iprg.nokia.com> Subject: Re: [mobile-ip] FMIPv6 - Handover Capabilities Extension Date: Thu, 14 Feb 2002 19:21:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, You're right, it isn't needed every time. It is only needed when the MN first comes up, and when it roams from one coverage area to another. I think this is discussed in Section 3. jak ----- Original Message ----- From: "Vijay Devarapalli" To: Sent: Thursday, February 14, 2002 6:38 PM Subject: [mobile-ip] FMIPv6 - Handover Capabilities Extension > hi, > > a question regarding the Handover Capabilties Extension (HOCAP) > option in the Fast MIPv6 draft 03. > > should this option be included in ProxyRtrSol and ProxyRtrAdv > messages? thats what it says in Section 5.1.1 and Section 5.1.2. > > but why? for ProxyRtrAdv it makes sense including it when > the mobile node is about to roam into a coverage area with > different handover capability. and for ProxyRtrSol too, I am > not sure we need to include it every time. > > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 01:12:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20326 for ; Fri, 15 Feb 2002 01:12:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25995; Thu, 14 Feb 2002 23:12:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15805; Thu, 14 Feb 2002 22:12:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F6BUKL006234 for ; Thu, 14 Feb 2002 22:11:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F6BUUF006233 for mobile-ip-dist; Thu, 14 Feb 2002 22:11:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F6BRKL006226 for ; Thu, 14 Feb 2002 22:11:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29774 for ; Thu, 14 Feb 2002 22:11:30 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09875 for ; Thu, 14 Feb 2002 23:11:29 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1F6BKZ16999 for ; Thu, 14 Feb 2002 22:11:20 -0800 (PST) Received: from cisco.com (sjc-vpn3-498.cisco.com [10.21.65.242]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABT07933; Thu, 14 Feb 2002 22:11:09 -0800 (PST) Message-ID: <3C6CA6A2.5DA6EDA1@cisco.com> Date: Thu, 14 Feb 2002 22:11:46 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HA redundancy in MIPv4 References: <01FAF65DEA16D4119B95009027E78F310930EF1D@il02exm26.comm.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Adam, Have you seen this draft, draft-subbarao-mobileip-redundancy-00.txt? VRRP is one of the underlying router redundancy protocol specified. Kent Lewis Adam-CAL022 wrote: > What work is being done in this area? I know that Cisco has a solution which runs a HA redundancy protocol on top of HSRP, and 3Com seems to have a HA chassis solution that supports redundant HAs. Both these seem to be proprietery in nature. A draft not too long ago draft-chambless-mobileip-harp-00.txt talked about doing it, but I haven't seen any follow up activity to it. This seems to me like a critical problem to solve, does anybody have any further information on this relating to a standards activity? Maybe something similar to what Cisco does, but using VRRP instead? > > Thanks, > adam -- | | Kent Leung :|: :|: IOS Development :|||: :|||: Voice: 408.526.5030 :|||||||: :|||||||: Email: kleung@cisco.com .:|||||||||:.:|||||||||:. URL : http://wwwin-mobileip:8000 c i s c o S y s t e m s "Enabling the mobile wireless age!" From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 02:34:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28993 for ; Fri, 15 Feb 2002 02:34:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16872; Fri, 15 Feb 2002 00:34:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13551; Thu, 14 Feb 2002 23:34:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F7XhKL006426 for ; Thu, 14 Feb 2002 23:33:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F7XhmV006425 for mobile-ip-dist; Thu, 14 Feb 2002 23:33:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F7XdKL006418 for ; Thu, 14 Feb 2002 23:33:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14784 for ; Thu, 14 Feb 2002 23:33:40 -0800 (PST) Received: from systat.com ([203.90.88.140]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05201 for ; Fri, 15 Feb 2002 00:33:37 -0700 (MST) Received: from temp1 [192.9.200.164] by company.mail [192.9.200.9] with SMTP (MDaemon.PRO.PRO.v5.0.0.R) for ; Fri, 15 Feb 2002 13:04:11 +0530 Message-ID: <001401c1b5dd$dfe34d20$a4c809c0@192.9.200.9> From: "thrineshwara" To: Subject: [mobile-ip] Regarding security aspects for mobile IP Date: Fri, 15 Feb 2002 13:01:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C1B620.EDD43280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MDRemoteIP: 192.9.200.164 X-Return-Path: thrineshwara@cranessoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C1B620.EDD43280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, As per my latest understanding, the current IPSec protocol is found = either not suitable or inadequate in providing the security for Binding = Update messages. New methods have to be identified yet.=20 Could you please update me on the recent developments in this regard?=20 Thanks & regards, Thrineshwara Manager - Telecom Projects Cranes Software International Ltd., Bangalore, India ______________________________________________________ This email with any attachments is for the exclusive use of the intended recipient/s & may contain confidential & legally privileged information. If you are not the intended recipient pls notify the sender immediately & delete the email from your system. Any unauthorised use, disclosure, printing, dissemination, forwarding or copying of this mail is strictly prohibited and unlawful. Visit us at: http://www.cranessoftware.com ------=_NextPart_000_0011_01C1B620.EDD43280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
As per my latest understanding, the = current IPSec=20 protocol is found either not suitable or inadequate in providing = the=20 security for Binding Update messages. New methods have to be identified = yet.=20
 
Could you please update me on the = recent=20 developments in this regard?
 
Thanks & regards,
 
Thrineshwara
Manager - Telecom = Projects
Cranes Software International = Ltd.,
Bangalore, = India

______________________________________________________
This email with any attachments is for the exclusive use of the intended
recipient/s & may contain confidential & legally privileged information.
If you are not the intended recipient pls notify the sender immediately
& delete the email from your system. Any unauthorised use, disclosure,
printing, dissemination, forwarding or copying of this mail is strictly
prohibited and unlawful.
Visit us at: http://www.cranessoftware.com ------=_NextPart_000_0011_01C1B620.EDD43280-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 03:24:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29585 for ; Fri, 15 Feb 2002 03:24:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01017; Fri, 15 Feb 2002 01:24:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06987; Fri, 15 Feb 2002 00:24:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F8NhKL006567 for ; Fri, 15 Feb 2002 00:23:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F8Nh0r006566 for mobile-ip-dist; Fri, 15 Feb 2002 00:23:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F8NdKL006559 for ; Fri, 15 Feb 2002 00:23:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08834 for ; Fri, 15 Feb 2002 00:23:41 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03932 for ; Fri, 15 Feb 2002 00:23:40 -0800 (PST) Received: from jariws1 ([62.248.149.171]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215082256.QHQX6990.fep07-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 10:22:56 +0200 Message-ID: <010301c1b5fa$163f8e80$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 10:23:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Mike for the comments! Some further discussion below: > The decision to allow or disallow piggybacking is partly dependent > on how big the piggybacked object is going to be, so it's hard to > answer this question independently of the authorization scheme. True. > My current view is that: > - you have to do RR for the CoA in all cases; > - if you have an IPSec SA, you don't need RR for the HoA; > - if the HoA is cryptographically generated, you still need to check > that > it's RR I agree with the first and third items. As to the second I think I *technically* agree in the sense that your assumpion (ip addresses in certs) is taken in account. However, I may disagree on the likelihood of the assumption really being true. We could of course state that HoA RR MAY be omitted if the cert has an IP address but MUST be performed otherwise. I'm just somewhat concerned that we'd be specifying a special case handling for something that wouldn't be a very likely case in real life, and introducing some additional complexity to products. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 03:45:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00188 for ; Fri, 15 Feb 2002 03:45:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22075; Fri, 15 Feb 2002 01:45:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09281; Fri, 15 Feb 2002 00:45:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F8fwKL006631 for ; Fri, 15 Feb 2002 00:41:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F8fwdP006630 for mobile-ip-dist; Fri, 15 Feb 2002 00:41:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F8fsKL006623 for ; Fri, 15 Feb 2002 00:41:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08859 for ; Fri, 15 Feb 2002 00:41:55 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26517 for ; Fri, 15 Feb 2002 01:41:53 -0700 (MST) Received: from jariws1 ([62.248.149.171]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215084110.QLTN6990.fep07-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 10:41:10 +0200 Message-ID: <013d01c1b5fc$a2437340$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "James Kempf" , Cc: References: <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> <002101c1b5cc$e374c100$956015ac@T23KEMPF> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 10:41:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > My current view is that: > > - you have to do RR for the CoA in all cases; > > Even if the CoA is cryptographically generated? Hmm.... I believe so. CGA would prevent bombing of a specific host, but if there was no CoA RR test you'd still be able to flood a network. > > - if the HoA is cryptographically generated, you still need to check > > that > > it's RR > > Always? That is, can you do it once then not? Otherwise, I don't > see much point in using cryptographically generated addresses. I believe once is enough here, at the beginning. It's the same flooding argument, but the situation with the HoA and the CoA is different in the sense that HoA stays in the network that we have then verified with RR (and host with CGA), while CoA moves from network to another. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 03:58:02 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00422 for ; Fri, 15 Feb 2002 03:58:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01450; Fri, 15 Feb 2002 00:57:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10631; Fri, 15 Feb 2002 00:57:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F8ulKL006692 for ; Fri, 15 Feb 2002 00:56:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F8ul0M006691 for mobile-ip-dist; Fri, 15 Feb 2002 00:56:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F8uiKL006684 for ; Fri, 15 Feb 2002 00:56:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23371 for ; Fri, 15 Feb 2002 00:56:44 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25466 for ; Fri, 15 Feb 2002 00:56:43 -0800 (PST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g1F8uIc02411; Fri, 15 Feb 2002 09:56:18 +0100 (MET) Message-ID: <3C6CCD33.FA135AC@inrialpes.fr> Date: Fri, 15 Feb 2002 09:56:19 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: James Kempf , mroe@microsoft.com, jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> <002101c1b5cc$e374c100$956015ac@T23KEMPF> <013d01c1b5fc$a2437340$8a1b6e0a@arenanet.fi> Content-Type: multipart/alternative; boundary="------------994D07C90A3E0440768629B5" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------994D07C90A3E0440768629B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote > > > > - if the HoA is cryptographically generated, you still need to check > > > that > > > it's RR > > > > Always? That is, can you do it once then not? Otherwise, I don't > > see much point in using cryptographically generated addresses. > > I believe once is enough here, at the beginning. It's the same > flooding argument, but the situation with the HoA and the CoA > is different in the sense that HoA stays in the network that we > have then verified with RR (and host with CGA), while CoA > moves from network to another. I am not sure whether once is enough. I would say that with CGA you still need to perform HoA RR periodically but not each time you move (so you do have the handover performance problem of "regular" RR). The explanation is the following. In general, HoA RR is useful to 1- make sure that the BU was sent by the legitimate MN 2- avoid the "future" attack (as desribed by Pekka N.) CGA solves the 1st problem but you still need to run a HoA RR periodically to solve the 2nd one... Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------994D07C90A3E0440768629B5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote
 
> >  - if the HoA is cryptographically generated, you still need to check
> > that
> >    it's RR
>
> Always? That is, can you do it once then not? Otherwise, I don't
> see much point in using cryptographically generated addresses.

I believe once is enough here, at the beginning. It's the same
flooding argument, but the situation with the HoA and the CoA
is different in the sense that HoA stays in the network that we
have then verified with RR (and host with CGA), while CoA
moves from network to another.

I am not sure whether once is enough. I would say that with CGA you still
need to perform HoA RR periodically but not each time you move (so you do have
the handover performance problem of "regular" RR).

The explanation is the following. In general, HoA RR is useful to
1- make sure that the BU was sent by the legitimate MN
2- avoid the "future" attack (as desribed by Pekka N.)

CGA solves the 1st problem but you still need to run a HoA RR periodically to solve the 2nd one...

Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------994D07C90A3E0440768629B5-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 04:42:15 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01066 for ; Fri, 15 Feb 2002 04:42:15 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11838; Fri, 15 Feb 2002 02:42:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15576; Fri, 15 Feb 2002 01:41:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F9ejKL006851 for ; Fri, 15 Feb 2002 01:40:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1F9ej6m006850 for mobile-ip-dist; Fri, 15 Feb 2002 01:40:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1F9efKL006843 for ; Fri, 15 Feb 2002 01:40:41 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27926 for ; Fri, 15 Feb 2002 01:40:39 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00704 for ; Fri, 15 Feb 2002 01:40:36 -0800 (PST) Received: from jariws1 ([62.248.149.171]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215093950.QYOW6990.fep07-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 11:39:50 +0200 Message-ID: <016701c1b604$d4a51e80$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Claude Castelluccia" , Cc: "James Kempf" , References: <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> <002101c1b5cc$e374c100$956015ac@T23KEMPF> <013d01c1b5fc$a2437340$8a1b6e0a@arenanet.fi> <3C6CCD33.FA135AC@inrialpes.fr> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 11:40:40 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01C1B615.97F3F2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C1B615.97F3F2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Claude, I think we are in rough agreement though my explanation is a bit different. I did mean to say "periodically but not very often" = instead of "once". I believe Residual_threats.txt talked about hours or days for CGA. The rationale for this is the differences in kinds of future attacks = that you can launch with RR or CGA. With RR, you can launch a specific attack against a specific host, while with CGA at most you achieve some flooding in the network that you visited <=3D a day ago. I am not sure whether once is enough. I would say that with CGA you = still=20 need to perform HoA RR periodically but not each time you move (so you = do have=20 the handover performance problem of "regular" RR).=20 The explanation is the following. In general, HoA RR is useful to=20 1- make sure that the BU was sent by the legitimate MN=20 2- avoid the "future" attack (as desribed by Pekka N.)=20 CGA solves the 1st problem but you still need to run a HoA RR = periodically to solve the 2nd one...=20 ------=_NextPart_000_0164_01C1B615.97F3F2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Claude, I think we are in rough agreement though my=20 explanation is
a bit different. I did mean to say "periodically but = not very=20 often" instead
of "once". I believe Residual_threats.txt talked = about hours=20 or days for
CGA.
 
The rationale for this is the differences in kinds = of future=20 attacks that
you can launch with RR or CGA. With RR, you can = launch a=20 specific
attack against a specific host, while with CGA at = most you=20 achieve
some flooding in the network that you visited = <=3D a day=20 ago.
I am=20 not sure whether once is enough. I would say that with = CGA you still=20
need to perform HoA RR periodically but not each time you = move (so=20 you do have
the handover performance problem of "regular" RR).=20

The explanation is the following. In general, HoA RR is useful = to=20
1- make sure that the BU was sent by the legitimate MN
2- = avoid=20 the "future" attack (as desribed by Pekka N.)=20

CGA solves the 1st problem but you still need to run a=20 HoA RR periodically to solve the 2nd one...=20

------=_NextPart_000_0164_01C1B615.97F3F2C0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 05:16:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01398 for ; Fri, 15 Feb 2002 05:16:15 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA22792; Fri, 15 Feb 2002 03:16:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29461; Fri, 15 Feb 2002 02:16:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FAEsKL006989 for ; Fri, 15 Feb 2002 02:14:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FAEr8C006988 for mobile-ip-dist; Fri, 15 Feb 2002 02:14:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FAEnKL006981 for ; Fri, 15 Feb 2002 02:14:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18855 for ; Fri, 15 Feb 2002 02:14:52 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12401 for ; Fri, 15 Feb 2002 02:14:51 -0800 (PST) Received: from jariws1 ([62.248.149.171]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215101407.RGDD6990.fep07-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 12:14:07 +0200 Message-ID: <018101c1b609$9efc99c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "thrineshwara" Cc: References: <001401c1b5dd$dfe34d20$a4c809c0@192.9.200.9> Subject: Re: [mobile-ip] Regarding security aspects for mobile IP Date: Fri, 15 Feb 2002 12:14:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > As per my latest understanding, the current IPSec protocol is found either not suitable or inadequate in > providing the security for Binding Update messages. New methods have to be identified yet. > > Could you please update me on the recent developments in this regard? You could check the archieve for the "few" messages on the subject, if you want the recent developments ;-) But overall the situation is that understanding of the MIPv6 security requirements has grown a lot during the last year or so. We have a better picture now on the kinds of needs we have for global MN - CN signaling security, the need to check CoAs, the potential dangers to third parties, and so on. An effort is in place to develop a solution, and I believe we have most of the components as long as we could agree on which ones to pick ;-) BU authorization itself we believe can be handled with a few basic techniques called RR and CGA. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:23:44 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01968 for ; Fri, 15 Feb 2002 06:23:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21382; Fri, 15 Feb 2002 03:23:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12972; Fri, 15 Feb 2002 03:23:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBMZKL007249 for ; Fri, 15 Feb 2002 03:22:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBMZZr007248 for mobile-ip-dist; Fri, 15 Feb 2002 03:22:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBMWKL007241 for ; Fri, 15 Feb 2002 03:22:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12815 for ; Fri, 15 Feb 2002 03:22:33 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA21430 for ; Fri, 15 Feb 2002 04:22:31 -0700 (MST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M410PZ9>; Fri, 15 Feb 2002 12:22:30 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M4A4RYH; Fri, 15 Feb 2002 12:22:25 +0100 From: "Jean-Michel COMBES" To: , Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 12:22:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Erik Nordmark > Envoye : jeudi 14 fevrier 2002 18:29 > A : kempf@docomolabs-usa.com > Cc : mobile-ip@sunroof.eng.sun.com > Objet : Re: [mobile-ip] Piggybacking - DT recommendation > > > Jim, > > > If changes are required in IPsec, then I think we ought > > to ask for them. > > How long do you suggest we should delay MIPv6 while waiting for > such changes > to IPsec specifications? > > I think Jeff Schiller already pointed out (but I could misremember) > that MIPv6 BUs don't fit with the available IPsec selectors which > would seem > like a hint that we shouldn't expect IPsec to change. JMC : just allocate a specific Header type value for BU/BAck and the IPsec selector problem is solved (that will allow a more precise firewall policy too) without changes in IPsec. > So I'm having a hard time seeing how to move forward at the moment. > > > > (b) We recommend that when IPsec protection is used, it is > > > always used in *addition* to RR (or CGA) methods, not as > > > a replacement. Thus RR (or CGA) methods would be used to > > > protect MN - CN Route optimization procedures even when IPsec > > > is used. > > > > > > > DISAGREE. Requring RR for BU security if the BU is between > > the MN and an AR or LMM agent in the local foreign network > > will have serious performance impact. Requiring just CGA or > > something similar would probably have less impact. In any > > case, the MN should be able to establish a BSA when it > > enters the foreign network and use that to secure any routing > > update signaling with entities in the foreign network. > > I don't think the DT intended to make a statement about how LMM should > be secured but instead focus on how MIPv6 should be secured. > It might very well be that LMM has both different performance constraints > as well as the ability to rely on some infrastructure local to > an operator. So apart from the LMM concerns, do you still disagree with > the above? > > Erik > Regards. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:42:22 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02119 for ; Fri, 15 Feb 2002 06:42:21 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06499; Fri, 15 Feb 2002 04:42:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29805; Fri, 15 Feb 2002 03:42:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBfEKL007319 for ; Fri, 15 Feb 2002 03:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBfEsg007318 for mobile-ip-dist; Fri, 15 Feb 2002 03:41:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBfBKL007311 for ; Fri, 15 Feb 2002 03:41:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28248 for ; Fri, 15 Feb 2002 03:41:12 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13456 for ; Fri, 15 Feb 2002 03:41:11 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FBfAhM002813 for ; Fri, 15 Feb 2002 12:41:10 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Feb 15 12:40:27 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 12:40:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA13@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "Hesham Soliman (ERA)" , "'Erik Nordmark'" , "'Charles E. Perkins'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'gmorrow@nortelnetworks.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 12:40:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Nobody has brought up any new points (well, except perhaps > Kempf's point > about i-mode using something akin to piggybacking but I don't know > if that is a link-layer type thing or an e2e thing) this > time around. > > Thus there is no more light shining on the issue than there was > after the last round of discussions. => Can't disagree with that. I'd like to summarise my point(s) in a simple way though: Carrying two different types of information in a single IP packet is (architecturally) not a good idea. This is due to the fact that IP packets receive different treatments by link layers, routers and end hosts, depending on the content of the packet. Hence placing 2 different sets of information (each requiring a different treatment) in one packet is likely to break some policies. We've seen some examples already: IPsec and L2s with Qos assurances. We could also see more in future. So the point is, the foundation for this idea is not correct. RFC2460 doesn't say anything about this, but I wouldn't expect it to. I think it's up to us to realise this. I hope this helps the discussion. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:43:26 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02147 for ; Fri, 15 Feb 2002 06:43:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA24009; Fri, 15 Feb 2002 03:43:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00060; Fri, 15 Feb 2002 03:43:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBgaKL007345 for ; Fri, 15 Feb 2002 03:42:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBgaCD007342 for mobile-ip-dist; Fri, 15 Feb 2002 03:42:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBgWKL007334 for ; Fri, 15 Feb 2002 03:42:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16381 for ; Fri, 15 Feb 2002 03:42:33 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27542 for ; Fri, 15 Feb 2002 04:42:32 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1FBgVB26394 for ; Fri, 15 Feb 2002 12:42:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Feb 15 12:41:30 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 12:32:46 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA15@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 12:41:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, late reply, I'm struggling with email. > How about manual configuration? Every mobile node > should be allowed to establish a permanent security > association by manual configuration. The argument > against this for billions of correspondent nodes is clear. > There isn't any good argument for disallowing it in > special cases. => In this case would the policy be: Trust any BU from user@operator.com ? Or Trust any BU from HoA 3ffe::1/128 ? The latter is clearly not possible because the HoA could be spoofed. The former has the authorisation problems that PKI have. > > - AAA? This adds more burdens (infrastructure > > requirement and inflexbility) > > There's a huge difference between mandating AAA for > all purposes (which would be hard because of the reasons > you have given) and disallowing it for all applications > (which would be bad, because many scenarios work well > with AAA-style authorization). AAA (and others!) could > be used to establish longer-term security associations > than ephemeral RR. => OK. I proposed this some time ago, but in light of the recent developments (new IFL methods) I can't see the advantage of using this. But i suppose that doesn't say that it can't happen. > > > > => Interesting, because I can negate the exact > > > > argument with examples. > > > > > > If so, then I will be able to show that your examples > > > are not IPv6 compliant. > > > > => Charlie, this argument does not hold. Using > > extension headers is useful for processing > > of the 'received' packets. It doesn't mean > > that we can put any protocol into any packet and > > that disallowing this breaks IPv6. It might > > be worth discussing this on the IPv6 list > > though. > > This discussion about piggybacking is ONLY relevant for > received packets, => Received from someone who sent them :) Anyhow, I meant that ext headers should be used to process the 'received packet', e.g. The HAO is used to process the received packet by replacing the src address with the address in the HAO. and already IPv6 essentially mandates that > receivers be able to to the appropriate processing for IPv6 > extension headers. There is NO requirement that a sender > has to use piggybacking. > > When I read this sentence: > It doesn't mean that we can put any protocol > into any packet and that disallowing this breaks IPv6. > I start to think that you are absolutely not following my > discussion. But to try to make it clear: > - IPv6 nodes MUST be able to transmit packets with MTU >= 1280 > - IPv6 nodes MUST be able to parse certain extension headers. > Putting these two mandates does not in any way add up to > "putting any protocol into any packet". I think you should try to > explain why you made that characterization. => Perhaps I can best explain this by referring you to the email I sent a moment ago in reply to Erik on the same topic. I've tried to get to the crux of the problem and summarise my reasons. > The links that you claim, are links that do not correctly > implement IPv6. > There are no links, such as you claim, that correctly > implement IPv6. > There are plenty of links that correctly implement IPv6. => The links I refer to implement MTU correctly, it's not an MTU issue. Apart from losing the QoS assurances if the BU is piggybacked on the wrong stream (one that requires different treatment), there can be significant additional delays due to piggybacking on short packets, which are likely to cause the packet to be dropped (e.g. because it's too late in the RT case). Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:43:56 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02182 for ; Fri, 15 Feb 2002 06:43:55 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA24157; Fri, 15 Feb 2002 03:43:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00247; Fri, 15 Feb 2002 03:43:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBh2KL007374 for ; Fri, 15 Feb 2002 03:43:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBh1W5007373 for mobile-ip-dist; Fri, 15 Feb 2002 03:43:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBgvKL007363 for ; Fri, 15 Feb 2002 03:42:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09042 for ; Fri, 15 Feb 2002 03:42:59 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21724 for ; Fri, 15 Feb 2002 04:42:58 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FBgvhM005204 for ; Fri, 15 Feb 2002 12:42:57 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Feb 15 12:42:10 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 12:33:26 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA16@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 12:42:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > > => I've tried to show several times that the best > > way to support MIPv6 signalling on a link with > > QoS support is to separate the signalling packets > > form the normal traffic. If anyone thinks > > this is unreasonable then please explain why. > > > > Sure, radio links would all work *much* better if > we got to use a special channel for IP signaling. > Maybe someday this will happen, but the > fact of the matter is, today it doesn't. => It does. WCDMA already has separate bearers for different types of traffic. They can be reused or new ones can easily be defined. But I think the existing ones are fine. I don't know about the specifics of cdma2000 but I find it very hard to see why the same can't be done. Unless it doesn't provide QoS assurances, which seems unlikely. It's a matter of mapping IP packets on the right bearers. No magic at all. > > => A BSA would only exist if an appropriate mechanism > > was used. I think that can be done with RR+CGA. > > Just because you have an IPsec SA, doesn't mean you > > are authorised to send the BU. It's an address > > ownership problem and that's why we need RR. > > > > How long do you think a handover > would take if the MN had to do RR in order to > update a binding at a MAP? => Too long :) Which is why I keep saying that we should get CGAs done pretty quickly. I think a lot of detailed work was done by several people from several organisations. I haven't seen any serious technical concerns raised against the CGA concept. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:45:23 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02210 for ; Fri, 15 Feb 2002 06:45:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA24457; Fri, 15 Feb 2002 03:45:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00755; Fri, 15 Feb 2002 03:45:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBiYKL007460 for ; Fri, 15 Feb 2002 03:44:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBiX0s007459 for mobile-ip-dist; Fri, 15 Feb 2002 03:44:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBiTKL007443 for ; Fri, 15 Feb 2002 03:44:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28548 for ; Fri, 15 Feb 2002 03:44:30 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27981 for ; Fri, 15 Feb 2002 04:43:55 -0700 (MST) Received: from chardonnay (ipunplugged.com [192.168.4.5]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA07711 for ; Fri, 15 Feb 2002 12:41:44 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 12:43:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil Roberts wrote: > I would like you to comment on each whether you AGREE, > DISAGREE, or CAN LIVE WITH the option. > > 1. Specify that piggybacking of binding update messages not > be used with MIP v6. AGREE > > Pros: > - puts no constraints on using IPSEC to protect > binding updates when possible > Cons: > - if the function is added later, some negotiation > would be needed between the sender and receiver > since all receivers would not be able to support > it > > 2. Specify that piggybacking always be an option. > DISAGREE > Pros: > - allows some improvement in terms of throughput > and latency that may be relevant on certain types > of links > Cons: > - the improvements are only relevant on certain > types of links and thus this is inclusion of > functionality at layer 3 that is useful only for > certain layer 2s > > - in cases where the functionality is detrimental > on certain kinds of links, the receiver may be > victimized when sent a piggybacked BU > > - need policy extensions to IPSEC (and > corresponding implementation modifications) for > those cases in which IPSEC is used to protect > BUs. > > 3. Specify that piggybacking is an option, but subject to > negotiation between the two communicating nodes. > CAN LIVE WITH > Pros: > - may be able to eliminate the detrimental effects > on stations on certain kinds of links > Cons: > - requires some more specification of signalling on > whether or not to use piggybacking and > additional behavior in the mobile node > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:49:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02275 for ; Fri, 15 Feb 2002 06:49:48 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27420; Fri, 15 Feb 2002 04:49:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02062; Fri, 15 Feb 2002 03:49:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBmwKL007560 for ; Fri, 15 Feb 2002 03:48:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBmwsU007559 for mobile-ip-dist; Fri, 15 Feb 2002 03:48:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBmtKL007549 for ; Fri, 15 Feb 2002 03:48:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09827 for ; Fri, 15 Feb 2002 03:48:56 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA23711 for ; Fri, 15 Feb 2002 04:48:55 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M4W5B8B>; Fri, 15 Feb 2002 12:48:54 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M4A4RZJ; Fri, 15 Feb 2002 12:48:49 +0100 From: "Jean-Michel COMBES" To: Subject: TR: [mobile-ip] A new proposal for handling Home Address destination options Date: Fri, 15 Feb 2002 12:48:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry, I forgot to send the reply to the ML Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 -----Message d'origine----- De : Jean-Michel COMBES [mailto:jeanmichel.combes@francetelecom.com] Envoye : vendredi 15 fevrier 2002 11:29 A : charliep@iprg.nokia.com Objet : RE: [mobile-ip] A new proposal for handling Home Address destination options Hi Charlie, my first comment is that your proposition doesn't concern all cases. For me, there are four cases. Explanations : We assumed that the attacker's packet looks like : IPv6Src: Attk@ IPv6Dst: Refl@ H@-DO : Vict@ with Attk@ = Attacker's IP address, Refl@ = Relector's IP address and Vict@ = Victim's IP address What happens then ? *** Case 1 : Vict@ is in the reflector's BC *** - the victim is a MN with H@ = Vict@ = MN-H@ - the MN is registered with a Co@ = MN-Co@ The reflector sends a packet looks like : IPv6Src: Refl@ IPv6Dst: MN-Co@ "RH" : Vict@ = MN-H@ Then two sub-cases : *** Case 1a : MN location is still MN-Co@ *** Solution : if the MN is equipped with a personal firewall, then the packet is rejected. *** Case 1b : MN location is not MN-Co@ *** Solution : ??? *** Case 2 : Vict@ is not in the reflector's BC *** The reflector sends a packet looks like : IPv6Src: Refl@ IPv6Dst: Vict@ Then two sub-cases : *** Case 2a : the victim is a MN *** Solution : your proposition *** Case 2b : the victim is not a MN *** Solution : ??? Am I wrong ? [snip] > > In order to make a good design, we must first distinguish between > a verifiable Home Address options (vHAO), and unverifiable Home > Address options (UnvHAO). A vHAO is a home address option that > contains a care-of address JMC : Typo ? You mean a Home Address, do you ? > that can be matched up to the care-of > address in a Binding Cache entry for a mobile node's home address. > UnvHAOss cannot be so verified, typically because the correspondent > node doesn't have any Binding Cache entry for the mobile node. > The design team recommendation for the vHAOs is good, and should > be incorporated into the specification. For the rest of this > note, I only consider UnvHAOs. > > For UnVCoAs, more care is needed. We can make some simple > improvements to the way that correspondent nodes handle UnvHAOs > that will substantially reduce or eliminate any residual threat > of a viable reflector attack. The first weapon in the arsenal > against these attacks is to tag outgoing packets with the > unverifiable care-of address. JMC : Do you mean that the CN adds a DO (for example) containing Co@ in its packet ? So with today Mobile IPv6 draft, when this is an UnVCoA, the CN MUST always send replies to MN with a RH (type 0) containing the UnVCo@. Am I wrong ? > These packets will then reach > the home agent. JMC : not always true, only if the victim is a MN (see the cases I explain on the top of my reply) > The home agent has to look up its Binding > Cache entry for the mobile node. If the care-of address does > not match the care-of address tagged by the correspondent node, > then the home agent can begin diagnostics or tracing for a > possible attacker, and then it would drop such packets. If the > care-of address matches, then we are back to good, with much > better security. Typically, along with tagging the packet, > the correspondent node would also take action to establish a > Binding Cache entry so that the care-of address would become > verifiable. > > The other simple mechanisms which further reduce or eliminate > vulnerability to the reflector attack are simple rate and > capacity limitations at the correspondent node. Any correspondent > node should only have a limited capacity for such UnvHOAs (perhaps > 5 or so, but configurable and perhaps larger for big servers). JMC : what happens if the attack is distributed (ie. the bad guy sends forged packets to many reflectors) ? Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 06:55:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02334 for ; Fri, 15 Feb 2002 06:55:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25920; Fri, 15 Feb 2002 04:55:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03299; Fri, 15 Feb 2002 03:55:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBsSKL007628 for ; Fri, 15 Feb 2002 03:54:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FBsR9Q007627 for mobile-ip-dist; Fri, 15 Feb 2002 03:54:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FBsOKL007620 for ; Fri, 15 Feb 2002 03:54:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18460 for ; Fri, 15 Feb 2002 03:54:26 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10229 for ; Fri, 15 Feb 2002 04:54:25 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FBsOhM017173 for ; Fri, 15 Feb 2002 12:54:24 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Feb 15 12:53:41 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 12:53:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA1F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , haley@zk3.dec.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 12:53:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B617.6CB15AB0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B617.6CB15AB0 Content-Type: text/plain; charset="iso-8859-1" Glenn, I'm starting to feel like a broken record. It has been mentioned several times that a receiver that will be harmed by piggybacking has no way of stopping this unless some negotiation is done. It seems that most people are against this option. Hesham -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Thursday, February 14, 2002 9:40 PM To: mobile-ip@sunroof.eng.sun.com; haley@zk3.dec.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Why can't we just leave these engineering tradeoffs to particular products? > -----Original Message----- > From: Erik Nordmark [ mailto:Erik.Nordmark@eng.sun.com ] > Sent: Thursday, February 14, 2002 11:32 AM > To: haley@zk3.dec.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation > > > > How can the DT recognize there is a *potential* benefit, but decide > > to kill piggybacking? > > Brian, > > There is a potential benefit it lots of things - I can > envision benefits > in carry BUs as XML over http (but there might be some > disadvantages as well > :-) > > The issue is the engineering tradeoff. > > Erik > > ------_=_NextPart_001_01C1B617.6CB15AB0 Content-Type: text/html; charset="iso-8859-1" RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
Glenn,
 
I'm starting to feel like a broken record. It has been
mentioned several times that a receiver that will be harmed
by piggybacking has no way of stopping this
unless some negotiation is done. It seems that
most people are against this option.
 
Hesham
 
 
-----Original Message-----
From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: Thursday, February 14, 2002 9:40 PM
To: mobile-ip@sunroof.eng.sun.com; haley@zk3.dec.com
Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Why can't we just leave these engineering tradeoffs to particular products?

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> Sent: Thursday, February 14, 2002 11:32 AM
> To: haley@zk3.dec.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
>
>
> > How can the DT recognize there is a *potential* benefit, but decide
> > to kill piggybacking?
>
> Brian,
>
> There is a potential benefit it lots of things - I can
> envision benefits
> in carry BUs as XML over http (but there might be some
> disadvantages as well
> :-)
>
> The issue is the engineering tradeoff.
>
>   Erik
>
>

------_=_NextPart_001_01C1B617.6CB15AB0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 09:00:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05386 for ; Fri, 15 Feb 2002 09:00:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15642; Fri, 15 Feb 2002 06:00:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22077; Fri, 15 Feb 2002 06:00:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FDxQKL007872 for ; Fri, 15 Feb 2002 05:59:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FDxP2P007871 for mobile-ip-dist; Fri, 15 Feb 2002 05:59:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FDxNKL007864 for ; Fri, 15 Feb 2002 05:59:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28557 for ; Fri, 15 Feb 2002 05:59:26 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12180 for ; Fri, 15 Feb 2002 06:59:13 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id F2B2810; Fri, 15 Feb 2002 16:00:45 +0200 (EET) Message-ID: <3C6D140E.3020900@nomadiclab.com> Date: Fri, 15 Feb 2002 15:58:38 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020214 X-Accept-Language: en-us MIME-Version: 1.0 To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C6C7780.4CFAA7B4@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, IMHO, I think that you proposal has quite a lot of value, thanks for working it out and posting it. Furthermore, I don't find any *big* security problems in it, per se. OTOH, I still have to read Jean-Michel's analysis carefully before I can say anything definitive about the security aspects. However, I think that there are fairly serious implementation related problems. We did discuss something fairly similar at the DT, and there seems to be too many implementation problems to solve; see below. However, I would appreciate if you liked to work more on this, and if the problems can indeed be solved, at least I personally will be in favour of something like what you propose. ------------------------ I'm including here the relevant parts of your message: > For UnVCoAs, more care is needed. We can make some simple > improvements to the way that correspondent nodes handle UnvHAOs > that will substantially reduce or eliminate any residual threat > of a viable reflector attack. The first weapon in the arsenal > against these attacks is to tag outgoing packets with the > unverifiable care-of address. These packets will then reach > the home agent. The home agent has to look up its Binding > Cache entry for the mobile node. If the care-of address does > not match the care-of address tagged by the correspondent node, > then the home agent can begin diagnostics or tracing for a > possible attacker, and then it would drop such packets. If the > care-of address matches, then we are back to good, with much > better security. Typically, along with tagging the packet, > the correspondent node would also take action to establish a > Binding Cache entry so that the care-of address would become > verifiable. This far I agree, especially since you later note that the tagging allows firewalls to filter them out whenever they are destined to some non-HA network: > There is a very simple firewall policy that will add a lot of > protection for general networks. That is, a firewall can > drop packets that have the care-of address tag, if there is > no reasonable home agent which might tunnel such a packet to > a mobile node. This will add further protection, in addition > to the traceability of the care-of address. [In this message I don't address the rate limitation etc; I just haven't had enough of time to consider it properly.] Let's continue with your suggested implementation. > The additional effort to implement this procedure requires that > the correspondent node set up a flagged entry in its Binding > Cache for the mobile node. This Binding Cache entry does not > yet allow the use of the care-of address for (e.g.) a Routing > Header, and it does require insertion of the tag containing the > care-of address. It would have a short lifetime, on the order > of single digits of seconds. I believe that at the time it > is created, we should also imagine that the process has been > started to create a "regular" Binding Cache entry, perhaps > by using Return Routability (RR). Thus, this procedure > represents an initiation of a several step process, and in > this way enables much smoother and faster communications with > the mobile node. This would be particularly important when > the mobile node has to supply timely data to the correspondent > node at a time when the Binding Cache entry does not yet exist. Now, here I see, firstly, a potential and fairly serious, security problem, and, secondly, fixing it seems to lead us to a can of worms. But, as I said, maybe this can of worms can be worked out, and I'd appreciate anyone seriously and rigoriously trying to do so. But the security problem first: using the Binding Cache for storing the UnVCoAs so that they can be tagged into outgoing packets leads, together with the firewalling rules, to a serious DoS attack. A concrete example illustrates nicely the problem. A mobile node MN, currently at a CoA 3ff0:100:1 sends a packet to a CN, with a HOA of 3ff0:200:2. Upon receiving the packet, the CN creates a flagged entry in the Binding Cache stating that the MN of HoA 3ff0:200:2 is currently at 3ff0:100:1 but this information has not been verified and therefore RO cannot be used. After that the CN removes the HAO and passes the packet to an application, setting the Source Address to HoA 3ff0:200:2. The application processes the packet and sends back a reply to the HoA 3ff0:200:2. Now, when processing the outgoing packet, the kernel consults the Binding Cache and finds the flagged Binding Cache entry. Since this entry exists, the kernel knows that the packet must be tagged with the CoA, goes ahead, and tags the packet with the CoA 3ff0:100:1. So far so good. Now consider that instead of there being such an MN, a victim called Victor is communicating with the CN using the address 3ff0:200:2. Victor is a stationary node and he doesn't care nor know about Home Agents. Initially Victor's communication flows just fine. However, if Victor employs the firewalling method, i.e. if he drops all packets tagged with a CoA tag, it is very easy to cause Denial-of-Service. Sending a single packet with an arbitrary source address and a HAO with HoA of Victor's address does that. That is, the attacker Mallory sends a single packet, perhaps even from his own address, with a HOA that contains Victor's address 3ff0:200:2 to the CN. This causes the CN to create the flagged BCE, as described above. As a result, all future packets that the CN sends to Victor will be tagged with the CoA tag. And this causes Victor's firewall to drop the packets. To summarize and generalize, using the BCE method for storing information about received HAOs and for tagging outgoing packets is not a good idea. It is too easy to enter bogus information into the BCE, thereby causing bogus tagging of outgoing packets. [A side note: CGA might help here, but OTOH, using it without proper precautiosn would open up DoS vulnerabilities against the CN. Security design is interesting. :-) ] Let us now consider what looks like the right way of implementing this. IMHO, the right way would be to more rigoriously associate requests containing the HAO and related replies that need to be tagged. For TCP and connected UDP sockets this seems to be achieveable, since the information about the received HAO and CoA can be stored in the socket. The unconnected UDP sockets are the problem, though. There the kernel does not create any state where the HAO or CoA could be stored. Consequently, the only reasonable option would be to pass the information to the user level. This, in turn, would mean API changes. One way to extend the API would be to include space into sockaddr_in6 for the care-of-address. Unfortunately that would increase the size of the struct, and as a result some applications might break. On the other hand, most applications these days use sockaddr_storage anyway, so that doesn't matter so much. One bit could be stolen from e.g. flowinfo or scope_id to indicate whether the added space contains a CoA or some other information. If adding extra space to the sockaddr_in6 would be considered too big a change, there are hacks we could make. For example, most unconnected UDP sockets don't have _that_ many outstanding requests anyway. Thus, it _might_ be possible to use e.g. the scope_id field to indicate that the packet was received with a HAO, and cache the HAO in the kernel space for a few seconds. However, such solutions are hacks. Thus, the best way seems to be adding more space to sockaddr_in6, using that space to store CoA (if there is one), and stealing one bit either from flowinfo or scope_id to indicate whether the CoA field is used or not. That would have the additional benefit that also other system calls used to report peer addresses (e.g. getpeername) would also report the CoA, if it exists. Well, maybe we would need to steal another bit, too. That would indicate whether the CoA is one just received in a HAO, or one authorized through RR or RR+CGA. Now, all these considerations led me earlier to some kind of exhaustion, i.e., getting this all work just seemed like too much work and too many details. But if you, Charlie, or if somebody else, feel otherwise, I'd be glad to see the results. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:05:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07464 for ; Fri, 15 Feb 2002 10:05:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21937; Fri, 15 Feb 2002 08:05:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20146; Fri, 15 Feb 2002 07:05:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FF2pKL008030 for ; Fri, 15 Feb 2002 07:02:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FF2o2h008029 for mobile-ip-dist; Fri, 15 Feb 2002 07:02:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FF2lKL008022 for ; Fri, 15 Feb 2002 07:02:47 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23859 for ; Fri, 15 Feb 2002 07:02:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23122 for ; Fri, 15 Feb 2002 07:02:47 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA18546; Fri, 15 Feb 2002 07:02:47 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FF2lo07518; Fri, 15 Feb 2002 07:02:47 -0800 X-mProtect:  Fri, 15 Feb 2002 07:02:47 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdt9C51F; Fri, 15 Feb 2002 07:02:45 PST Message-ID: <3C6D22B2.29E9CAB4@iprg.nokia.com> Date: Fri, 15 Feb 2002 07:01:06 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation References: <4DA6EA82906FD511BE2F00508BCF053802C6AA1F@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, A receiver that cannot receive such packets is not obeying the IPv6 specification. A receiver that wants to have specialized handling for control messages has to bear the burden of further negotiation, since it is no longer a connectionless (i.e., "IP"-style) link. Even so, this is trivially manageable. It seems to me that most people are in favor of having this flexibility. I also wonder why the "anti-" people are so hard line, when they already can have everything that they putatively want. Regards, Charlie P. "Hesham Soliman (ERA)" wrote: > Glenn,I'm starting to feel like a broken record. It has > been mentioned several times that a receiver that will be harmedby > piggybacking has no way of stopping this unless some negotiation is > done. It seems thatmost people are against this option. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:22:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07954 for ; Fri, 15 Feb 2002 10:22:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00386; Fri, 15 Feb 2002 08:22:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23140; Fri, 15 Feb 2002 07:22:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFKVKL008139 for ; Fri, 15 Feb 2002 07:20:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFKV70008138 for mobile-ip-dist; Fri, 15 Feb 2002 07:20:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFKRKL008131 for ; Fri, 15 Feb 2002 07:20:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03927 for ; Fri, 15 Feb 2002 07:20:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21382 for ; Fri, 15 Feb 2002 07:20:28 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA19688; Fri, 15 Feb 2002 07:20:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FFKRl18261; Fri, 15 Feb 2002 07:20:27 -0800 X-mProtect:  Fri, 15 Feb 2002 07:20:27 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcu0jew; Fri, 15 Feb 2002 07:20:25 PST Message-ID: <3C6D26D6.3F0ED278@iprg.nokia.com> Date: Fri, 15 Feb 2002 07:18:46 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA13@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, I have considered for a long time the scenario that you mention, and I think it can be clearly shown to be amenable to proper architectural understanding. That is what I'll try again to show in this note. "Hesham Soliman (ERA)" wrote: > => ... > Carrying two different types of information in > a single IP packet is (architecturally) not a good > idea. This is due to the fact that IP packets receive > different treatments by link layers, routers and > end hosts, depending on the content of the packet. Carrying IP information in an IP packet is architecturally a very good idea. And, IP packets are designed to have payload. So, carrying payload along with IP information in an IP packet is still a very good idea. > Hence placing 2 different sets of information (each > requiring a different treatment) in one > packet is likely to break some policies. IP information requires handling at the IP layer, and we already have a complete specification for that. I don't think you can show any broken policies with the way things are now. > We've seen some examples already: IPsec and > L2s with Qos assurances. We could also see > more in future. So the point is, the foundation > for this idea is not correct. This business about QoS is very interesting, and deserves attention. In fact, it is very reasonable for QoS negotiation to make restrictions about how IP-level resources are to be used. Thus, any QoS negotiation should have something to say about how the channel is used -- including the management of control signals, as well as various kinds of payloads. Speaking concretely, any QoS negotiation should trivially be able to configure transmission of Binding Updates according to the needs of the particular link-layer that you are concerned with. Seen in this way, which I suggest is architecturally much more sound, the problem just goes away naturally. Furthermore, seen in this way, perhaps you can understand why I think you are putting the cart before the horse. You seem to claim that my preferred design is tailored only for those link layers that can handle certain size payloads, but ALL IPv6 link-layers have to be able to do that. I believe I have shown that for the specialized needs of certain applications (NOTE -- NOT LINKS!), QoS mechanisms are already necessary, and can do what you need to have done. > I hope this helps the discussion. I hope you will really try to see my point of view, which is purely made from the the network layer and the desire to maintain improved performance. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:22:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07977 for ; Fri, 15 Feb 2002 10:22:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21611; Fri, 15 Feb 2002 08:22:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23207; Fri, 15 Feb 2002 07:22:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFKiKL008149 for ; Fri, 15 Feb 2002 07:20:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFKipt008148 for mobile-ip-dist; Fri, 15 Feb 2002 07:20:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFKeKL008141 for ; Fri, 15 Feb 2002 07:20:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27637 for ; Fri, 15 Feb 2002 07:20:36 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20329 for ; Fri, 15 Feb 2002 08:20:35 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1FFKYB26703 for ; Fri, 15 Feb 2002 16:20:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Feb 15 16:20:34 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 16:19:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA28@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 16:19:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > It seems to me that most people are in favor of having > this flexibility. I also wonder why the "anti-" people > are so hard line, when they already can have everything > that they putatively want. > => Based on the responses received, I didn't people were interested in the negotiation option. Personally, I don't think it makes sense to negotiate such capability Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:36:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08291 for ; Fri, 15 Feb 2002 10:36:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29003; Fri, 15 Feb 2002 08:36:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00763; Fri, 15 Feb 2002 07:36:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFZQKL008300 for ; Fri, 15 Feb 2002 07:35:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFZQPN008299 for mobile-ip-dist; Fri, 15 Feb 2002 07:35:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFZMKL008292 for ; Fri, 15 Feb 2002 07:35:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06182 for ; Fri, 15 Feb 2002 07:35:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08345 for ; Fri, 15 Feb 2002 07:35:24 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA20098; Fri, 15 Feb 2002 07:35:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FFZNj26749; Fri, 15 Feb 2002 07:35:23 -0800 X-mProtect:  Fri, 15 Feb 2002 07:35:23 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6ycBam; Fri, 15 Feb 2002 07:35:21 PST Message-ID: <3C6D2A56.3727712A@iprg.nokia.com> Date: Fri, 15 Feb 2002 07:33:42 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA15@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, I'll try to answer your questions, but I think they are mostly very straightforward. "Hesham Soliman (ERA)" wrote: > Hi Charlie, > > l > How about manual configuration? Every mobile node > > should be allowed to establish a permanent security > > association by manual configuration. The argument > > against this for billions of correspondent nodes is clear. > > There isn't any good argument for disallowing it in > > special cases. > > => In this case would the policy be: > Trust any BU from user@operator.com ? > Or > Trust any BU from HoA 3ffe::1/128 ? Your question isn't very clear, but I will try to reword it in order to answer the question I think you are most likely to be asking. Please forgive me if I guess wrong. The problem is, I don't know what you mean by "the policy". We are dealing with authentication of IP-level data as received by a correspondent node. Thus, "the policy" would be geared towards verification of data from a single IP address (e.g., xxxx:...:xxxx/128) (a home address). We are NOT dealing with NAI, and we are NOT dealing with prefixes of length less than 128. > The latter is clearly not possible because > the HoA could be spoofed. This is nonsense! If a correspondent node has a security association with a mobile node, based on its home address, then the mobile node cannot use some other home address! > The former has the authorisation problems > that PKI have. We are not dealing with NAI, but anyway it does not matter. As shown by AAA for Mobile IPv4, a AAA server can securely check the credentials of a mobile node which is using NAI. Thus, both of your assertions are incorrect. > > This discussion about piggybacking is ONLY relevant for > > received packets, > > => Received from someone who sent them :) > Anyhow, I meant that ext headers should be > used to process the 'received packet', > e.g. The HAO is used to process the received > packet by replacing the src address with > the address in the HAO. IP-level processing has several components, all easily able to be ascertained by looking at the code, including: - provide an IP-level identifier to higher level protocols (your example) - forwarding packets according to a route table - managing reassembly queues - checking version number :-) and, for Mobile IPv6, - insertion of care-of address for proper routing Features relevant to these functions belong at the IP level. > > - IPv6 nodes MUST be able to transmit packets with MTU >= 1280 > > - IPv6 nodes MUST be able to parse certain extension headers. > > Putting these two mandates does not in any way add up to > > "putting any protocol into any packet". I think you should try to > > explain why you made that characterization. > > => Perhaps I can best explain this by referring you > to the email I sent a moment ago in reply to Erik > on the same topic. I've tried to get to the crux > of the problem and summarise my reasons. I would very much prefer if you could respond directly to this instead of making me pile through even more volumes of e-mail. This overload is somewhat less than "fun", and it's getting all the way down to "dammit I cannot keep up with this dammit". > > The links that you claim, are links that do not correctly > > implement IPv6. > > There are no links, such as you claim, that correctly > > implement IPv6. > > There are plenty of links that correctly implement IPv6. > > => The links I refer to implement MTU correctly, > it's not an MTU issue. It is an MTU issue. It is trivially solvable by QoS methods. > Apart from losing the QoS > assurances if the BU is piggybacked on the wrong > stream (one that requires different treatment), there can > be significant additional delays due to piggybacking > on short packets, which are likely to cause > the packet to be dropped (e.g. because it's too > late in the RT case). If you have QoS assurances, then you can make the Binding Updates go wherever you want them to go. I have never argued against this. I feel that you have not tried to hear my explanation, though. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:40:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08350 for ; Fri, 15 Feb 2002 10:40:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01022; Fri, 15 Feb 2002 08:40:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01967; Fri, 15 Feb 2002 07:40:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFdnKL008430 for ; Fri, 15 Feb 2002 07:39:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFdn4a008429 for mobile-ip-dist; Fri, 15 Feb 2002 07:39:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFdkKL008422 for ; Fri, 15 Feb 2002 07:39:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25979 for ; Fri, 15 Feb 2002 07:39:47 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00656 for ; Fri, 15 Feb 2002 08:39:46 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FFdjhM017198 for ; Fri, 15 Feb 2002 16:39:45 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Feb 15 16:39:44 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 16:39:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA2A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 16:39:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Carrying two different types of information in > > a single IP packet is (architecturally) not a good > > idea. This is due to the fact that IP packets receive > > different treatments by link layers, routers and > > end hosts, depending on the content of the packet. > > Carrying IP information in an IP packet is architecturally > a very good idea. And, IP packets are designed to have > payload. So, carrying payload along with IP information > in an IP packet is still a very good idea. => Provided the payload's needs are known. If part of the payload requires different treatment from the rest, then it doesn't make any sense to include both in the same IP packet. > > > Hence placing 2 different sets of information (each > > requiring a different treatment) in one > > packet is likely to break some policies. > > IP information requires handling at the IP layer, > and we already have a complete specification for > that. I don't think you can show any broken policies > with the way things are now. => ?? I realise that IP requires handling at the IP layer. When you say 'the way things are now', are you referring to MIPv6 or IP in general? > > > We've seen some examples already: IPsec and > > L2s with Qos assurances. We could also see > > more in future. So the point is, the foundation > > for this idea is not correct. > > This business about QoS is very interesting, and > deserves attention. In fact, it is very reasonable > for QoS negotiation to make restrictions about > how IP-level resources are to be used. Thus, > any QoS negotiation should have something to > say about how the channel is used -- => Agreed. including > the management of control signals, as well as > various kinds of payloads. => Sure, but 'various kinds of payloads' in various packets is fine, whereas 'various kinds of payloads' in the same packet is not good. Can you give me a concrete example about how this can be handled in terms of doing the 'right thing' for each of the different types of payload, at the same time ? Even if there is such example (I don't know if there is), the point is, this is a bad protocol architecture. Speaking concretely, > any QoS negotiation should trivially be able to > configure transmission of Binding Updates according > to the needs of the particular link-layer that you are > concerned with. => Of course, but this is not the point. If one packet contains a BU (requires channel configuration X) and another application payload (requires channel config Y). I don't see a trivial way of selecting a single channel for this single packet. > > Seen in this way, which I suggest is architecturally > much more sound, the problem just goes away > naturally. => i must have missed something above, because I don't know how you reached that conclusion. > Furthermore, seen in this way, perhaps you can > understand why I think you are putting the cart > before the horse. You seem to claim that my preferred > design is tailored only for those link layers that can > handle certain size payloads, => The payload size is not the big issue here. but ALL IPv6 link-layers > have to be able to do that. => They sure do, but for a price: additional significant delays. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:41:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08375 for ; Fri, 15 Feb 2002 10:41:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10278; Fri, 15 Feb 2002 08:41:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02400; Fri, 15 Feb 2002 07:41:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFeqKL008477 for ; Fri, 15 Feb 2002 07:40:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFeqNg008476 for mobile-ip-dist; Fri, 15 Feb 2002 07:40:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFemKL008463 for ; Fri, 15 Feb 2002 07:40:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21275; Fri, 15 Feb 2002 07:40:49 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09770; Fri, 15 Feb 2002 08:40:49 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FFeiN04139; Fri, 15 Feb 2002 09:40:44 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H22HQ5>; Fri, 15 Feb 2002 09:40:44 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0215F83F@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Hesham Soliman (ERA)" , "'Erik Nordmark'" , "'Charles E. Perkins'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 09:40:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B637.202385E0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B637.202385E0 Content-Type: text/plain; charset="iso-8859-1" Hesham, There is no technical or logical argument to your point given. You are just saying I think this is bad without giving any meat to the argument. I do not agree with you on this view. Network services are network services and right now MIPv6 is not a network service in that the network does not participate other than forwarding i.e. there is no LMM and there is no FMIP in the MIPv6 spec. So since MIPv6 standalone is not a network service right now, your points are invalid. Furthermore when we do get to the network service based forms of MIP interacting with other network services, I think we will find that the same security arrangements between the enpoints requesting these services and the network will be used for all network based services. Sometimes an endpoint will need just one service and sometimes it will need more than one. Also sometimes the services need to know about each other and work together. Bundling of these distinct functional PDUs will give us modularity,flexibility and optimization. With these points in mind, I don't agree with you and it seems you are trying to use out of scope arguments that may not be correct in order to influence the current scope of MIPv6. I.e. I think NSIS might be a more appropriate discussion area for your viewpoint at this time. Thanks, Glenn > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Friday, February 15, 2002 5:40 AM > To: Hesham Soliman (ERA); 'Erik Nordmark'; 'Charles E. Perkins' > Cc: 'mobile-ip@sunroof.eng.sun.com'; Morrow, Glenn [RICH2:C330:EXCH] > Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > > > Nobody has brought up any new points (well, except perhaps > > Kempf's point > > about i-mode using something akin to piggybacking but I don't know > > if that is a link-layer type thing or an e2e thing) this > > time around. > > > > Thus there is no more light shining on the issue than there was > > after the last round of discussions. > > => Can't disagree with that. I'd like to summarise > my point(s) in a simple way though: > Carrying two different types of information in > a single IP packet is (architecturally) not a good > idea. This is due to the fact that IP packets receive > different treatments by link layers, routers and > end hosts, depending on the content of the packet. > Hence placing 2 different sets of information (each > requiring a different treatment) in one > packet is likely to break some policies. > We've seen some examples already: IPsec and > L2s with Qos assurances. We could also see > more in future. So the point is, the foundation > for this idea is not correct. > > RFC2460 doesn't say anything about this, > but I wouldn't expect it to. I think it's > up to us to realise this. > > I hope this helps the discussion. > > Hesham > ------_=_NextPart_001_01C1B637.202385E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Hesham,

There is no technical or logical argument to your = point given. You are just saying I think this is bad without giving any = meat to the argument.

I do not agree with you on this view. Network = services are network services and right now MIPv6 is not a network = service in that the network does not participate other than forwarding = i.e. there is no LMM and there is no FMIP in the MIPv6 spec. So since = MIPv6 standalone is not a network service right now, your points are = invalid.

Furthermore when we do get to the network service = based forms of MIP interacting with other network services, I think we = will find that the same security arrangements between the enpoints = requesting these services and the network will be used for all network = based services.

Sometimes an endpoint will need just one service and = sometimes it will need more than one. Also sometimes the services need = to know about each other and work together. Bundling of these distinct = functional PDUs will give us modularity,flexibility and = optimization. 

With these points in mind, I don't agree with you and = it seems you are trying to use out of scope arguments that may not be = correct in order to influence the current scope of MIPv6. I.e. I think = NSIS might be a more appropriate discussion area for your viewpoint at = this time.

Thanks,

Glenn



> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:hesham.soliman@era= .ericsson.se]
> Sent: Friday, February 15, 2002 5:40 AM
> To: Hesham Soliman (ERA); 'Erik Nordmark'; = 'Charles E. Perkins'
> Cc: 'mobile-ip@sunroof.eng.sun.com'; Morrow, = Glenn [RICH2:C330:EXCH]
> Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking = - DT recommendation]
>
>
>
>
>   > Nobody has brought up any new = points (well, except perhaps
>   > Kempf's point
>   > about i-mode using something = akin to piggybacking but I don't know
>   > if that is a link-layer type = thing or an e2e thing) this
>   > time around.
>   >
>   > Thus there is no more light = shining on the issue than there was
>   > after the last round of = discussions.
>
> =3D> Can't disagree with that. I'd like to = summarise
> my point(s) in a simple way though:
> Carrying two different types of information = in
> a single IP packet is (architecturally) not a = good
> idea. This is due to the fact that IP packets = receive
> different treatments by link layers, routers = and
> end hosts, depending on the content of the = packet.
> Hence placing 2 different sets of information = (each
> requiring a different treatment) in one
> packet is likely to break some policies. =
> We've seen some examples already: IPsec and =
> L2s with Qos assurances. We could also = see
> more in future. So the point is, the foundation =
> for this idea is not correct.
>
> RFC2460 doesn't say anything about this, =
> but I wouldn't expect it to. I think it's =
> up to us to realise this.
>
> I hope this helps the discussion.
>
> Hesham
>

------_=_NextPart_001_01C1B637.202385E0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:55:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08970 for ; Fri, 15 Feb 2002 10:55:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09585; Fri, 15 Feb 2002 08:55:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06031; Fri, 15 Feb 2002 07:55:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFsdKL008653 for ; Fri, 15 Feb 2002 07:54:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFscTu008652 for mobile-ip-dist; Fri, 15 Feb 2002 07:54:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFsZKL008645 for ; Fri, 15 Feb 2002 07:54:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24267 for ; Fri, 15 Feb 2002 07:54:37 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09193 for ; Fri, 15 Feb 2002 08:54:37 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA20667; Fri, 15 Feb 2002 07:54:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FFsZN08654; Fri, 15 Feb 2002 07:54:35 -0800 X-mProtect:  Fri, 15 Feb 2002 07:54:35 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBnDrMj; Fri, 15 Feb 2002 07:54:33 PST Message-ID: <3C6D2ED6.87BB2BF0@iprg.nokia.com> Date: Fri, 15 Feb 2002 07:52:54 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Michel COMBES CC: Mobile IP Working Group Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jean-Michel, Jean-Michel COMBES wrote: > Hi Charlie, > > my first comment is that your proposition doesn't concern all cases. > For me, there are four cases. Explanations : > > We assumed that the attacker's packet looks like : > IPv6Src: Attk@ > IPv6Dst: Refl@ > H@-DO : Vict@ > with Attk@ = Attacker's IP address, Refl@ = Relector's IP address and Vict@ > = Victim's IP address > > What happens then ? > > *** Case 1 : Vict@ is in the reflector's BC *** > - the victim is a MN with H@ = Vict@ = MN-H@ > - the MN is registered with a Co@ = MN-Co@ > The reflector sends a packet looks like : > IPv6Src: Refl@ > IPv6Dst: MN-Co@ > "RH" : Vict@ = MN-H@ It took me a while to figure out that BC == "Binding Cache"... > Then two sub-cases : > > *** Case 1a : MN location is still MN-Co@ *** > Solution : if the MN is equipped with a personal firewall, then the packet > is rejected. > > *** Case 1b : MN location is not MN-Co@ *** > Solution : ??? In this case, there is absolutely no problem. Since the mobile node has an entry in the correspondent node's Binding Cache, then the mobile node has established that Binding Cache entry by some means that supplied the care-of address for that Binding Cache entry. If the care-of address does not match what's in the Home Address Option, then the packet is dropped. This is the "verifiable" case in my proposal, and as I indicated in my note, this is to follow the recommendation of the design team -- namely, if the are Binding Cache entries for the home address, and none of them match the care-of address sent in the Home Address option, the packet is dropped (perhaps also logged for security). > *** Case 2 : Vict@ is not in the reflector's BC *** > The reflector sends a packet looks like : > IPv6Src: Refl@ > IPv6Dst: Vict@ > > Then two sub-cases : > > *** Case 2a : the victim is a MN *** > Solution : your proposition > > *** Case 2b : the victim is not a MN *** > Solution : ??? In case 2b, the firewall should drop packets destined for a network that does not have mobile nodes, but that have the care-of address tag. I did mention this in my proposal. > > In order to make a good design, we must first distinguish between > > a verifiable Home Address options (vHAO), and unverifiable Home > > Address options (UnvHAO). A vHAO is a home address option that > > contains a care-of address > > JMC : > Typo ? You mean a Home Address, do you ? No, but I still didn't say what I meant. I meant that the vHAO is a home address option in a packet which contains a care-of address which is verifiably associated with the mobile node's home address. > > that can be matched up to the care-of > > address in a Binding Cache entry for a mobile node's home address. > > UnvHAOss cannot be so verified, typically because the correspondent > > node doesn't have any Binding Cache entry for the mobile node. > > The design team recommendation for the vHAOs is good, and should > > be incorporated into the specification. For the rest of this > > note, I only consider UnvHAOs. > > > > For UnVCoAs, more care is needed. We can make some simple > > improvements to the way that correspondent nodes handle UnvHAOs > > that will substantially reduce or eliminate any residual threat > > of a viable reflector attack. The first weapon in the arsenal > > against these attacks is to tag outgoing packets with the > > unverifiable care-of address. > > JMC : > Do you mean that the CN adds a DO (for example) containing Co@ in its packet > ? So with today Mobile IPv6 draft, when this is an UnVCoA, the CN MUST > always send replies to MN with a RH (type 0) containing the UnVCo@. Am I > wrong ? The format of the tag is not decided. It could be a routing header with segments-left == 0. It could be something else. The format of the tag might depend on the outcome of the ongoing discussion about what kind of routing header should be used for route optimization. > > The home agent has to look up its Binding > > Cache entry for the mobile node. If the care-of address does > > not match the care-of address tagged by the correspondent node, > > then the home agent can begin diagnostics or tracing for a > > possible attacker, and then it would drop such packets. If the > > care-of address matches, then we are back to good, with much > > better security. Typically, along with tagging the packet, > > the correspondent node would also take action to establish a > > Binding Cache entry so that the care-of address would become > > verifiable. > > > > The other simple mechanisms which further reduce or eliminate > > vulnerability to the reflector attack are simple rate and > > capacity limitations at the correspondent node. Any correspondent > > node should only have a limited capacity for such UnvHOAs (perhaps > > 5 or so, but configurable and perhaps larger for big servers). > > JMC : > what happens if the attack is distributed (ie. the bad guy sends forged > packets to many reflectors) ? Then the bad guy has done exactly the same thing, but less efficiently, than sending all the packets itself to the victim. It would be faster for the bad guy to just forget about this useless method of attack. Plus the attack is eminently traceable. I do not think this remaining threat is at all worthy of amputating useful protocol functionality. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 10:59:50 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09171 for ; Fri, 15 Feb 2002 10:59:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10748; Fri, 15 Feb 2002 08:59:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07263; Fri, 15 Feb 2002 07:59:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFwrKL008747 for ; Fri, 15 Feb 2002 07:58:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FFwq2o008746 for mobile-ip-dist; Fri, 15 Feb 2002 07:58:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FFwnKL008739 for ; Fri, 15 Feb 2002 07:58:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25289 for ; Fri, 15 Feb 2002 07:58:51 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06740 for ; Fri, 15 Feb 2002 07:58:50 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FFwnhM025236 for ; Fri, 15 Feb 2002 16:58:49 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Feb 15 16:58:07 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 16:49:19 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA2B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 16:58:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > should be allowed to establish a permanent security > > > association by manual configuration. The argument > > > against this for billions of correspondent nodes is clear. > > > There isn't any good argument for disallowing it in > > > special cases. > > > > => In this case would the policy be: > > Trust any BU from user@operator.com ? > > Or > > Trust any BU from HoA 3ffe::1/128 ? > > The problem is, I don't know what you mean by "the policy". > We are dealing with authentication of IP-level data as > received by a correspondent node. Thus, "the policy" > would be geared towards verification of data from a > single IP address (e.g., xxxx:...:xxxx/128) (a home > address). We are NOT dealing with NAI, and we are > NOT dealing with prefixes of length less than 128. => My points are: - what is the identity used to establish an SA? - Just because you have an SA with that identity does that mean that they can modify your routing table (that's effectively what a BU does). The ownership of a HoA does NOT give you the right to forward traffic to any address (CoA) on the Internet. This is why I said that the second option was not valid. But i clearly said it wrongly, probably because of the time I wrote it! Being a certain identity in a certificate ..etc does not necessarily authorise you to divert traffic from an address (HoA), unless the HoA is included in your identity somehow. And you still need to prove that you own a CoA of course. Authenticating someone doesn't necessarily give them authorisation to do whatever they want. For the BU, the proof of ownership for the HoA and Coa is needed. > > This is nonsense! If a correspondent node has a > security association with a mobile node, based on its > home address, then the mobile node cannot use some > other home address! => OK I explained what I should have said above. > > > The former has the authorisation problems > > that PKI have. > > We are not dealing with NAI, but anyway it does not > matter. As shown by AAA for Mobile IPv4, a AAA > server can securely check the credentials of a mobile > node which is using NAI. Thus, both of your assertions > are incorrect. => What's AAA doing here? My response was on manually configured SAs! > > => The links I refer to implement MTU correctly, > > it's not an MTU issue. > > It is an MTU issue. It is trivially solvable by QoS methods. => I do not know why you assert that it's MTU related. MTU has nothing to do with this. What are the trivial QoS methods?? Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 11:08:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09504 for ; Fri, 15 Feb 2002 11:08:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15407; Fri, 15 Feb 2002 09:08:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10268; Fri, 15 Feb 2002 08:08:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FG7KKL008877 for ; Fri, 15 Feb 2002 08:07:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FG7KdK008876 for mobile-ip-dist; Fri, 15 Feb 2002 08:07:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FG7GKL008862 for ; Fri, 15 Feb 2002 08:07:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09846 for ; Fri, 15 Feb 2002 08:07:18 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14759 for ; Fri, 15 Feb 2002 09:07:17 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1FG7GB23667 for ; Fri, 15 Feb 2002 17:07:16 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Feb 15 17:06:50 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 17:06:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA2C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Glenn Morrow'" , "Hesham Soliman (ERA)" , "'Erik Nordmark'" , "'Charles E. Perkins'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 17:06:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: There is no technical or logical argument to your point given. You are just saying I think this is bad without giving any meat to the argument. => Good feedback (no I'm not serious). I do not agree with you on this view. Network services are network services and right now MIPv6 is not a network service in that the network does not participate other than forwarding i.e. there is no LMM and there is no FMIP in the MIPv6 spec. So since MIPv6 standalone is not a network service right now, your points are invalid. =>Glenn, What are you talking about ? Did you really read anything below? I'm talking about this: - Placing more than one payload in the packet, each requiring different level of QoS, security or any other handling, is a bad idea. Who said anything about LMM or FMIP???? Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 11:32:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10295 for ; Fri, 15 Feb 2002 11:32:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06912; Fri, 15 Feb 2002 09:32:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16815; Fri, 15 Feb 2002 08:32:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGVcKL009049 for ; Fri, 15 Feb 2002 08:31:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGVbKD009048 for mobile-ip-dist; Fri, 15 Feb 2002 08:31:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGVYKL009038 for ; Fri, 15 Feb 2002 08:31:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15174 for ; Fri, 15 Feb 2002 08:31:36 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06168 for ; Fri, 15 Feb 2002 09:31:35 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA22403; Fri, 15 Feb 2002 08:31:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FGVYV04087; Fri, 15 Feb 2002 08:31:34 -0800 X-mProtect:  Fri, 15 Feb 2002 08:31:34 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcYeBVw; Fri, 15 Feb 2002 08:31:32 PST Message-ID: <3C6D3781.7F18DB82@iprg.nokia.com> Date: Fri, 15 Feb 2002 08:29:54 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation References: <4DA6EA82906FD511BE2F00508BCF053802C6AA28@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, "Hesham Soliman (ERA)" wrote: > => Based on the responses received, I didn't > people were interested in the negotiation > option. Personally, I don't think it makes > sense to negotiate such capability Which capability are you referring to? There was not any negotiation referred to in the paragraph you quoted. The only negotiation I mentioned, was the negotiated related to making the particular kind of QoS reservation that you had discussed, related to sending Binding Update on a separate control channel. Also, please note that even if there is a separate control channel, correct IP operation would require that negotiation be carried out even before splitting naked Binding Updates down that channel, so nothing is gained in this regard by axing the functionality. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 11:40:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10673 for ; Fri, 15 Feb 2002 11:40:52 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11373; Fri, 15 Feb 2002 09:40:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06067; Fri, 15 Feb 2002 08:40:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGdrKL009210 for ; Fri, 15 Feb 2002 08:39:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGdrl1009209 for mobile-ip-dist; Fri, 15 Feb 2002 08:39:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGdoKL009202 for ; Fri, 15 Feb 2002 08:39:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05924 for ; Fri, 15 Feb 2002 08:39:52 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03902 for ; Fri, 15 Feb 2002 09:39:51 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FGdohM011333 for ; Fri, 15 Feb 2002 17:39:50 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Feb 15 17:39:50 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 17:30:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA31@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 17:39:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => Based on the responses received, I didn't > > people were interested in the negotiation > > option. Personally, I don't think it makes > > sense to negotiate such capability > > > The only negotiation I mentioned, was the > negotiated related to making the particular kind > of QoS reservation that you had discussed, > related to sending Binding Update on a > separate control channel. => Ah, ok. Sure, that negotiations will take place anytime between turning on the device and sending the BU. It's implementation (system) dependant I suppose. Also, please note > that even if there is a separate control channel, > correct IP operation would require that > negotiation be carried out even before splitting > naked Binding Updates down that channel, so > nothing is gained in this regard by axing the > functionality. => By 'naded' BU you mean in a separate packet right? You don't mean sending the ext header alone and then recombining that at the receiving router do you? I'll assume the former, yes a request for a certain channel is needed before sending the packet. The point is, separation of the packets will mean that each will get the 'expected' treatment. The other alternative is to take each extension header and place it on a separate channel. But I think this is obviously unworkable because some parts of the packet might get lost and some not. Since some parts might require retransmission and some don't, then things will get very messy. So it's just a lot simpler to send them in 2 separate IP packets. Hesham > > Regards, > Charlie P. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 11:47:01 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10911 for ; Fri, 15 Feb 2002 11:47:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24511; Fri, 15 Feb 2002 08:46:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08283; Fri, 15 Feb 2002 08:46:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGjTKL009435 for ; Fri, 15 Feb 2002 08:45:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGjTWM009434 for mobile-ip-dist; Fri, 15 Feb 2002 08:45:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGjQKL009427 for ; Fri, 15 Feb 2002 08:45:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07713 for ; Fri, 15 Feb 2002 08:45:28 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05951 for ; Fri, 15 Feb 2002 09:45:28 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FGjQN06536; Fri, 15 Feb 2002 10:45:26 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CP64>; Fri, 15 Feb 2002 10:45:26 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0215FA7B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com, haley@zk3.dec.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 10:45:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B640.2A347E50" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B640.2A347E50 Content-Type: text/plain; charset="iso-8859-1" Hesham, I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators. Here are some proposals: - SAR the packet. - Send it over a signaling channel with additional delay. - Make the channels more flexible to handle spurious changes in bandwidth. Keep in mind that the almost negligable delay, if any, induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either. Also keep in mind that the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO. Thanks, Glenn -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Friday, February 15, 2002 5:54 AM To: 'mobile-ip@sunroof.eng.sun.com'; haley@zk3.dec.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Glenn, I'm starting to feel like a broken record. It has been mentioned several times that a receiver that will be harmed by piggybacking has no way of stopping this unless some negotiation is done. It seems that most people are against this option. Hesham -----Original Message----- From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com] Sent: Thursday, February 14, 2002 9:40 PM To: mobile-ip@sunroof.eng.sun.com; haley@zk3.dec.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Why can't we just leave these engineering tradeoffs to particular products? > -----Original Message----- > From: Erik Nordmark [ mailto:Erik.Nordmark@eng.sun.com ] > Sent: Thursday, February 14, 2002 11:32 AM > To: haley@zk3.dec.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation > > > > How can the DT recognize there is a *potential* benefit, but decide > > to kill piggybacking? > > Brian, > > There is a potential benefit it lots of things - I can > envision benefits > in carry BUs as XML over http (but there might be some > disadvantages as well > :-) > > The issue is the engineering tradeoff. > > Erik > > ------_=_NextPart_001_01C1B640.2A347E50 Content-Type: text/html; charset="iso-8859-1" RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
-----Original Message-----
From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se]
Sent: Friday, February 15, 2002 5:54 AM
To: 'mobile-ip@sunroof.eng.sun.com'; haley@zk3.dec.com
Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn,
 
I'm starting to feel like a broken record. It has been
mentioned several times that a receiver that will be harmed
by piggybacking has no way of stopping this
unless some negotiation is done. It seems that
most people are against this option.
 
Hesham
 
 
-----Original Message-----
From: Glenn Morrow [mailto:gmorrow@nortelnetworks.com]
Sent: Thursday, February 14, 2002 9:40 PM
To: mobile-ip@sunroof.eng.sun.com; haley@zk3.dec.com
Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Why can't we just leave these engineering tradeoffs to particular products?

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> Sent: Thursday, February 14, 2002 11:32 AM
> To: haley@zk3.dec.com
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
>
>
> > How can the DT recognize there is a *potential* benefit, but decide
> > to kill piggybacking?
>
> Brian,
>
> There is a potential benefit it lots of things - I can
> envision benefits
> in carry BUs as XML over http (but there might be some
> disadvantages as well
> :-)
>
> The issue is the engineering tradeoff.
>
>   Erik
>
>

------_=_NextPart_001_01C1B640.2A347E50-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 11:50:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11036 for ; Fri, 15 Feb 2002 11:50:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10469; Fri, 15 Feb 2002 09:49:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09333; Fri, 15 Feb 2002 08:49:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGnAKL009496 for ; Fri, 15 Feb 2002 08:49:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGnA9u009495 for mobile-ip-dist; Fri, 15 Feb 2002 08:49:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGn7KL009488 for ; Fri, 15 Feb 2002 08:49:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07718 for ; Fri, 15 Feb 2002 08:49:09 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00801 for ; Fri, 15 Feb 2002 09:49:08 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA23216; Fri, 15 Feb 2002 08:49:07 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FGn6l29064; Fri, 15 Feb 2002 08:49:06 -0800 X-mProtect:  Fri, 15 Feb 2002 08:49:06 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd45Ieqf; Fri, 15 Feb 2002 08:49:04 PST Message-ID: <3C6D3B9E.8FA523FB@iprg.nokia.com> Date: Fri, 15 Feb 2002 08:47:26 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Hesham's note about security and Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA2B@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, This has, by now, a lot less to do with piggybacking. I ask you to avoid mixing all the discussions together. I have relabeled this e-mail accordingly. "Hesham Soliman (ERA)" wrote: > => My points are: > > - what is the identity used to establish an SA? Presumably, the home address. However, I didn't make a user guide for manual configuration. I only say that the result will be a BSA (Binding Security Association) that will be useful for authenticating Binding Updates from a particular care-of address. Just like the home agent has been doing all along. > - Just because you have an SA with > that identity does that mean that they can > modify your routing table (that's effectively > what a BU does). The purpose of the BSA is to enable the recipient to modify the Binding Cache with updated information. This is the very central purpose of the Binding Update, and is just like what the home agent does. > The ownership of a HoA does NOT give you the right > to forward traffic to any address (CoA) on > the Internet. This is why I said that the > second option was not valid. But i clearly > said it wrongly, probably because of the > time I wrote it! We were supposed to be talking about piggybacking. Your question is related to BU authorization in general, and I am behind on that subject. > > > The former has the authorisation problems > > > that PKI have. > > > > We are not dealing with NAI, but anyway it does not > > matter. As shown by AAA for Mobile IPv4, a AAA > > server can securely check the credentials of a mobile > > node which is using NAI. Thus, both of your assertions > > are incorrect. > > => What's AAA doing here? My response > was on manually configured SAs! You mentioned something that looks like a NAI. My experience with NAIs is that they are useful with AAA-based authorization. I'll happily forget that you brought it up :-) > > > => The links I refer to implement MTU correctly, > > > it's not an MTU issue. > > > > It is an MTU issue. It is trivially solvable by QoS methods. > > => I do not know why you assert that it's > MTU related. MTU has nothing to do with this. If the link can carry 1280 bytes, it can carry Binding Update. Thus it is exactly an MTU issue. Your whole point is to get Binding Update out of the data channel, and you are mistakenly using a very brute force approach to doing this. > What are the trivial QoS methods?? To sketch: Application endpoint A asks for X bits/sec data, Y bits/sec control. Application endpoint B says yes. A sends <= bits over the data channel. A sends <= Y bits/sec over the control channel. Endpoint B does not MAKE endpoint A mash together the data and control, and endpoint B _DOES_ respect endpoint A's request for QoS on the available channels. Is that enough, or do I have to work harder to be clear? Can you at least try to see what I have to say? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 11:59:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11271 for ; Fri, 15 Feb 2002 11:59:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16625; Fri, 15 Feb 2002 09:59:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12388; Fri, 15 Feb 2002 08:59:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGwJKL009631 for ; Fri, 15 Feb 2002 08:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FGwJ1n009630 for mobile-ip-dist; Fri, 15 Feb 2002 08:58:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FGwGKL009623 for ; Fri, 15 Feb 2002 08:58:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25281 for ; Fri, 15 Feb 2002 08:58:18 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16026 for ; Fri, 15 Feb 2002 09:58:18 -0700 (MST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FGwHL20029 for ; Fri, 15 Feb 2002 10:58:17 -0600 (CST) Message-ID: <3C6D3E1E.8070806@alcatel.com> Date: Fri, 15 Feb 2002 10:58:06 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation References: <933FADF5E673D411B8A30002A5608A0E0215FA7B@zrc2c012.us.nortel.com> Content-Type: multipart/alternative; boundary="------------030905060301080106000606" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------030905060301080106000606 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Glenn, Charlie, and all, I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG. I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work. It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world. Let me also note that I only have a very primitive knowledge of the security issues. Regards, Glenn Morrow wrote: > Hesham, > > > > I too, am starting to feel like a broken record so I think we should > perhaps digress into the link layer space of the particular access > technology you believe will be damaged. Please let me know which > access specific link layer technology you are referring to? This will > be doing access work but gee if it is going to keep access specific > arguments out of the IETF work, I suppose I'm game for coming up with > an access and media specific solution to the problem i.e. I guess I'll > try to help improve the least common denominators. > > > > Here are some proposals: > > > > - SAR the packet. > > - Send it over a signaling channel with additional delay. > > - Make the channels more flexible to handle spurious changes in bandwidth. > > > > Keep in mind that the almost negligable delay, if any, induced by > some of these solutions will not happen very often. I also urge you to > drive down the highway right now with an existing cell phone and see > if you notice some delay during handoff. I know you could get a > perfect one under some circumstances but just keep doing it and you'll > find that some "engineering choices" have been made on particular > deployments, let alone particular products. My point here is "get > real". The last proposal which I think is what the Nokia contingent > has been saying doesn't even have this theoretic no delay mumbo jumbo > point either. > > > > Also keep in mind that the mobile could be configured to tell the > CN(MN) not to send it bundled in the future after the 1st one. This > also seems like a prudent engineering choice. But gee, I haven't seen > any of these mythical sort of IP VOIP 3G handsets deployed that would > have this problem in the future and the way the financiers and vendor > plans are going lately with respect to alternatives I'm not sure if we > ever will. > > > > There - now I've been completely politically incorrect but I hope this > points out again just like an old broken record the flaw in the > arguments against bundling. And again, I would like to remind people > in a completely agnostic manner that this is the IETF and not a > cellular SDO and that to technically use the excuse for decision you > have used below would signal to me that the IETF is behaving like an > access specific cellular SDO. > > > > Thanks, > > > > Glenn > > > behcet --------------030905060301080106000606 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet

--------------030905060301080106000606-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:05:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11545 for ; Fri, 15 Feb 2002 12:05:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19067; Fri, 15 Feb 2002 10:05:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14585; Fri, 15 Feb 2002 09:05:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FH4SKL009721 for ; Fri, 15 Feb 2002 09:04:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FH4Stg009720 for mobile-ip-dist; Fri, 15 Feb 2002 09:04:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FH4PKL009713 for ; Fri, 15 Feb 2002 09:04:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14294 for ; Fri, 15 Feb 2002 09:04:28 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26315 for ; Fri, 15 Feb 2002 10:04:27 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id <1L6R3H0Q>; Fri, 15 Feb 2002 11:58:09 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 11:58:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B641.F1E8D242" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B641.F1E8D242 Content-Type: text/plain Not really. The DT makes recommendations which are subject to working group discussion and decision. The DT has made a recommendation and the WG is discussing it. Once some decision is reached we'll ask the DT to go off and draft text or (use some text that someone else has drafted). -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, February 15, 2002 11:58 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Glenn, Charlie, and all, I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG. I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work. It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world. Let me also note that I only have a very primitive knowledge of the security issues. Regards, Glenn Morrow wrote: Hesham, I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators. Here are some proposals: - SAR the packet. - Send it over a signaling channel with additional delay. - Make the channels more flexible to handle spurious changes in bandwidth. Keep in mind that the almost negligable delay, if any, induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either. Also keep in mind that the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO. Thanks, Glenn behcet ------_=_NextPart_001_01C1B641.F1E8D242 Content-Type: text/html Message
 
Not really.  The DT makes recommendations which are subject to working group discussion and decision.  The DT has made
a recommendation and the WG is discussing it.  Once some decision is reached we'll ask the DT to go off and draft text or
(use some text that someone else has drafted).
 
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 11:58 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet

------_=_NextPart_001_01C1B641.F1E8D242-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:09:49 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11820 for ; Fri, 15 Feb 2002 12:09:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21293; Fri, 15 Feb 2002 10:09:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16003; Fri, 15 Feb 2002 09:09:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FH8UKL009877 for ; Fri, 15 Feb 2002 09:08:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FH8UcP009876 for mobile-ip-dist; Fri, 15 Feb 2002 09:08:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FH8RKL009869 for ; Fri, 15 Feb 2002 09:08:27 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15859 for ; Fri, 15 Feb 2002 09:08:29 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24950 for ; Fri, 15 Feb 2002 09:08:27 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FH8NN27475 for ; Fri, 15 Feb 2002 11:08:23 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CQJD>; Fri, 15 Feb 2002 11:08:23 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240213D3D7@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: mobile-ip@sunroof.eng.sun.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 11:08:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B643.5F7212A0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B643.5F7212A0 Content-Type: text/plain; charset="iso-8859-1" >It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world. It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares. -Kuntal -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, February 15, 2002 10:58 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Glenn, Charlie, and all, I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG. I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work. It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world. Let me also note that I only have a very primitive knowledge of the security issues. Regards, Glenn Morrow wrote: Hesham, I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators. Here are some proposals: - SAR the packet. - Send it over a signaling channel with additional delay. - Make the channels more flexible to handle spurious changes in bandwidth. Keep in mind that the almost negligable delay, if any, induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either. Also keep in mind that the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO. Thanks, Glenn behcet ------_=_NextPart_001_01C1B643.5F7212A0 Content-Type: text/html; charset="iso-8859-1" RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
>It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world.
 
It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares.
 
-Kuntal
 
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 10:58 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet

------_=_NextPart_001_01C1B643.5F7212A0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:10:33 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11896 for ; Fri, 15 Feb 2002 12:10:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21946; Fri, 15 Feb 2002 10:10:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16377; Fri, 15 Feb 2002 09:10:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FH9SKL009918 for ; Fri, 15 Feb 2002 09:09:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FH9SrX009917 for mobile-ip-dist; Fri, 15 Feb 2002 09:09:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FH9OKL009904 for ; Fri, 15 Feb 2002 09:09:24 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29253 for ; Fri, 15 Feb 2002 09:09:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23129 for ; Fri, 15 Feb 2002 09:09:24 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA24042; Fri, 15 Feb 2002 09:05:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FH53b18927; Fri, 15 Feb 2002 09:05:03 -0800 X-mProtect:  Fri, 15 Feb 2002 09:05:03 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2FuQeV; Fri, 15 Feb 2002 09:05:00 PST Message-ID: <3C6D3F5E.3A97EA64@iprg.nokia.com> Date: Fri, 15 Feb 2002 09:03:26 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA2A@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > Carrying IP information in an IP packet is architecturally > > a very good idea. And, IP packets are designed to have > > payload. So, carrying payload along with IP information > > in an IP packet is still a very good idea. > > => Provided the payload's needs are known. > If part of the payload requires different > treatment from the rest, then it doesn't > make any sense to include both in the > same IP packet. The payload has its needs. Specific needs for the Binding Update are met by using the Binding Authentication Data suboption. > > > > > Hence placing 2 different sets of information (each > > > requiring a different treatment) in one > > > packet is likely to break some policies. > > > > IP information requires handling at the IP layer, > > and we already have a complete specification for > > that. I don't think you can show any broken policies > > with the way things are now. > > => ?? I realise that IP requires handling > at the IP layer. When you say 'the way things > are now', are you referring to MIPv6 or > IP in general? I am referring to Mobile IPv6. But it's also true for IPv6 :-) > including > > the management of control signals, as well as > > various kinds of payloads. > > => Sure, but 'various kinds of payloads' in various > packets is fine, whereas 'various kinds of payloads' > in the same packet is not good. > Can you give me a concrete example about how > this can be handled in terms of doing the > 'right thing' for each of the different types > of payload, at the same time ? I don't know what "this" is, but: - Binding Authentication Data suboption can always be used to authenticate Binding Updates. - IPsec AH can be used, with special handling and key negotiation, to authenticate Binding Updates if there is no payload. that is, assuming we get the spec out before they invalidate use of AH. > Even if there is such example (I don't know if > there is), the point is, this is a bad protocol > architecture. I strongly disagree with this characterization, and I am ever more certain that you cannot support it. > Speaking concretely, > > any QoS negotiation should trivially be able to > > configure transmission of Binding Updates according > > to the needs of the particular link-layer that you are > > concerned with. > > => Of course, but this is not the point. If one packet > contains a BU (requires channel configuration X) and > another application payload (requires channel config Y). > I don't see a trivial way of selecting a single > channel for this single packet. You can't put a round peg in a square hole of equal area. If this point is not clear, after all I have written about it, then let me know and I will try again. To summarize, if your application has particular QoS requirements, then it is easy to make the QoS negotiation satisfy those requirements. To reduce performance on ALL link layers, especially if it is because of unwillingness to allow your particular link-layer to follow IPv6 requirements, is not legitimate. > > Seen in this way, which I suggest is architecturally > > much more sound, the problem just goes away > > naturally. > > => i must have missed something above, because > I don't know how you reached that conclusion. Do you see now? > => The payload size is not the big issue here. > > but ALL IPv6 link-layers > > have to be able to do that. > > => They sure do, but for a price: additional > significant delays. Again, this is simply not correct. The additional delay only happens for link layers which SHOULD do the appropriate negotiation, but fail to do so. Their only remedy is to enforce their QoS requirements on every other link layer. Not fair! Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:17:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12178 for ; Fri, 15 Feb 2002 12:17:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28158; Fri, 15 Feb 2002 10:17:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01490; Fri, 15 Feb 2002 09:17:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHGPKL010025 for ; Fri, 15 Feb 2002 09:16:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHGPAk010024 for mobile-ip-dist; Fri, 15 Feb 2002 09:16:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHGMKL010017 for ; Fri, 15 Feb 2002 09:16:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25819; Fri, 15 Feb 2002 09:16:24 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25591; Fri, 15 Feb 2002 10:16:24 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FHGKN29259; Fri, 15 Feb 2002 11:16:20 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CQN1>; Fri, 15 Feb 2002 11:16:20 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0215FB7A@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Hesham Soliman (ERA)" , "'Erik Nordmark'" , "'Charles E. Perkins'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Fri, 15 Feb 2002 11:16:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B644.7BC9AB10" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B644.7BC9AB10 Content-Type: text/plain; charset="iso-8859-1" Hesham, Excuse me for misinterpreting and jumping to conclusions but technically why is it a bad idea, especially when there is no checksum in the IPv6 header? I don't see a problem with it. > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Friday, February 15, 2002 10:06 AM > To: Morrow, Glenn [RICH2:C330:EXCH]; Hesham Soliman (ERA); 'Erik > Nordmark'; 'Charles E. Perkins' > Cc: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > > There is no technical or logical argument to your point > given. You are just saying I think this is bad without giving > any meat to the argument. > > => Good feedback (no I'm not serious). > > I do not agree with you on this view. Network services are > network services and right now MIPv6 is not a network service > in that the network does not participate other than > forwarding i.e. there is no LMM and there is no FMIP in the > MIPv6 spec. So since MIPv6 standalone is not a network > service right now, your points are invalid. > > =>Glenn, What are you talking about ? Did you really > read anything below? I'm talking about this: > > - Placing more than one payload in the packet, each > requiring different level of QoS, security or any > other handling, is a bad idea. > > Who said anything about LMM or FMIP???? > > Hesham > ------_=_NextPart_001_01C1B644.7BC9AB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

Hesham,

Excuse me for misinterpreting and jumping to = conclusions but technically why is it a bad idea, especially when there = is no checksum in the IPv6 header? I don't see a problem with = it.

> -----Original Message-----
> From: Hesham Soliman (ERA) [mailto:hesham.soliman@era= .ericsson.se]
> Sent: Friday, February 15, 2002 10:06 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]; Hesham = Soliman (ERA); 'Erik
> Nordmark'; 'Charles E. Perkins'
> Cc: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking = - DT recommendation]
>
>
>
>
> There is no technical or logical argument to = your point
> given. You are just saying I think this is bad = without giving
> any meat to the argument.
>
> =3D> Good feedback (no I'm not = serious).
>
> I do not agree with you on this view. Network = services are
> network services and right now MIPv6 is not a = network service
> in that the network does not participate other = than
> forwarding i.e. there is no LMM and there is no = FMIP in the
> MIPv6 spec. So since MIPv6 standalone is not a = network
> service right now, your points are invalid. =
>
> =3D>Glenn, What are you talking about ? Did = you really
> read anything below? I'm talking about = this:
>
> - Placing more than one payload in the packet, = each
>   requiring different level of QoS, = security or any
>   other handling, is a bad = idea.
>
> Who said anything about LMM or FMIP????
>
> Hesham
>

------_=_NextPart_001_01C1B644.7BC9AB10-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:26:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12492 for ; Fri, 15 Feb 2002 12:26:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02030; Fri, 15 Feb 2002 10:26:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04276; Fri, 15 Feb 2002 09:26:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHPEKL010133 for ; Fri, 15 Feb 2002 09:25:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHPEJR010132 for mobile-ip-dist; Fri, 15 Feb 2002 09:25:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHPBKL010125 for ; Fri, 15 Feb 2002 09:25:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21429 for ; Fri, 15 Feb 2002 09:25:13 -0800 (PST) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15662 for ; Fri, 15 Feb 2002 09:25:13 -0800 (PST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FHPCL28136 for ; Fri, 15 Feb 2002 11:25:12 -0600 (CST) Message-ID: <3C6D446E.5050406@alcatel.com> Date: Fri, 15 Feb 2002 11:25:02 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation References: <23BDB0046F3ED51185CD0002A5608D240213D3D7@zrc2c009.us.nortel.com> Content-Type: multipart/alternative; boundary="------------070107080102080908030105" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------070107080102080908030105 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kuntal, Recently RFC2002 was modified to become RFC2002bis and then RFC3220. Did this cause backward compatibility nightmares? I think that you are talking about some cyber authority making RFCs that never change. We all know in the telecom world, the standards change sometimes completely! So I stand by my argument. Kuntal Chowdhury wrote: > > It could also be noted that whatever the solutions to be agreed this > time under time pressure may always be improved upon later on with > additional RFCs or RFC >xxx-bis's. It is not end of the world. > > > > It is always a bad idea to rush into a solution under time pressure to > get an RFC number. This kind of approach always results in backward > compatibility nightmares. > > > > -Kuntal > > > > > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Friday, February 15, 2002 10:58 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation > > Glenn, Charlie, and all, > I have a feeling that Charlie and Glenn and possibly others > coming up with solutions of their own defeats the purpose of the > design team set up by the WG cochairs and to my knowledge agreed > by the WG. > I suggest that DT makes a conference call with these people once > and for all and gets their input and continues its work. > It could also be noted that whatever the solutions to be agreed > this time under time pressure may always be improved upon later on > with additional RFCs or RFC xxx-bis's. It is not end of the world. > Let me also note that I only have a very primitive knowledge of > the security issues. > > Regards, > > Glenn Morrow wrote: > >> Hesham, >> >> >> >> I too, am starting to feel like a broken record so I think we >> should perhaps digress into the link layer space of the >> particular access technology you believe will be damaged. Please >> let me know which access specific link layer technology you are >> referring to? This will be doing access work but gee if it is >> going to keep access specific arguments out of the IETF work, I >> suppose I'm game for coming up with an access and media specific >> solution to the problem i.e. I guess I'll try to help improve the >> least common denominators. >> >> >> >> Here are some proposals: >> >> >> >> - SAR the packet. >> >> - Send it over a signaling channel with additional delay. >> >> - Make the channels more flexible to handle spurious changes in >> bandwidth. >> >> >> >> Keep in mind that the almost negligable delay, if any, induced >> by some of these solutions will not happen very often. I also >> urge you to drive down the highway right now with an existing >> cell phone and see if you notice some delay during handoff. I >> know you could get a perfect one under some circumstances but >> just keep doing it and you'll find that some "engineering >> choices" have been made on particular deployments, let alone >> particular products. My point here is "get real". The last >> proposal which I think is what the Nokia contingent has been >> saying doesn't even have this theoretic no delay mumbo jumbo >> point either. >> >> >> >> Also keep in mind that the mobile could be configured to tell >> the CN(MN) not to send it bundled in the future after the 1st >> one. This also seems like a prudent engineering choice. But gee, >> I haven't seen any of these mythical sort of IP VOIP 3G handsets >> deployed that would have this problem in the future and the way >> the financiers and vendor plans are going lately with respect to >> alternatives I'm not sure if we ever will. >> >> >> >> There - now I've been completely politically incorrect but I hope >> this points out again just like an old broken record the flaw in >> the arguments against bundling. And again, I would like to remind >> people in a completely agnostic manner that this is the IETF and >> not a cellular SDO and that to technically use the excuse for >> decision you have used below would signal to me that the IETF is >> behaving like an access specific cellular SDO. >> >> >> >> Thanks, >> >> >> >> Glenn >> >> >> > behcet > -- Behcet --------------070107080102080908030105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kuntal,
  Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
Did this cause backward compatibility nightmares?
  I think that you are talking about some cyber authority making RFCs that never change.
We all know in the telecom world, the standards change sometimes completely!

  So I stand by my argument.

Kuntal Chowdhury wrote:
RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
> It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world.
 
It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares.
 
-Kuntal
 

-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 10:58 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet


-- 
Behcet 

--------------070107080102080908030105-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:38:55 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13160 for ; Fri, 15 Feb 2002 12:38:55 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09401; Fri, 15 Feb 2002 09:38:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09065; Fri, 15 Feb 2002 09:38:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHbhKL010217 for ; Fri, 15 Feb 2002 09:37:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHbhjs010216 for mobile-ip-dist; Fri, 15 Feb 2002 09:37:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHbdKL010209 for ; Fri, 15 Feb 2002 09:37:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01252 for ; Fri, 15 Feb 2002 09:37:42 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10181 for ; Fri, 15 Feb 2002 10:37:40 -0700 (MST) Received: from chardonnay (ipunplugged.com [192.168.4.5]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA15739 for ; Fri, 15 Feb 2002 18:35:33 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 18:37:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <015f01c1b589$9ed9b7a0$7e6015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > > > > > If changes are required in IPsec, then I think we ought > > > to ask for them. > > > > How long do you suggest we should delay MIPv6 while waiting for such > changes > > to IPsec specifications? > > > > If we don't start now, it will take even longer to get the change. I > don't > understand why we couldn't simply allow piggybacking > with the caveat that you shouldn't use it with IPSec, then start > working with the IPSec group to come up with a solution that will work. > The MN doesn't have to send the BU as part of an IPSec secured > TCP stream, it could send it separately. > To me, this seems to offer a workable compromise. If the major trouble with piggybacking BU's is in the granularity of IPsec selectors, so piggybacking when IPsec's in use gives trouble, -- why, let us allow optional piggybacking where there is no problem, and disallow them (for now) where we have no clear way forward? Best, Henrik From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:39:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13214 for ; Fri, 15 Feb 2002 12:39:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17618; Fri, 15 Feb 2002 10:39:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09581; Fri, 15 Feb 2002 09:39:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHcjKL010243 for ; Fri, 15 Feb 2002 09:38:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHcj9w010242 for mobile-ip-dist; Fri, 15 Feb 2002 09:38:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHcfKL010232 for ; Fri, 15 Feb 2002 09:38:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25841 for ; Fri, 15 Feb 2002 09:38:44 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA10849 for ; Fri, 15 Feb 2002 10:38:43 -0700 (MST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id <1M410WN3>; Fri, 15 Feb 2002 18:38:41 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1M4A4SPH; Fri, 15 Feb 2002 18:38:38 +0100 From: "Jean-Michel COMBES" To: "Mobile IP Working Group" Subject: RE: [mobile-ip] A new proposal for handling Home Address destination options Date: Fri, 15 Feb 2002 18:38:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C6D2ED6.87BB2BF0@iprg.nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, > -----Message d'origine----- > De : Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Envoye : vendredi 15 fevrier 2002 16:53 > A : COMBES jean-michel FTRD/DTL > Cc : Mobile IP Working Group > Objet : Re: [mobile-ip] A new proposal for handling Home Address > destination options > > > [snip] > > > > *** Case 1 : Vict@ is in the reflector's BC *** > > - the victim is a MN with H@ = Vict@ = MN-H@ > > - the MN is registered with a Co@ = MN-Co@ > > The reflector sends a packet looks like : > > IPv6Src: Refl@ > > IPv6Dst: MN-Co@ > > "RH" : Vict@ = MN-H@ > > It took me a while to figure out that BC == "Binding Cache"... JMC : sorry ... > > > Then two sub-cases : > > > > *** Case 1a : MN location is still MN-Co@ *** > > Solution : if the MN is equipped with a personal firewall, then > the packet > > is rejected. > > > > *** Case 1b : MN location is not MN-Co@ *** > > Solution : ??? > > In this case, there is absolutely no problem. Since the mobile node > has an entry in the correspondent node's Binding Cache, then the > mobile node has established that Binding Cache entry by some means > that supplied the care-of address for that Binding Cache entry. > If the care-of address does not match what's in the Home Address > Option, then the packet is dropped. This is the "verifiable" case > in my proposal, and as I indicated in my note, this is to follow the > recommendation of the design team -- namely, if the are Binding > Cache entries for the home address, and none of them match the > care-of address sent in the Home Address option, the packet is > dropped (perhaps also logged for security). JMC : And what happens in the case where the CN has not received the new MN location (ie. the new MN-Co@) ? > > > *** Case 2 : Vict@ is not in the reflector's BC *** > > The reflector sends a packet looks like : > > IPv6Src: Refl@ > > IPv6Dst: Vict@ > > > > Then two sub-cases : > > > > *** Case 2a : the victim is a MN *** > > Solution : your proposition > > > > *** Case 2b : the victim is not a MN *** > > Solution : ??? > > In case 2b, the firewall should drop packets destined for a network > that does not have mobile nodes, but that have the care-of address tag. > I did mention this in my proposal. > > > > In order to make a good design, we must first distinguish between > > > a verifiable Home Address options (vHAO), and unverifiable Home > > > Address options (UnvHAO). A vHAO is a home address option that > > > contains a care-of address > > > > JMC : > > Typo ? You mean a Home Address, do you ? > > No, but I still didn't say what I meant. I meant that the vHAO is a home > address option in a packet which contains a care-of address which is > verifiably associated with the mobile node's home address. JMC : OK ... I see now :-) [snip] > > > > > > The other simple mechanisms which further reduce or eliminate > > > vulnerability to the reflector attack are simple rate and > > > capacity limitations at the correspondent node. Any correspondent > > > node should only have a limited capacity for such UnvHOAs (perhaps > > > 5 or so, but configurable and perhaps larger for big servers). > > > > JMC : > > what happens if the attack is distributed (ie. the bad guy sends forged > > packets to many reflectors) ? > > Then the bad guy has done exactly the same thing, but less efficiently, > than sending all the packets itself to the victim. It would be faster for > the bad guy to just forget about this useless method of attack. Plus the > attack is eminently traceable. JMC : I meant what happens when the bad guy sends forged packets to many reflectors to attack the same victim ? Example : IPv6Src: Attk@, IPv6Dst: Refl@#1, H@-DO : Vict@ IPv6Src: Attk@, IPv6Dst: Refl@#2, H@-DO : Vict@ IPv6Src: Attk@, IPv6Dst: Refl@#3, H@-DO : Vict@ ... IPv6Src: Attk@, IPv6Dst: Refl@#n, H@-DO : Vict@ with Refl@#1 the address of the reflector host #1, Refl@#2 the address of the reflector host #2, etc. > > I do not think this remaining threat is at all worthy of amputating useful > protocol functionality. > > > Regards, > Charlie P. > Thanks for your comments. Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:42:14 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13367 for ; Fri, 15 Feb 2002 12:42:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10463; Fri, 15 Feb 2002 09:42:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10562; Fri, 15 Feb 2002 09:41:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHfGKL010354 for ; Fri, 15 Feb 2002 09:41:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHfGL5010353 for mobile-ip-dist; Fri, 15 Feb 2002 09:41:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHfDKL010346 for ; Fri, 15 Feb 2002 09:41:13 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26823 for ; Fri, 15 Feb 2002 09:41:16 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12022 for ; Fri, 15 Feb 2002 09:41:15 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1FHfEt12867; Fri, 15 Feb 2002 09:41:14 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX06010; Fri, 15 Feb 2002 09:40:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA28143; Fri, 15 Feb 2002 09:41:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.18489.713135.180163@thomasm-u1.cisco.com> Date: Fri, 15 Feb 2002 09:41:13 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: "Hesham Soliman (ERA)" Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation In-Reply-To: <3C6D22B2.29E9CAB4@iprg.nokia.com> References: <4DA6EA82906FD511BE2F00508BCF053802C6AA1F@Esealnt861.al.sw.ericsson.se> <3C6D22B2.29E9CAB4@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins writes: > Hesham, > > A receiver that cannot receive such packets is not obeying > the IPv6 specification. A receiver that wants to have > specialized handling for control messages has to bear > the burden of further negotiation, since it is no longer > a connectionless (i.e., "IP"-style) link. Even so, this > is trivially manageable. > > It seems to me that most people are in favor of having > this flexibility. I think we should let the WG chairs decide this. From what I can tell, there has been no movement toward consensus here as all of the same arguements are being repeated. > I also wonder why the "anti-" people > are so hard line, when they already can have everything > that they putatively want. This statement underscores that the two sides are still not communicating. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:44:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13516 for ; Fri, 15 Feb 2002 12:44:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11128; Fri, 15 Feb 2002 09:44:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11234; Fri, 15 Feb 2002 09:44:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHhXKL010424 for ; Fri, 15 Feb 2002 09:43:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHhX4x010423 for mobile-ip-dist; Fri, 15 Feb 2002 09:43:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHhTKL010416 for ; Fri, 15 Feb 2002 09:43:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02735 for ; Fri, 15 Feb 2002 09:43:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13093 for ; Fri, 15 Feb 2002 09:43:29 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA26898; Fri, 15 Feb 2002 09:43:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FHhPt23403; Fri, 15 Feb 2002 09:43:25 -0800 X-mProtect:  Fri, 15 Feb 2002 09:43:25 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlXIov3; Fri, 15 Feb 2002 09:43:22 PST Message-ID: <3C6D4858.8747AEEB@iprg.nokia.com> Date: Fri, 15 Feb 2002 09:41:44 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <3C6D140E.3020900@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Charlie, > > IMHO, I think that you proposal has quite a lot of value, > thanks for working it out and posting it. Thanks! My goal is to maintain the important functionality which allows a mobile node to avoid reverse tunneling in many cases not conveniently solvable by establishment of a BSA. This whole issue is actually part of the larger issue of teasing out the dual roles of the IP address as locator vs. as identifier. I hope you will agree with me that we should try to avoid avenues of discourse that seem likely to fall irretrievably into that design area. I am hoping we can get a good solution that doesn't require solving the larger problem. ... deleted description of concrete application of proposed tagging ... > > if Victor employs the firewalling method, i.e. if he drops > all packets tagged with a CoA tag, it is very easy to cause > Denial-of-Service. Sending a single packet with an arbitrary > source address and a HAO with HoA of Victor's address does that. > That is, the attacker Mallory sends a single packet, perhaps > even from his own address, with a HOA that contains Victor's > address 3ff0:200:2 to the CN. This causes the CN to create > the flagged BCE, as described above. As a result, all future > packets that the CN sends to Victor will be tagged with the > CoA tag. And this causes Victor's firewall to drop the packets. I understand the problem. > To summarize and generalize, using the BCE method for storing > information about received HAOs and for tagging outgoing packets > is not a good idea. It is too easy to enter bogus information > into the BCE, thereby causing bogus tagging of outgoing packets. I have a truly outlandish and perfect solution to this problem, except that it may not be the most economical or parsimonious. But it is so "different" that I think I will seek another approach for now, in order to find the most economical solution. I think the first noteworthy aspect is that it is a platform issue, and may not require additional protocol. Nevertheless, I agree with you that we want to have protocol that is implementable, so we need an existence proof. > Let us now consider what looks like the right way of implementing > this. IMHO, the right way would be to more rigoriously > associate requests containing the HAO and related replies > that need to be tagged. For TCP and connected UDP sockets > this seems to be achieveable, since the information about > the received HAO and CoA can be stored in the socket. The > unconnected UDP sockets are the problem, though. There the > kernel does not create any state where the HAO or CoA could > be stored. Consequently, the only reasonable option would be > to pass the information to the user level. This, in turn, > would mean API changes. To the zeroth level, I would be satisfied with a solution that only works for connected sockets. I do not think it would be wise at this point to require changes to user programs. However, I would have to go back and try to see what common UDP applications do with their sockets. What about DNS? More to the point, if we agree that it is a platform issue, then we can evolve the platform solution in time as we get more experience. > One way to extend the API would be to include space into > sockaddr_in6 for the care-of-address. Unfortunately that would > increase the size of the struct, and as a result some applications > might break. On the other hand, most applications these days > use sockaddr_storage anyway, so that doesn't matter so much. > One bit could be stolen from e.g. flowinfo or scope_id to indicate > whether the added space contains a CoA or some other information. I would militate against using a flowlabel bit unless there were not any other mechanism. > If adding extra space to the sockaddr_in6 would be considered too > big a change, there are hacks we could make. For example, most > unconnected UDP sockets don't have _that_ many outstanding requests > anyway. Thus, it _might_ be possible to use e.g. the scope_id > field to indicate that the packet was received with a HAO, and > cache the HAO in the kernel space for a few seconds. However, > such solutions are hacks. That's a pretty big hack! > Thus, the best way seems to be adding more space to sockaddr_in6, > using that space to store CoA (if there is one), and stealing one > bit either from flowinfo or scope_id to indicate whether the CoA > field is used or not. That would have the additional benefit that > also other system calls used to report peer addresses (e.g. > getpeername) would also report the CoA, if it exists. Well, maybe > we would need to steal another bit, too. That would indicate > whether the CoA is one just received in a HAO, or one authorized > through RR or RR+CGA. I'm O.K. with most of this discussion. I just hope you can agree that we can get most of the way there sooner, and let platforms evolve as need be. Do you like my staged evolution approach? I believe it shows we can get there, and in the near term before the final platform issues are solved we can still have Proposed Standard. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:48:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13751 for ; Fri, 15 Feb 2002 12:48:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15058; Fri, 15 Feb 2002 10:48:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12966; Fri, 15 Feb 2002 09:48:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHlNKL010503 for ; Fri, 15 Feb 2002 09:47:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHlMZ3010502 for mobile-ip-dist; Fri, 15 Feb 2002 09:47:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHlJKL010495 for ; Fri, 15 Feb 2002 09:47:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04248 for ; Fri, 15 Feb 2002 09:47:22 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22222 for ; Fri, 15 Feb 2002 10:47:22 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FHlKN06079 for ; Fri, 15 Feb 2002 11:47:20 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CQ60>; Fri, 15 Feb 2002 11:47:20 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240213D557@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: mobile-ip@sunroof.eng.sun.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 11:47:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B648.D0468E70" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B648.D0468E70 Content-Type: text/plain; charset="iso-8859-1" > Recently RFC2002 was modified to become RFC2002bis and then RFC3220. > Did this cause backward compatibility nightmares? It seems, you are very sure it does not! To my knowledge, RFC 3220 is far from being widely deployed and tested? > I think that you are talking about some cyber authority making RFCs that never change. Also, cyber authorities should not publish RFCs which need to be obsoleted every now and then. Had the IETF followed your suggestion, then this whole internet would have been a real management nightmare. > We all know in the telecom world, the standards change sometimes completely! Successful telecom standards are not defined in a hurry and they do not change like the way you are advocating. -Kuntal -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, February 15, 2002 11:25 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Kuntal, Recently RFC2002 was modified to become RFC2002bis and then RFC3220. Did this cause backward compatibility nightmares? I think that you are talking about some cyber authority making RFCs that never change. We all know in the telecom world, the standards change sometimes completely! So I stand by my argument. Kuntal Chowdhury wrote: > It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world. It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares. -Kuntal -----Original Message----- From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ] Sent: Friday, February 15, 2002 10:58 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Glenn, Charlie, and all, I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG. I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work. It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world. Let me also note that I only have a very primitive knowledge of the security issues. Regards, Glenn Morrow wrote: Hesham, I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators. Here are some proposals: - SAR the packet. - Send it over a signaling channel with additional delay. - Make the channels more flexible to handle spurious changes in bandwidth. Keep in mind that the almost negligable delay, if any, induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either. Also keep in mind that the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO. Thanks, Glenn behcet -- Behcet ------_=_NextPart_001_01C1B648.D0468E70 Content-Type: text/html; charset="iso-8859-1" RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
> Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
> Did this cause backward compatibility nightmares?
 
It seems, you are very sure it does not! To my knowledge, RFC 3220 is far from being widely deployed and tested?
 
> I think that you are talking about some cyber authority making RFCs that never change.
Also, cyber authorities should not publish RFCs which need to be obsoleted every now and then. Had the IETF followed your suggestion, then this whole internet would have been a real management nightmare.
 
> We all know in the telecom world, the standards change sometimes completely!
Successful telecom standards are not defined in a hurry and they do not change like the way you are advocating.
 
-Kuntal
 
 
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 11:25 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Kuntal,
  Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
Did this cause backward compatibility nightmares?
  I think that you are talking about some cyber authority making RFCs that never change.
We all know in the telecom world, the standards change sometimes completely!

  So I stand by my argument.

Kuntal Chowdhury wrote:
> It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world.
 
It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares.
 
-Kuntal
 

-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 10:58 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet


-- 
Behcet 

------_=_NextPart_001_01C1B648.D0468E70-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 12:55:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14011 for ; Fri, 15 Feb 2002 12:55:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19650; Fri, 15 Feb 2002 10:54:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15513; Fri, 15 Feb 2002 09:54:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHrqKL010596 for ; Fri, 15 Feb 2002 09:53:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FHrpHO010595 for mobile-ip-dist; Fri, 15 Feb 2002 09:53:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FHrmKL010588 for ; Fri, 15 Feb 2002 09:53:48 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00642 for ; Fri, 15 Feb 2002 09:53:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18539 for ; Fri, 15 Feb 2002 09:53:50 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA27498; Fri, 15 Feb 2002 09:53:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FHrme05881; Fri, 15 Feb 2002 09:53:48 -0800 X-mProtect:  Fri, 15 Feb 2002 09:53:48 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0BXxGa; Fri, 15 Feb 2002 09:53:46 PST Message-ID: <3C6D4AC8.84B4AE9D@iprg.nokia.com> Date: Fri, 15 Feb 2002 09:52:08 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Henrik, Henrik Levkowetz wrote in response to James Kempf: > > The MN doesn't have to send the BU as part of an IPSec secured > > TCP stream, it could send it separately. > > > > To me, this seems to offer a workable compromise. If the major > trouble with piggybacking BU's is in the granularity of IPsec selectors, > so piggybacking when IPsec's in use gives trouble, -- why, let us allow > optional piggybacking where there is no problem, and disallow them (for now) > where we have no clear way forward? I basically agree with both of you, with the proviso that even with an IPsec-secured TCP stream, one could include a Binding Update by using the Binding Authentication Data suboption. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 13:15:34 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14564 for ; Fri, 15 Feb 2002 13:15:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18060; Fri, 15 Feb 2002 10:15:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23414; Fri, 15 Feb 2002 10:15:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIEGKL010712 for ; Fri, 15 Feb 2002 10:14:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FIEF6f010711 for mobile-ip-dist; Fri, 15 Feb 2002 10:14:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIECKL010704 for ; Fri, 15 Feb 2002 10:14:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07358 for ; Fri, 15 Feb 2002 10:14:15 -0800 (PST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14981 for ; Fri, 15 Feb 2002 11:14:15 -0700 (MST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g1FIEE716021 for ; Fri, 15 Feb 2002 12:14:14 -0600 (CST) Message-ID: <3C6D4FEB.4080500@alcatel.com> Date: Fri, 15 Feb 2002 12:14:03 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation References: <23BDB0046F3ED51185CD0002A5608D240213D557@zrc2c009.us.nortel.com> Content-Type: multipart/alternative; boundary="------------060208060507010402070509" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------060208060507010402070509 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please note that all IETF WGs work under a charter with certain deadlines, i.e. under time pressure. If there is no time pressure for MIPv6 as you seem to suggest, then let's take it to IRTF the research branch of IETF. Yes RFCs are obsoleted from time to time. So what is your point? I am not advocating anything, it is the WG cochairs who are advocating something. I am just suggesting something purely out of reasonable logic to make better progress in this WG. Regards, Kuntal Chowdhury wrote: > > Recently RFC2002 was modified to become RFC2002bis and then RFC3220. > > Did this cause backward compatibility nightmares? > > > > It seems, you are very sure it does not! To my knowledge, RFC 3220 is > far from being widely deployed and tested? > > > > > I think that you are talking about some cyber authority making RFCs > that never change. > > Also, cyber authorities should not publish RFCs which need to be > obsoleted every now and then. Had the IETF followed your suggestion, > then this whole internet would have been a real management nightmare. > > > > > We all know in the telecom world, the standards change sometimes > completely! > > Successful telecom standards are not defined in a hurry and they do > not change like the way you are advocating. > > > > -Kuntal > > > > > > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Friday, February 15, 2002 11:25 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation > > Kuntal, > Recently RFC2002 was modified to become RFC2002bis and then > RFC3220. > Did this cause backward compatibility nightmares? > I think that you are talking about some cyber authority making > RFCs that never change. > We all know in the telecom world, the standards change sometimes > completely! > > So I stand by my argument. > > Kuntal Chowdhury wrote: > >> > It could also be noted that whatever the solutions to be agreed >> this time under time pressure may always be improved upon later >> on with additional RFCs or RFC >xxx-bis's. It is not end of the >> world. >> >> >> >> It is always a bad idea to rush into a solution under time >> pressure to get an RFC number. This kind of approach always >> results in backward compatibility nightmares. >> >> >> >> -Kuntal >> >> >> >> >> -----Original Message----- >> From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ] >> Sent: Friday, February 15, 2002 10:58 AM >> To: mobile-ip@sunroof.eng.sun.com >> Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation >> >> Glenn, Charlie, and all, >> I have a feeling that Charlie and Glenn and possibly others >> coming up with solutions of their own defeats the purpose of >> the design team set up by the WG cochairs and to my knowledge >> agreed by the WG. >> I suggest that DT makes a conference call with these people >> once and for all and gets their input and continues its work. >> It could also be noted that whatever the solutions to be >> agreed this time under time pressure may always be improved >> upon later on with additional RFCs or RFC xxx-bis's. It is >> not end of the world. >> Let me also note that I only have a very primitive >> knowledge of the security issues. >> >> Regards, >> >> Glenn Morrow wrote: >> >>> Hesham, >>> >>> >>> >>> I too, am starting to feel like a broken record so I think >>> we should perhaps digress into the link layer space of the >>> particular access technology you believe will be damaged. >>> Please let me know which access specific link layer >>> technology you are referring to? This will be doing access >>> work but gee if it is going to keep access specific >>> arguments out of the IETF work, I suppose I'm game for >>> coming up with an access and media specific solution to the >>> problem i.e. I guess I'll try to help improve the least >>> common denominators. >>> >>> >>> >>> Here are some proposals: >>> >>> >>> >>> - SAR the packet. >>> >>> - Send it over a signaling channel with additional delay. >>> >>> - Make the channels more flexible to handle spurious changes >>> in bandwidth. >>> >>> >>> >>> Keep in mind that the almost negligable delay, if any, >>> induced by some of these solutions will not happen very >>> often. I also urge you to drive down the highway right now >>> with an existing cell phone and see if you notice some delay >>> during handoff. I know you could get a perfect one under >>> some circumstances but just keep doing it and you'll find >>> that some "engineering choices" have been made on particular >>> deployments, let alone particular products. My point here is >>> "get real". The last proposal which I think is what the >>> Nokia contingent has been saying doesn't even have this >>> theoretic no delay mumbo jumbo point either. >>> >>> >>> >>> Also keep in mind that the mobile could be configured to >>> tell the CN(MN) not to send it bundled in the future after >>> the 1st one. This also seems like a prudent engineering >>> choice. But gee, I haven't seen any of these mythical sort >>> of IP VOIP 3G handsets deployed that would have this problem >>> in the future and the way the financiers and vendor >>> plans are going lately with respect to alternatives I'm not >>> sure if we ever will. >>> >>> >>> >>> There - now I've been completely politically incorrect but I >>> hope this points out again just like an old broken record >>> the flaw in the arguments against bundling. And again, I >>> would like to remind people in a completely agnostic manner >>> that this is the IETF and not a cellular SDO and that to >>> technically use the excuse for decision you have used below >>> would signal to me that the IETF is behaving like an access >>> specific cellular SDO. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Glenn >>> >>> >>> >> behcet >> > >-- >Behcet > > -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 --------------060208060507010402070509 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Please note that all IETF WGs work under a charter with certain deadlines, i.e. under time pressure. If there is no time pressure for MIPv6 as you seem to suggest, then let's take it to IRTF the research branch of IETF.

Yes RFCs are obsoleted from time to time. So what is your point?

I am not advocating anything, it is the WG cochairs who are advocating something. I am just suggesting something purely out of reasonable logic to make better progress in this WG.

Regards,

Kuntal Chowdhury wrote:
RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
> Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
> Did this cause backward compatibility nightmares?
 
It seems, you are very sure it does not! To my knowledge, RFC 3220 is far from being widely deployed and tested?
 
> I think that you are talking about some cyber authority making RFCs that never change.
Also, cyber authorities should not publish RFCs which need to be obsoleted every now and then. Had the IETF followed your suggestion, then this whole internet would have been a real management nightmare.
 
> We all know in the telecom world, the standards change sometimes completely!
Successful telecom standards are not defined in a hurry and they do not change like the way you are advocating.
 
-Kuntal
 
 
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 11:25 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Kuntal,
  Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
Did this cause backward compatibility nightmares?
  I think that you are talking about some cyber authority making RFCs that never change.
We all know in the telecom world, the standards change sometimes completely!

  So I stand by my argument.

Kuntal Chowdhury wrote:
> It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world.
 
It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares.
 
-Kuntal
 

-----Original Message-----
From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
Sent: Friday, February 15, 2002 10:58 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet


-- 
Behcet 


-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

--------------060208060507010402070509-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 13:22:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14782 for ; Fri, 15 Feb 2002 13:22:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12925; Fri, 15 Feb 2002 11:22:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26426; Fri, 15 Feb 2002 10:22:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FILmKL010773 for ; Fri, 15 Feb 2002 10:21:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FILmd8010772 for mobile-ip-dist; Fri, 15 Feb 2002 10:21:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FILiKL010765 for ; Fri, 15 Feb 2002 10:21:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03012 for ; Fri, 15 Feb 2002 10:21:46 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05031 for ; Fri, 15 Feb 2002 11:21:45 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29618 for ; Fri, 15 Feb 2002 10:21:45 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FILhw12397 for ; Fri, 15 Feb 2002 10:21:43 -0800 X-mProtect:  Fri, 15 Feb 2002 10:21:43 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7DHjZY; Fri, 15 Feb 2002 10:21:42 PST Message-ID: <3C6D51B6.AE3D342C@iprg.nokia.com> Date: Fri, 15 Feb 2002 10:21:42 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] FMIPv6 - Handover Capabilities Extension References: <3C6C74B9.37EC6315@iprg.nokia.com> <007701c1b5cf$ddcafcd0$956015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit There should be some clarification in section 5.1.1 and 5.1.2. They way I read the 'SHOULD', this option has to be there in every ProxyRtrSol and ProxyRtrAdv Thanks Vijay James Kempf wrote: > > Vijay, > > You're right, it isn't needed every time. It is only needed when > the MN first comes up, and when it roams from one coverage > area to another. I think this is discussed in Section 3. > > jak > > ----- Original Message ----- > From: "Vijay Devarapalli" > To: > Sent: Thursday, February 14, 2002 6:38 PM > Subject: [mobile-ip] FMIPv6 - Handover Capabilities Extension > > > hi, > > > > a question regarding the Handover Capabilties Extension (HOCAP) > > option in the Fast MIPv6 draft 03. > > > > should this option be included in ProxyRtrSol and ProxyRtrAdv > > messages? thats what it says in Section 5.1.1 and Section 5.1.2. > > > > but why? for ProxyRtrAdv it makes sense including it when > > the mobile node is about to roam into a coverage area with > > different handover capability. and for ProxyRtrSol too, I am > > not sure we need to include it every time. > > > > Vijay > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 13:32:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14942 for ; Fri, 15 Feb 2002 13:32:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18687; Fri, 15 Feb 2002 11:31:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00055; Fri, 15 Feb 2002 10:31:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIUvKL010859 for ; Fri, 15 Feb 2002 10:30:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FIUucA010858 for mobile-ip-dist; Fri, 15 Feb 2002 10:30:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIUrKL010851 for ; Fri, 15 Feb 2002 10:30:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05321 for ; Fri, 15 Feb 2002 10:30:55 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14810 for ; Fri, 15 Feb 2002 10:30:55 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FIUrN27286 for ; Fri, 15 Feb 2002 12:30:53 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H22JWA>; Fri, 15 Feb 2002 12:30:53 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D240213D691@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: mobile-ip@sunroof.eng.sun.com Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 12:30:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B64E.E6443AA0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B64E.E6443AA0 Content-Type: text/plain; charset="iso-8859-1" Well, I have problem with the statement "Since there is a time pressure for a MIPv6 RFC, lets publish something". It is simply not a wise idea, no matter if a SDO needs MIPv6 RFC by some timeline. -Kuntal -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, February 15, 2002 12:14 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Please note that all IETF WGs work under a charter with certain deadlines, i.e. under time pressure. If there is no time pressure for MIPv6 as you seem to suggest, then let's take it to IRTF the research branch of IETF. Yes RFCs are obsoleted from time to time. So what is your point? I am not advocating anything, it is the WG cochairs who are advocating something. I am just suggesting something purely out of reasonable logic to make better progress in this WG. Regards, Kuntal Chowdhury wrote: > Recently RFC2002 was modified to become RFC2002bis and then RFC3220. > Did this cause backward compatibility nightmares? It seems, you are very sure it does not! To my knowledge, RFC 3220 is far from being widely deployed and tested? > I think that you are talking about some cyber authority making RFCs that never change. Also, cyber authorities should not publish RFCs which need to be obsoleted every now and then. Had the IETF followed your suggestion, then this whole internet would have been a real management nightmare. > We all know in the telecom world, the standards change sometimes completely! Successful telecom standards are not defined in a hurry and they do not change like the way you are advocating. -Kuntal -----Original Message----- From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ] Sent: Friday, February 15, 2002 11:25 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Kuntal, Recently RFC2002 was modified to become RFC2002bis and then RFC3220. Did this cause backward compatibility nightmares? I think that you are talking about some cyber authority making RFCs that never change. We all know in the telecom world, the standards change sometimes completely! So I stand by my argument. Kuntal Chowdhury wrote: > It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world. It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares. -Kuntal -----Original Message----- From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ] Sent: Friday, February 15, 2002 10:58 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Glenn, Charlie, and all, I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG. I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work. It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world. Let me also note that I only have a very primitive knowledge of the security issues. Regards, Glenn Morrow wrote: Hesham, I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators. Here are some proposals: - SAR the packet. - Send it over a signaling channel with additional delay. - Make the channels more flexible to handle spurious changes in bandwidth. Keep in mind that the almost negligable delay, if any, induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either. Also keep in mind that the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO. Thanks, Glenn behcet -- Behcet -- Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Road PB7 Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477 2794 Fax: (972) 519 2460 ------_=_NextPart_001_01C1B64E.E6443AA0 Content-Type: text/html; charset="iso-8859-1" RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation
Well, I have problem with the statement
"Since there is a time pressure for a MIPv6 RFC, lets publish something". It is simply not a wise idea, no matter if a SDO needs MIPv6 RFC by some timeline.
 
-Kuntal
 
 
 
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 12:14 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Please note that all IETF WGs work under a charter with certain deadlines, i.e. under time pressure. If there is no time pressure for MIPv6 as you seem to suggest, then let's take it to IRTF the research branch of IETF.

Yes RFCs are obsoleted from time to time. So what is your point?

I am not advocating anything, it is the WG cochairs who are advocating something. I am just suggesting something purely out of reasonable logic to make better progress in this WG.

Regards,

Kuntal Chowdhury wrote:
> Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
> Did this cause backward compatibility nightmares?
 
It seems, you are very sure it does not! To my knowledge, RFC 3220 is far from being widely deployed and tested?
 
> I think that you are talking about some cyber authority making RFCs that never change.
Also, cyber authorities should not publish RFCs which need to be obsoleted every now and then. Had the IETF followed your suggestion, then this whole internet would have been a real management nightmare.
 
> We all know in the telecom world, the standards change sometimes completely!
Successful telecom standards are not defined in a hurry and they do not change like the way you are advocating.
 
-Kuntal
 
 
-----Original Message-----
From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com]
Sent: Friday, February 15, 2002 11:25 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Kuntal,
  Recently RFC2002 was modified to become RFC2002bis and then RFC3220.
Did this cause backward compatibility nightmares?
  I think that you are talking about some cyber authority making RFCs that never change.
We all know in the telecom world, the standards change sometimes completely!

  So I stand by my argument.

Kuntal Chowdhury wrote:
> It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC >xxx-bis's. It is not end of the world.
 
It is always a bad idea to rush into a solution under time pressure to get an RFC number. This kind of approach always results in backward compatibility nightmares.
 
-Kuntal
 

-----Original Message-----
From: Behcet Sarikaya [ mailto:behcet.sarikaya@alcatel.com ]
Sent: Friday, February 15, 2002 10:58 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Glenn, Charlie, and all,
  I have a feeling that Charlie and Glenn and possibly others coming up with solutions of their own defeats the purpose of the design team set up by the WG cochairs and to my knowledge agreed by the WG.
  I suggest that DT makes a conference call with these people once and for all and gets their input and continues its work.
  It could also be noted that whatever the solutions to be agreed this time under time pressure may always be improved upon later on with additional RFCs or RFC xxx-bis's. It is not end of the world.
  Let me also note that I only have a very primitive knowledge of the security issues.

Regards,

Glenn Morrow wrote:
Hesham,
 
I too, am starting to feel like a broken record so I think we should perhaps digress into the link layer space of the particular access technology you believe will be damaged. Please let me know which access specific link layer technology you are referring to? This will be doing access work but gee if it is going to keep access specific arguments out of the IETF work, I suppose I'm game for coming up with an access and media specific solution to the problem i.e. I guess I'll try to help improve the least common denominators.
 
Here are some proposals: 
 
- SAR the packet.
- Send it over a signaling channel with additional delay.
- Make the channels more flexible to handle spurious changes in bandwidth.
 
Keep in mind that the almost negligable delay, if any,  induced by some of these solutions will not happen very often. I also urge you to drive down the highway right now with an existing cell phone and see if you notice some delay during handoff. I know you could get a perfect one under some circumstances but just keep doing it and you'll find that some "engineering choices" have been made on particular deployments, let alone particular products. My point here is "get real". The last proposal which I think is what the Nokia contingent has been saying doesn't even have this theoretic no delay mumbo jumbo point either.
 
Also keep in mind that  the mobile could be configured to tell the CN(MN) not to send it bundled in the future after the 1st one. This also seems like a prudent engineering choice. But gee, I haven't seen any of these mythical sort of IP VOIP 3G handsets deployed that would have this problem in the future and the way the financiers and vendor plans are going lately with respect to alternatives I'm not sure if we ever will. 
 
There - now I've been completely politically incorrect but I hope this points out again just like an old broken record the flaw in the arguments against bundling. And again, I would like to remind people in a completely agnostic manner that this is the IETF and not a cellular SDO and that to technically use the excuse for decision you have used below would signal to me that the IETF is behaving like an access specific cellular SDO.
 
Thanks,
 
Glenn
 
behcet


-- 
Behcet 


-- 
Behcet Sarikaya
Network Strategy Group, Mobile Networking Team
Alcatel USA M/S 026
1000 Coit Road  PB7
Plano, TX 75075 USA
Email: behcet.sarikaya@alcatel.com
Phone: (972) 477 2794 Fax: (972) 519 2460

------_=_NextPart_001_01C1B64E.E6443AA0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 13:49:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15322 for ; Fri, 15 Feb 2002 13:49:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28045; Fri, 15 Feb 2002 11:49:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06334; Fri, 15 Feb 2002 10:49:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIm8KL010991 for ; Fri, 15 Feb 2002 10:48:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FIm8PB010990 for mobile-ip-dist; Fri, 15 Feb 2002 10:48:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FIm5KL010983 for ; Fri, 15 Feb 2002 10:48:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17846 for ; Fri, 15 Feb 2002 10:48:06 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22472 for ; Fri, 15 Feb 2002 10:48:06 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA01386 for ; Fri, 15 Feb 2002 10:48:06 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1FIm5k22036 for ; Fri, 15 Feb 2002 10:48:05 -0800 X-mProtect:  Fri, 15 Feb 2002 10:48:05 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdlxYuiU; Fri, 15 Feb 2002 10:48:02 PST Message-ID: <3C6D5780.18CE58BB@iprg.nokia.com> Date: Fri, 15 Feb 2002 10:46:24 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Iime pressure for RFC? References: <23BDB0046F3ED51185CD0002A5608D240213D691@zrc2c009.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Kuntal, I think we have to be sensitive to the time pressure in this case. Thus, we should definitely go for a solution that is: - open for further improvements in the future - avoids trying to boil the ocean However, I get the sense that we are very close to closure on the important issues. It is true that I have raised some points of difference with the design team recommendations, but I also think (encouraged by responses from the design team members) that we are close to resolving those differences. And, in some cases, we are close to agreeing that we can evolve to a future better system given the parts that we can agree on today. So, I am optimistic that we can get to a very reasonable agreement on the issues, and that we will be able to do so in a timely fashion. Lastly, in response to statements about how nothing new is gained from the current discussion, then I would say those people are not paying close enough attention. I have learned new things from the discussions, and so it is easy for me to imagine that other open-minded people have also. Regards, Charlie P. Kuntal Chowdhury wrote: > Well, I have problem with the statement "Since there is a time > pressure for a MIPv6 RFC, lets publish something". It is simply not a > wise idea, no matter if a SDO needs MIPv6 RFC by some timeline.-Kuntal > > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Friday, February 15, 2002 12:14 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - DT > recommendation > > Please note that all IETF WGs work under a charter with > certain deadlines, i.e. under time pressure. If there is no > time pressure for MIPv6 as you seem to suggest, then let's > take it to IRTF the research branch of IETF. > > Yes RFCs are obsoleted from time to time. So what is your > point? > > I am not advocating anything, it is the WG cochairs who are > advocating something. I am just suggesting something purely > out of reasonable logic to make better progress in this WG. > > Regards, > > Kuntal Chowdhury wrote: > > > > Recently RFC2002 was modified to become RFC2002bis and > > then RFC3220. > > > Did this cause backward compatibility nightmares?It > > seems, you are very sure it does not! To my knowledge, RFC > > 3220 is far from being widely deployed and tested?> I > > think that you are talking about some cyber authority > > making RFCs that never change. > > Also, cyber authorities should not publish RFCs which need > > to be obsoleted every now and then. Had the IETF followed > > your suggestion, then this whole internet would have been > > a real management nightmare.> We all know in the telecom > > world, the standards change sometimes completely! > > Successful telecom standards are not defined in a hurry > > and they do not change like the way you are > > advocating.-Kuntal > > > > -----Original Message----- > > From: Behcet Sarikaya > > [mailto:behcet.sarikaya@alcatel.com] > > Sent: Friday, February 15, 2002 11:25 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: (ISSUE) [mobile-ip] Piggybacking - > > DT recommendation > > > > Kuntal, > > Recently RFC2002 was modified to become > > RFC2002bis and then RFC3220. > > Did this cause backward compatibility > > nightmares? > > I think that you are talking about some cyber > > authority making RFCs that never change. > > We all know in the telecom world, the standards > > change sometimes completely! > > > > So I stand by my argument. > > > > Kuntal Chowdhury wrote: > > > > > > It could also be noted that whatever the > > > solutions to be agreed this time under time > > > pressure may always be improved upon later on > > > with additional RFCs or RFC >xxx-bis's. It is > > > not end of the world. It is always a bad idea > > > to rush into a solution under time pressure to > > > get an RFC number. This kind of approach always > > > results in backward compatibility > > > nightmares. -Kuntal > > > > > > -----Original Message----- > > > From: Behcet Sarikaya [ > > > mailto:behcet.sarikaya@alcatel.com ] > > > Sent: Friday, February 15, 2002 10:58 > > > AM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: (ISSUE) [mobile-ip] > > > Piggybacking - DT recommendation > > > > > > Glenn, Charlie, and all, > > > I have a feeling that Charlie and > > > Glenn and possibly others coming up > > > with solutions of their own defeats > > > the purpose of the design team set up > > > by the WG cochairs and to my > > > knowledge agreed by the WG. > > > I suggest that DT makes a > > > conference call with these people > > > once and for all and gets their input > > > and continues its work. > > > It could also be noted that > > > whatever the solutions to be agreed > > > this time under time pressure may > > > always be improved upon later on with > > > additional RFCs or RFC xxx-bis's. It > > > is not end of the world. > > > Let me also note that I only have a > > > very primitive knowledge of the > > > security issues. > > > > > > Regards, > > > > > > Glenn Morrow wrote: > > > > > > > Hesham, I too, am starting to feel > > > > like a broken record so I think we > > > > should perhaps digress into the > > > > link layer space of the particular > > > > access technology you believe will > > > > be damaged. Please let me know > > > > which access specific link layer > > > > technology you are referring to? > > > > This will be doing access work but > > > > gee if it is going to keep access > > > > specific arguments out of the IETF > > > > work, I suppose I'm game for coming > > > > up with an access and media > > > > specific solution to the problem > > > > i.e. I guess I'll try to help > > > > improve the least common > > > > denominators. Here are some > > > > proposals: - SAR the packet.- Send > > > > it over a signaling channel with > > > > additional delay.- Make the > > > > channels more flexible to handle > > > > spurious changes in bandwidth. Keep > > > > in mind that the almost negligable > > > > delay, if any, induced by some of > > > > these solutions will not happen > > > > very often. I also urge you to > > > > drive down the highway right now > > > > with an existing cell phone and see > > > > if you notice some delay during > > > > handoff. I know you could get a > > > > perfect one under some > > > > circumstances but just keep doing > > > > it and you'll find that some > > > > "engineering choices" have been > > > > made on particular deployments, let > > > > alone particular products. My point > > > > here is "get real". The last > > > > proposal which I think is what the > > > > Nokia contingent has been saying > > > > doesn't even have this theoretic no > > > > delay mumbo jumbo point > > > > either. Also keep in mind that the > > > > mobile could be configured to tell > > > > the CN(MN) not to send it bundled > > > > in the future after the 1st one. > > > > This also seems like a prudent > > > > engineering choice. But gee, I > > > > haven't seen any of these mythical > > > > sort of IP VOIP 3G handsets > > > > deployed that would have this > > > > problem in the future and the way > > > > the financiers and vendor plans are > > > > going lately with respect to > > > > alternatives I'm not sure if we > > > > ever will. There - now I've been > > > > completely politically incorrect > > > > but I hope this points out again > > > > just like an old broken record the > > > > flaw in the arguments against > > > > bundling. And again, I would like > > > > to remind people in a completely > > > > agnostic manner that this is the > > > > IETF and not a cellular SDO and > > > > that to technically use the excuse > > > > for decision you have used below > > > > would signal to me that the IETF is > > > > behaving like an access specific > > > > cellular SDO. Thanks, Glenn > > > > > > behcet > > > > > > > > -- > > Behcet > > > > > > > -- > Behcet Sarikaya > Network Strategy Group, Mobile Networking Team > Alcatel USA M/S 026 > 1000 Coit Road PB7 > Plano, TX 75075 USA > Email: behcet.sarikaya@alcatel.com > Phone: (972) 477 2794 Fax: (972) 519 2460 > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 14:16:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16297 for ; Fri, 15 Feb 2002 14:16:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12293; Fri, 15 Feb 2002 12:15:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26834; Fri, 15 Feb 2002 11:15:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FJEUKL011186 for ; Fri, 15 Feb 2002 11:14:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FJEUtH011185 for mobile-ip-dist; Fri, 15 Feb 2002 11:14:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FJERKL011178 for ; Fri, 15 Feb 2002 11:14:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25876 for ; Fri, 15 Feb 2002 11:14:29 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03655 for ; Fri, 15 Feb 2002 11:14:28 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FJEQN18544; Fri, 15 Feb 2002 13:14:26 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CRVS>; Fri, 15 Feb 2002 13:14:26 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0215FE15@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: "Hesham Soliman (ERA)" , Michael Thomas Subject: RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation Date: Fri, 15 Feb 2002 13:14:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B654.FA88C520" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B654.FA88C520 Content-Type: text/plain; charset="iso-8859-1" Another point I would like to make about bundling is that this is something that MIPv6 signaling can do by the way it has been designed and that other signaling technologies (perhaps a better term might be layer) can not do it. So if you remove this distinguishing item, it might re-open or give credence to the old argument about which signaling should be used for node mobility. regards, Glenn ------_=_NextPart_001_01C1B654.FA88C520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (ISSUE) [mobile-ip] Piggybacking - DT recommendation

Another point I would like to make about bundling is = that this is something that MIPv6 signaling can do by the way it has = been designed and that other signaling technologies  (perhaps a = better term might be layer) can not do it. So if you remove this = distinguishing item, it might re-open or give credence to the old = argument about which signaling should be used for node mobility.  =

regards,

Glenn

------_=_NextPart_001_01C1B654.FA88C520-- From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 14:45:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17612 for ; Fri, 15 Feb 2002 14:45:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28513; Fri, 15 Feb 2002 12:45:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08688; Fri, 15 Feb 2002 11:44:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FJi9KL011323 for ; Fri, 15 Feb 2002 11:44:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1FJi9re011322 for mobile-ip-dist; Fri, 15 Feb 2002 11:44:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1FJi6KL011315 for ; Fri, 15 Feb 2002 11:44:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08336 for ; Fri, 15 Feb 2002 11:44:08 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25626 for ; Fri, 15 Feb 2002 12:44:05 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id D575810; Fri, 15 Feb 2002 21:45:38 +0200 (EET) Message-ID: <3C6D6502.1040808@nomadiclab.com> Date: Fri, 15 Feb 2002 21:44:02 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <3C6D140E.3020900@nomadiclab.com> <3C6D4858.8747AEEB@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, I completely agree that we need to avoid going too deep into the address as locator vs. as identifier discourse. IMHO, that venue should be taken separately. OTOH, there are situations where understanding the difference helps us in deciding the right semantics and encoding. ----------------- >>To summarize and generalize, using the BCE method for storing >>information about received HAOs and for tagging outgoing packets >>is not a good idea. It is too easy to enter bogus information >>into the BCE, thereby causing bogus tagging of outgoing packets. > > I have a truly outlandish and perfect solution to this problem, > except that it may not be the most economical or parsimonious. > But it is so "different" that I think I will seek another approach > for now, in order to find the most economical solution. Ok. > I think the first noteworthy aspect is that it is a platform issue, > and may not require additional protocol. Nevertheless, I agree > with you that we want to have protocol that is implementable, > so we need an existence proof. I agree that the implementation is a platform issue, and can even be approached in a piece wise manner. That is, if the rest of the WG would like to have triangular routing that works only for TCP and a few UDP applications, but not all UDP applications, that is certainly OK for me. From the security point of view, I think that most probably we could adopt the solution without too much worries, since the tagged packets can indeed be dropped on firewalls. Thus, even if we later find out that there are additional vulner- abilities in the method, there is still hope that there exist some immediate remedy to the situation, i.e. strictening firewall rules or such. However, I have one practical reservation: We must be very careful in the wording and details. Firstly, we must make sure that the RFC is completely inambiguous in making sure that the tagged packets are exactly those that result of receiving a packet with HOA and no else. Secondly, to get to that point we have to analyze a number of possible border cases, such as TCP retransmissions, application level UDP retransmissions etc. Thirdly, there must be some text like the following. Under all circumstances, the CN MUST NOT send untagged packets to HoA. If the CN implementation is unable to positively assure this property, it MUST drop all incoming packets that contain the HAO _before_ passing them to TCP, application, or other mechanism that might send packets to the HoA. Fourthly, we should work out a reasonable scheme (ICMP or other) where the CN informs the MN that it is dropping the packets because it is unable to process unverified HAOs. I also think that there is more work to be done on the rate limitation, but I have to admit that I haven't considered that too much. --------------- >>One way to extend the API would be to include space into >>sockaddr_in6 for the care-of-address. Unfortunately that would >>increase the size of the struct, and as a result some applications >>might break. On the other hand, most applications these days >>use sockaddr_storage anyway, so that doesn't matter so much. >>One bit could be stolen from e.g. flowinfo or scope_id to indicate >>whether the added space contains a CoA or some other information. > > I would militate against using a flowlabel bit unless there were not > any other mechanism. The flowinfo field in the struct sockaddr_in6 has extra bits that are currently unused and that cannot fit in to the flowlabel. ---------------- > Do you like my staged evolution approach? I believe it shows we can > get there, and in the near term before the final platform issues are > solved we can still have Proposed Standard. As I stated above, the stage evolution is fine with me. However, I am worried about getting the standard text onto a level that we can be assured that there does not exist any unambiguities that would allow an implementation (or even a lazy implementor) to open up the reflection threat. That's quite an amount of work, and somebody must work out the details quickly. Unfortunately I don't have the time, given the desired schedule. OTOH, I can certainly review whatever text is produced. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 15 20:48:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24607 for ; Fri, 15 Feb 2002 20:48:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22427; Fri, 15 Feb 2002 18:47:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04624; Fri, 15 Feb 2002 17:47:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1G1kpKL012194 for ; Fri, 15 Feb 2002 17:46:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1G1kpIf012193 for mobile-ip-dist; Fri, 15 Feb 2002 17:46:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1G1kmKL012186 for ; Fri, 15 Feb 2002 17:46:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04431 for ; Fri, 15 Feb 2002 17:46:49 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22106 for ; Fri, 15 Feb 2002 18:46:49 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA28504 for ; Fri, 15 Feb 2002 17:46:48 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1G1kmr22151 for ; Fri, 15 Feb 2002 17:46:48 -0800 X-mProtect:  Fri, 15 Feb 2002 17:46:48 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdWv8zwp; Fri, 15 Feb 2002 17:46:46 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA87382 for ; Fri, 15 Feb 2002 17:46:46 -0800 (PST) Message-ID: <3C6DBA06.D416F143@iprg.nokia.com> Date: Fri, 15 Feb 2002 17:46:46 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: > > James Kempf wrote: > > > > .. I don't > > understand why we couldn't simply allow piggybacking > > with the caveat that you shouldn't use it with IPSec, then start > > working with the IPSec group to come up with a solution that will work. > > The MN doesn't have to send the BU as part of an IPSec secured > > TCP stream, it could send it separately. > > > > To me, this seems to offer a workable compromise. If the major > trouble with piggybacking BU's is in the granularity of IPsec selectors, > so piggybacking when IPsec's in use gives trouble, -- why, let us allow > optional piggybacking where there is no problem, and disallow them (for now) > where we have no clear way forward? > > Best, > Henrik I would like to second this simple compromise. It would solve the IPsec issue short term with no change requirement to protocol specs other than possibly an implementation note to MIPv6. Once a policy rule is inserted for BUs, don't piggyback. Existence of the rule can, e.g., be a per-HoA BCE flag set when inserting the IPsec policy. It is then known to the part of code deciding on piggybacking. This is one of the simplest way, other ways exist, too. BUs have a new extension header number to solve the orthogonal-to-piggybacking problem of distinguishing from non-MIPv6 DstHdr traffic. There seem to be two threads on piggybacking, IPsec and L2. I see above some first signs of progress towards a compromise in the former. To me this is a new development compared to discussions last fall. BR, -Jari M. From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 10:19:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12855 for ; Sat, 16 Feb 2002 10:19:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00398; Sat, 16 Feb 2002 08:19:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00072; Sat, 16 Feb 2002 07:19:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFIMKL013128 for ; Sat, 16 Feb 2002 07:18:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GFIM8J013127 for mobile-ip-dist; Sat, 16 Feb 2002 07:18:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFIJKL013120 for ; Sat, 16 Feb 2002 07:18:19 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21353 for ; Sat, 16 Feb 2002 07:18:20 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04880 for ; Sat, 16 Feb 2002 07:18:19 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GFIHk18033 for ; Sat, 16 Feb 2002 16:18:17 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA23792 for ; Sat, 16 Feb 2002 16:18:17 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GFIHg30008 for ; Sat, 16 Feb 2002 16:18:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161518.g1GFIHg30008@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation In-reply-to: Your message of Thu, 14 Feb 2002 00:19:45 +0200. <3C6AE681.4060504@piuha.net> Date: Sat, 16 Feb 2002 16:18:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Does this mean that you propose HAOs to be accepted either because there's an IPSec SA or because there's a BCE, and bidir tunneling otherwise? I think I could AGREE with that. => yes, the key point is something has to provide the home address verification but IPsec can do that, not only BCE. True, but you yourself listed some issues with the kernel approach. We didn't see a way out so we didn't consider it further. => I believe this is too new to become a real alternative... Yes, AGREE... I think this was roughly what we meant though the text didn't exactly come out so. => so we agree about all points in your message. Regards Francis.Dupont@enst-bretagne.fr PS: I've seen a new thread about this problem but roughly the current recommendation is in "CAN LIVE WITH" scope for me. From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 10:24:33 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12923 for ; Sat, 16 Feb 2002 10:24:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27953; Sat, 16 Feb 2002 08:24:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00495; Sat, 16 Feb 2002 07:24:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFNOKL013197 for ; Sat, 16 Feb 2002 07:23:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GFNOAb013196 for mobile-ip-dist; Sat, 16 Feb 2002 07:23:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFNLKL013189 for ; Sat, 16 Feb 2002 07:23:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21916 for ; Sat, 16 Feb 2002 07:23:23 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25995 for ; Sat, 16 Feb 2002 08:23:22 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GFNHk18192; Sat, 16 Feb 2002 16:23:18 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA23835; Sat, 16 Feb 2002 16:23:18 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GFNHg30033; Sat, 16 Feb 2002 16:23:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161523.g1GFNHg30033@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation In-reply-to: Your message of Thu, 14 Feb 2002 15:38:20 +0100. Date: Sat, 16 Feb 2002 16:23:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => basically BCE state will become hard state. => should be more "harder" than "hard". Per what definition of hard and soft state? => in the HAO/BCE case, the problem is the MN should have a good idea of the state of its BCEs on its CNs. So the BU/BA has to be more robust and there is a need for "will delete" messages from CNs to MNs. Nothing hard (:-) but this should give a heavier protocol... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 10:32:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13169 for ; Sat, 16 Feb 2002 10:32:31 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27073; Sat, 16 Feb 2002 08:32:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01173; Sat, 16 Feb 2002 07:32:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFVFKL013268 for ; Sat, 16 Feb 2002 07:31:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GFVFS7013267 for mobile-ip-dist; Sat, 16 Feb 2002 07:31:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFVCKL013260 for ; Sat, 16 Feb 2002 07:31:12 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23016 for ; Sat, 16 Feb 2002 07:31:14 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06861 for ; Sat, 16 Feb 2002 07:31:13 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GFV9k18545; Sat, 16 Feb 2002 16:31:09 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA23912; Sat, 16 Feb 2002 16:31:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GFV9g30068; Sat, 16 Feb 2002 16:31:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161531.g1GFV9g30068@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (ISSUE) [mobile-ip] Home Address Option: design team recommendation In-reply-to: Your message of Thu, 14 Feb 2002 18:38:15 +0100. Date: Sat, 16 Feb 2002 16:31:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => mobile to mobile communication with simultaneous movement > (BUs never reach peers until a fallback path though a HA is used). This can actually be avoided as is examplified by BU3WAY - the BU/RR related packets by-pass any binding cache entry on the sending node. => I agree my comment only applies for route optimized BUs, but BUs are critical so we'd like to put them on the fastest path. In fact, this is only an other argument in the mobile-to-mobile special case (for security, I don't argue for special BUs). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 10:36:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13217 for ; Sat, 16 Feb 2002 10:36:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02580; Sat, 16 Feb 2002 08:36:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01448; Sat, 16 Feb 2002 07:35:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFZGKL013329 for ; Sat, 16 Feb 2002 07:35:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GFZFYq013328 for mobile-ip-dist; Sat, 16 Feb 2002 07:35:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFZCKL013321 for ; Sat, 16 Feb 2002 07:35:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01395 for ; Sat, 16 Feb 2002 07:35:14 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02480 for ; Sat, 16 Feb 2002 08:35:13 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GFZ6k18671; Sat, 16 Feb 2002 16:35:06 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA23937; Sat, 16 Feb 2002 16:35:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GFZ6g30093; Sat, 16 Feb 2002 16:35:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161535.g1GFZ6g30093@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation In-reply-to: Your message of Thu, 14 Feb 2002 18:43:23 +0100. Date: Sat, 16 Feb 2002 16:35:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => DISAGREE (R3): this kind of requirement is *not* in the scope > of the mobile-ip WG. It is clearly the job of the IPv6 WG. > The only acceptable thing is a recommendation from the mobile-ip WG > to the IPv6 WG to consider such a requirement for all IPv6 nodes. It would seem to be useful to determine whether we have rough concensus in the MIP WG to mandate this *before* we ask the IPv6 WG (as well as the rest of the IETF community) for their opinions. => I agree. The issue is in the wording. I take it your DISAGREE in due to the procedural concerns. => exactly Do you agree or disagree that the MIP WG should recommend to the IPv6 WG that we think this should be mandatory in all IPv6 nodes? => I agree. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 10:57:27 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13437 for ; Sat, 16 Feb 2002 10:57:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15146; Sat, 16 Feb 2002 07:57:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25845; Sat, 16 Feb 2002 07:57:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFuKKL013478 for ; Sat, 16 Feb 2002 07:56:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GFuKBa013477 for mobile-ip-dist; Sat, 16 Feb 2002 07:56:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GFuHKL013470 for ; Sat, 16 Feb 2002 07:56:17 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11066 for ; Sat, 16 Feb 2002 07:56:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04800 for ; Sat, 16 Feb 2002 08:56:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GFuEk19413; Sat, 16 Feb 2002 16:56:14 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA24123; Sat, 16 Feb 2002 16:56:14 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GFuDg30205; Sat, 16 Feb 2002 16:56:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161556.g1GFuDg30205@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CONCLUSION) Re: [mobile-ip] Routing headers - part 2 In-reply-to: Your message of Thu, 14 Feb 2002 18:21:29 +0100. Date: Sat, 16 Feb 2002 16:56:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: There is a risk (how big it is can be debated) that IPv6 firewalls assume that IPv6 routing headers = IPv4 source routing and have a single on/off knob. => they can understand we introduce a new RH type for them and be grateful? If we instead have ADA (and HOA) as DOs there are probably going to be IPv6 firewalls that have a single on/off knob for IPv6 destination options. But in that case the firewall implementors, as well as users, might be a tad less likely to have it be turned off by default partly because destination options is new compared to IPv4 and they might actually read something which says destination options is used e.g. for mobile IPv6 => up to this point I agree but the following deduction assumes a matter of taste. and think before disabling it. => I am afraid we don't know and as we got no answer from a firewall vendor I can only try to imagine what firewall implementors will like. For the complexity of the implementations, RH type 2 is far easier than destination option chasing. I don't believe in the firewall argument: if firewall implementors understand the protocols they filter, all alternatives will be considered as equivalent (and they are) and will receive the same kind of processing. This is a bit different for firewall managers but or they are competent and shall do the right thing independently of what we choose, or they are not and they shall keep the default... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 11:35:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13841 for ; Sat, 16 Feb 2002 11:35:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04051; Sat, 16 Feb 2002 09:35:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01191; Sat, 16 Feb 2002 08:34:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GGYCKL013636 for ; Sat, 16 Feb 2002 08:34:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GGYC7O013635 for mobile-ip-dist; Sat, 16 Feb 2002 08:34:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GGY9KL013628 for ; Sat, 16 Feb 2002 08:34:09 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24181; Sat, 16 Feb 2002 08:34:11 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15477; Sat, 16 Feb 2002 08:34:09 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GGY7k20776; Sat, 16 Feb 2002 17:34:07 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA24539; Sat, 16 Feb 2002 17:34:07 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GGY3g30313; Sat, 16 Feb 2002 17:34:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161634.g1GGY3g30313@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, kempf@docomolabs-usa.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Thu, 14 Feb 2002 12:27:56 +0100. Date: Sat, 16 Feb 2002 17:34:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => not only they exist but when the IKE phase 1 uses address identities > (very common, the default mode of every IKE implementations I know > because it is needed for pre-shared keys in main mode) the address > must be the subject(Alt)Name of the certificate. This is checked > for all compliant IKE implementations and all good implementations > check too if the address in the identity and the address used for IKE > messages are the same (a trivial attack if not performed). I having a hard time to parse the above. It seems like you are saying that when the IKE phase 1 uses address identities the addresses must be checked That seems very obvious and not surprising. => this is not so obvious (from time to time someone asked in the IPsec mailing list) and there is an easy interesting case. But IKE can also be used with phase 1 address identities. For instance the IKE certs I use right now have Subject Name: Subject Alternative Names: email = nordmark@eng.sun.com => the exception is this: a certificate which says nothing about addresses. I've seen some answers (reading IKE implementation documentations/sources): - forget the check (BAD) - reject the certificate (very common: you should get the identity in the subject(Alt)Name) - resolve the DNS name (correct for a FQDN identity, very abusive for an user_FQDN identity as in your example) The problem I've pointed out in the past is that I don't see how existing ways of doing PKIs can ensure that an IP address in the subject altname actually is actually the IP address assigned to the node and that can be tracked as the node and/or site renumbers etc. => this is a problem of how to do a PKI. You are pointing out that should a PKI exist that can not only mechanically produce such certificates, but also guarantee that the subject altname IP address is assigned to the holder of the cert, they can be used. => more, if such a PKI doesn't exist then the common default IKE configuration doesn't work. I believe both of the above are true and independent. => I agree, one (mine) is a practical requirement, the other (yours) is how to fulfill the requirement. So are we in violent agreement that while the mechanisms in IKE work when using such certificates I can't get such a useful certificate from existing commercial PKIs (like Verisign etc)? => I can't talk about commercial PKIs (not enough money to use them). I create my certificates using OpenSSL (derived) tools and patch them (i.e. add missing subjectAltNames) using OpenBSD certpatch tool. The PKI mechanisms are supposed to deal with renumbering but my plan is to use DNSSEC (which has a built-in name or address to public key binding) as soon as it becomes usuable. > Don't forget that the "road warrior" case is supported by many IPsec > implementations so this is more a question of how protocols are (mis)used > than about protocols themselves. What does that have to do with the subject at hand? => the "road warrior" case is your laptop case. My laptop certificate doesn't (and can't) use an IP address as a suject altname because the IP address is different depending on where I connect. => so your certificate has no subject(Alt)Names bound to an address *and* you don't use an address as the phase 1 identity (and this identity has to be one of the subject(Alt)Names). Usually this is a special case in policies and there are some restrictions (for instance the "road warrior" should not be a security gateway). I can't see the problem: I believe this is only misunderstanding, my clause is: PKIs can bind addresses to certificates, this kind of bindings has a clear semantics but PKIs should not always bind addresses to certificates. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 11:41:54 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13939 for ; Sat, 16 Feb 2002 11:41:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16999; Sat, 16 Feb 2002 08:41:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02102; Sat, 16 Feb 2002 08:41:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GGf5KL013703 for ; Sat, 16 Feb 2002 08:41:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GGf50u013702 for mobile-ip-dist; Sat, 16 Feb 2002 08:41:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GGf2KL013695 for ; Sat, 16 Feb 2002 08:41:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16362 for ; Sat, 16 Feb 2002 08:41:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10636 for ; Sat, 16 Feb 2002 08:41:03 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GGerk21087; Sat, 16 Feb 2002 17:40:53 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA24604; Sat, 16 Feb 2002 17:40:53 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GGeqg30341; Sat, 16 Feb 2002 17:40:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161640.g1GGeqg30341@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: mobile-ip@sunroof.eng.sun.com, "Erik Nordmark" , "Vijay Devarapalli" , "Jari Arkko" , basavaraj.patil@nokia.com Subject: Re: [mobile-ip] BU Authorization method: design team recommendation In-reply-to: Your message of Thu, 14 Feb 2002 17:14:58 PST. <15468.24850.600770.337107@thomasm-u1.cisco.com> Date: Sat, 16 Feb 2002 17:40:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: In fact, IPsec can leverage AAA in two ways: 1) XAUTH 2) KINK The former is deployed, but the latter is a lot cleaner. Recall that it's the subscriber database that's actually important. There is no fundamental reason you couldn't put a Kerberos protocol head on an existing AAA database, just like you can put a DIAMETER protocol head on that database. => IMHO Kerberos and DIAMETER/AAA are two orthogonal extensions/ improvements of the Unix login/password we used 20 years ago. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 12:02:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14192 for ; Sat, 16 Feb 2002 12:02:51 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07468; Sat, 16 Feb 2002 10:02:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05312; Sat, 16 Feb 2002 09:02:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GH1lKL013776 for ; Sat, 16 Feb 2002 09:01:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GH1lBU013775 for mobile-ip-dist; Sat, 16 Feb 2002 09:01:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GH1iKL013768 for ; Sat, 16 Feb 2002 09:01:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25996 for ; Sat, 16 Feb 2002 09:01:46 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09324 for ; Sat, 16 Feb 2002 10:01:45 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GH1hk21954 for ; Sat, 16 Feb 2002 18:01:43 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA24767 for ; Sat, 16 Feb 2002 18:01:44 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GH1hg30449 for ; Sat, 16 Feb 2002 18:01:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161701.g1GH1hg30449@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options In-reply-to: Your message of Thu, 14 Feb 2002 18:50:40 PST. <3C6C7780.4CFAA7B4@iprg.nokia.com> Date: Sat, 16 Feb 2002 18:01:43 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The Home Address option allows a correspondent node to correctly associate a mobile node's home address with ongoing protocol operations in higher level protocols. => this is the key point and even in the BT recommendation alternative ways to the BCE check should be allowed. For instance, assume the MN and the CN share a trust domain, the MN can easily build an end-to-end IPsec SA pair with the CN using its Home Address (H@) (don't forget the mobility is transparent so for example IKE should see only the H@). With the MN->CN SA, the CN is able to verify Home Address options. It is important, for cases where a correspondent node should be able to receive packets from a mobile node without going through a home agent. => I agree and I am not very satisfied by the choice of the design team in the apparent security/performance lost tradeoff. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 13:09:50 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14986 for ; Sat, 16 Feb 2002 13:09:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21052; Sat, 16 Feb 2002 10:09:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16620; Sat, 16 Feb 2002 10:09:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GI8lKL013933 for ; Sat, 16 Feb 2002 10:08:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GI8laO013932 for mobile-ip-dist; Sat, 16 Feb 2002 10:08:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GI8iKL013925 for ; Sat, 16 Feb 2002 10:08:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16478 for ; Sat, 16 Feb 2002 10:08:47 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17823 for ; Sat, 16 Feb 2002 11:08:46 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GI8ik24502; Sat, 16 Feb 2002 19:08:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA25309; Sat, 16 Feb 2002 19:08:45 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GI8ig30602; Sat, 16 Feb 2002 19:08:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161808.g1GI8ig30602@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: charliep@iprg.nokia.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options In-reply-to: Your message of Fri, 15 Feb 2002 15:58:38 +0200. <3C6D140E.3020900@nomadiclab.com> Date: Sat, 16 Feb 2002 19:08:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: However, I think that there are fairly serious implementation related problems. => someone suggested to add an implementor in the DT... This far I agree, especially since you later note that the tagging allows firewalls to filter them out whenever they are destined to some non-HA network: => the filtering out a bit dangerous, I believe a more clever filtering in order to: - drop on the floor unrelated floods of tagged packets - avoid the vulnerability described by Pekka. For connected or pseudo-connected transport protocols, to track communications is easy using a cache. For other cases, rate limitation should be enough (don't forget a DDoS attack can be only based on brute force flooding and sophistication only makes them harder). But the security problem first: using the Binding Cache for storing the UnVCoAs so that they can be tagged into outgoing packets leads, together with the firewalling rules, to a serious DoS attack. => this attack is against the firewall so it is enough to warn firewall implementors against it IMHO. To summarize and generalize, using the BCE method for storing information about received HAOs and for tagging outgoing packets is not a good idea. => I strongly disagree. It is too easy to enter bogus information into the BCE, thereby causing bogus tagging of outgoing packets. => if there is no stupid action associated to tagged packets, the only issue is the overhead of the tag itself. [A side note: CGA might help here, but OTOH, using it without proper precautiosn would open up DoS vulnerabilities against the CN. Security design is interesting. :-) ] => to make AH mandatory won't even make IPsec folk happy (:-)! Let us now consider what looks like the right way of implementing this. => this is no more difficult than the already nearly required binding cache. Most of my questions in a previous message about the strange idea of the DT this cannot be implemented in the kernel found their answer in Charlie's proposal. IMHO, the right way would be to more rigoriously associate requests containing the HAO and related replies that need to be tagged. => this is not necessary (fortunately because this is hard). For TCP and connected UDP sockets this seems to be achieveable, since the information about the received HAO and CoA can be stored in the socket. => socket -> PCB (Process Control Block, something which is used (usually with this name) by every implementations). The unconnected UDP sockets are the problem, though. There the kernel does not create any state where the HAO or CoA could be stored. => so the kernel should create state... where is the problem? Consequently, the only reasonable option would be to pass the information to the user level. => this is the less reasonable option... This, in turn, would mean API changes. => typically something an implementor does *never* ask for! One way to extend the API would be to include space into sockaddr_in6 for the care-of-address. Unfortunately that would increase the size of the struct, and as a result some applications might break. => s/some/all/ On the other hand, most applications these days use sockaddr_storage => the disillusion shall be bitter. anyway, so that doesn't matter so much. One bit could be stolen from e.g. flowinfo or scope_id to indicate whether the added space contains a CoA or some other information. If adding extra space to the sockaddr_in6 would be considered too big a change, there are hacks we could make. For example, most unconnected UDP sockets don't have _that_ many outstanding requests anyway. Thus, it _might_ be possible to use e.g. the scope_id field to indicate that the packet was received with a HAO, and cache the HAO in the kernel space for a few seconds. However, such solutions are hacks. => I agree, there are hacks. Not better than to add a field in sockaddr_in6 structure to make unconnected UDP sockets answer with the right source address (or this is a real problem and should be addressed in the standardized API, or this is not and a warning for careless programmers is enough). That would have the additional benefit that also other system calls used to report peer addresses (e.g. getpeername) would also report the CoA, if it exists. => this is a real question but the experience shows the system call which should be extended to report the CoA is getsockname (this should not be a surprise, to talk to a mobile is transparent, to be a mobile is not). Be more serious, this should be handled by the kernel. There is a good place to put the cache, the "Destination Cache" (RFC 2461 5.1) (two reasons: this is a per destination cache, this solves MTU issues). To come back to the kernel implementation considerations, immediate issues were: - what kind of state? how long to keep it? (answer in proposal: cache (according to Mike Thomas' types of state) and for single digits of seconds) - what to do if only some packets have HAO? (no answer, there is an opportunity to detect attacks but a drastic action will give a DoS issue) - what to do if there is not enough memory to handle the state? (drop the packet, this raises another issue) - trivial performance attack with rogue packets (force the additional of an OAH to any packet for the victim) (no answer) - etc: what to do with two different UnvHOA for the same H@ (answer, drop the second one) I believe the proposal is a good answer to indirect DDoS but is subject to DoS attacks against itself: this is easy to protect the CN (just refuse new UnvHOAs) but this is easy too to disable processing of UnvHOAs (one only needs to flood the CN by UnvHOAs until the CN cache is full). There is a second order attack (i.e. against the MNs which want to use the CNs) with a limited lifetime (cache will be flushed after a short delay). Of course, the addresses of attackers will be known and with a good ingress filtering their locations too. Finally the "2.5. ADDITIONAL INFORMATION COPIED TO THE REFLECTED PACKETS" alternative is perhaps feasible... Thanks Francis.Dupont@enst-bretagne.fr PS: a detail: is it required/useful to add a tag to every packets? From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 13:17:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15044 for ; Sat, 16 Feb 2002 13:17:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18823; Sat, 16 Feb 2002 11:16:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05515; Sat, 16 Feb 2002 10:16:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GIFlKL013995 for ; Sat, 16 Feb 2002 10:15:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GIFlGK013994 for mobile-ip-dist; Sat, 16 Feb 2002 10:15:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GIFiKL013987 for ; Sat, 16 Feb 2002 10:15:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11461 for ; Sat, 16 Feb 2002 10:15:32 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22213 for ; Sat, 16 Feb 2002 10:15:31 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GIFSk24759; Sat, 16 Feb 2002 19:15:28 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA25359; Sat, 16 Feb 2002 19:15:29 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GIFTg30638; Sat, 16 Feb 2002 19:15:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161815.g1GIFTg30638@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jean-Michel COMBES Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options In-reply-to: Your message of Fri, 15 Feb 2002 07:52:54 PST. <3C6D2ED6.87BB2BF0@iprg.nokia.com> Date: Sat, 16 Feb 2002 19:15:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > *** Case 2b : the victim is not a MN *** > Solution : ??? In case 2b, the firewall should drop packets destined for a network that does not have mobile nodes, but that have the care-of address tag. I did mention this in my proposal. => the obvious attack is to create a wrong entry in the UnvHAO cache so no drastic action like to drop a packet should be required on a bad tag. The format of the tag is not decided. It could be a routing header with segments-left == 0. => I really like the HAO with a RH-like segment-left field. > JMC : > what happens if the attack is distributed (ie. the bad guy sends forged > packets to many reflectors) ? Then the bad guy has done exactly the same thing, but less efficiently, than sending all the packets itself to the victim. It would be faster for the bad guy to just forget about this useless method of attack. Plus the attack is eminently traceable. => I agree: there are different levels of attacks... I do not think this remaining threat is at all worthy of amputating useful protocol functionality. => this is the apparent security/performance lost tradeoff... Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 13:26:54 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15123 for ; Sat, 16 Feb 2002 13:26:54 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23457; Sat, 16 Feb 2002 11:26:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07011; Sat, 16 Feb 2002 10:26:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GIPaKL014065 for ; Sat, 16 Feb 2002 10:25:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GIPaAV014064 for mobile-ip-dist; Sat, 16 Feb 2002 10:25:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GIPWKL014057 for ; Sat, 16 Feb 2002 10:25:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06923 for ; Sat, 16 Feb 2002 10:25:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23401 for ; Sat, 16 Feb 2002 10:25:33 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1GIPUk25191; Sat, 16 Feb 2002 19:25:30 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA25446; Sat, 16 Feb 2002 19:25:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1GIPVg30671; Sat, 16 Feb 2002 19:25:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202161825.g1GIPVg30671@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Charlie Perkins Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options In-reply-to: Your message of Fri, 15 Feb 2002 21:44:02 +0200. <3C6D6502.1040808@nomadiclab.com> Date: Sat, 16 Feb 2002 19:25:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > I think the first noteworthy aspect is that it is a platform issue, > and may not require additional protocol. Nevertheless, I agree > with you that we want to have protocol that is implementable, > so we need an existence proof. => ahah! Something for implementors (:-). However, I have one practical reservation: We must be very careful in the wording and details. Firstly, we must make sure that the RFC is completely inambiguous in making sure that the tagged packets are exactly those that result of receiving a packet with HOA and no else. => this is the point where we disagree. Fourthly, we should work out a reasonable scheme (ICMP or other) where the CN informs the MN that it is dropping the packets because it is unable to process unverified HAOs. => some kind of unreachable for administrative reasons... I'd like to get a different code for UnvHOA collisions and for other no more memory, etc, cases. I also think that there is more work to be done on the rate limitation, but I have to admit that I haven't considered that too much. => I agree you have to apologize to forget rate limitation against a DoS attack without multipliers. The flowinfo field in the struct sockaddr_in6 has extra bits that are currently unused and that cannot fit in to the flowlabel. => the whole flowinfo field is unused in fact (this is not the good API, Itojun's proposal is many times better). Unfortunately I don't have the time, given the desired schedule. => like everybody in this list... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Feb 16 16:28:42 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16817 for ; Sat, 16 Feb 2002 16:28:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14382; Sat, 16 Feb 2002 14:28:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14244; Sat, 16 Feb 2002 13:28:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GLRIKL014248 for ; Sat, 16 Feb 2002 13:27:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1GLRIXG014247 for mobile-ip-dist; Sat, 16 Feb 2002 13:27:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GLRFKL014240 for ; Sat, 16 Feb 2002 13:27:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14078; Sat, 16 Feb 2002 13:27:17 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08713; Sat, 16 Feb 2002 14:27:17 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1GLRFS02870; Sat, 16 Feb 2002 15:27:15 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CVMC>; Sat, 16 Feb 2002 15:27:15 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E021B5DB8@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Sat, 16 Feb 2002 15:27:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B730.B5C42B50" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B730.B5C42B50 Content-Type: text/plain; charset="iso-8859-1" Yes. > So perhaps we need to tack the whole tangled mess above in > one fell swoop. > Would that make more sense to you? > > Erik > > ------_=_NextPart_001_01C1B730.B5C42B50 Content-Type: text/html; charset="iso-8859-1" RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation]

Yes.

> So perhaps we need to tack the whole tangled mess above in
> one fell swoop.
> Would that make more sense to you?
>
>   Erik
>
>

------_=_NextPart_001_01C1B730.B5C42B50-- From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 17 12:04:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08472 for ; Sun, 17 Feb 2002 12:04:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24892; Sun, 17 Feb 2002 10:04:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29095; Sun, 17 Feb 2002 09:04:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HH3NKL015684 for ; Sun, 17 Feb 2002 09:03:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HH3N4W015683 for mobile-ip-dist; Sun, 17 Feb 2002 09:03:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HH3KKL015676 for ; Sun, 17 Feb 2002 09:03:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13002 for ; Sun, 17 Feb 2002 09:03:22 -0800 (PST) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24788 for ; Sun, 17 Feb 2002 10:03:21 -0700 (MST) Received: from attglobal.net (slip-12-64-6-96.mis.prserv.net[12.64.6.96]) by prserv.net (out1) with SMTP id <2002021717031820104dpcu3e>; Sun, 17 Feb 2002 17:03:19 +0000 Message-ID: <3C6FE255.C2FA49C3@attglobal.net> Date: Sun, 17 Feb 2002 11:03:18 -0600 From: Sebastian Thalanany X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, gdommety@cisco.com Subject: [mobile-ip] Length field definitions - rfc3115 Content-Type: multipart/alternative; boundary="------------99EAC50AA570E8A58C0D520C" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------99EAC50AA570E8A58C0D520C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Gopal, The Length field definitions for the Mobile IP Vendor/Organization specific extensions, namely, the CVSE and the NVSE perhaps require clarifications. Here is the text for the definitions for the Length field for the CVSE and the NVSE elements: 1. CVSE Length Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the Type, Length and the Reserved fields. 2. NVSE Length Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the Type, Length and the Reserved fields. or Length Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the Type, Length fields. The Length field MUST be set to 2 plus the length of the Value(data) field, where the additional two octets are required to include the length of the Reserved field. Please clarify the Length field definition for the NVSE, from among the two possible definitions suggested above, so that the text in the 3GPP2 text can be updated appropriately for the usage of the Length field associated with the NVSE. The suggested definitions above, for the CVSE and the NVSE, are based on the recently published RFC3220, section 1.9. There is no ambiguity with regard to the existing definition for the Length field associated with the CVSE in the RFC3115. Perhaps the references to RFC2002 would be replaced with references to RFC3220. Thanks. Regards, Sebastian --------------99EAC50AA570E8A58C0D520C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Gopal,
              The Length field definitions for the Mobile IP Vendor/Organization specific extensions, namely, the CVSE and the NVSE perhaps require clarifications. Here is the text for the definitions for the Length field for the CVSE and the NVSE elements:

1. CVSE

        Length         Length in bytes of the Value(data) field within this extension.  It does NOT include the bytes associated with the  Type, Length and the Reserved fields.
 

2. NVSE

        Length         Length in bytes of the Value(data) field within this extension.  It does NOT include the bytes associated with the  Type, Length and the Reserved fields.

or

        Length        Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the  Type, Length fields. The Length field MUST be set to 2 plus the length of the Value(data) field, where the additional two octets are required to include the length of the Reserved field.

        Please clarify the Length field definition for the NVSE, from among the two possible definitions suggested above, so that the text in the 3GPP2 text can be updated appropriately for the usage of the Length field associated with the NVSE. The suggested definitions above, for the CVSE and the NVSE, are based on the recently published RFC3220, section 1.9. There is no ambiguity with regard to the existing definition for the Length field associated with the CVSE in the RFC3115. Perhaps the references to RFC2002 would be replaced with references to RFC3220.

        Thanks.

Regards,
    Sebastian
  --------------99EAC50AA570E8A58C0D520C-- From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 17 12:43:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08990 for ; Sun, 17 Feb 2002 12:43:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00719; Sun, 17 Feb 2002 10:42:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20714; Sun, 17 Feb 2002 09:42:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HHfxKL015787 for ; Sun, 17 Feb 2002 09:41:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HHfx8g015786 for mobile-ip-dist; Sun, 17 Feb 2002 09:41:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HHfuKL015779 for ; Sun, 17 Feb 2002 09:41:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20523 for ; Sun, 17 Feb 2002 09:41:58 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21102 for ; Sun, 17 Feb 2002 10:41:58 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1HHfvh25040; Sun, 17 Feb 2002 09:41:57 -0800 (PST) Received: from cisco.com (sjc-vpn3-396.cisco.com [10.21.65.140]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABT57672; Sun, 17 Feb 2002 09:41:38 -0800 (PST) Message-ID: <3C6FEB76.650DEF8E@cisco.com> Date: Sun, 17 Feb 2002 09:42:15 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: gdommety@cisco.com Subject: Re: [mobile-ip] Length field definitions - rfc3115 References: <3C6FE255.C2FA49C3@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Sebastian. Good pt. 1. CVSE Length Length in bytes of this extension, not including the Type, Reserved, and Length fields. 2. NVSE Length Length in bytes of this extension, not including the Type and Length bytes. Is this sufficient? This description is used by other RFCs and drafts as well. Though the text you provided is more descriptive. But the Value(data) would have to be explained further for clarity too. Kent Sebastian Thalanany wrote: > Hello Gopal, > The Length field definitions for the Mobile IP > Vendor/Organization specific extensions, namely, the CVSE and the NVSE > perhaps require clarifications. Here is the text for the definitions > for the Length field for the CVSE and the NVSE elements: > > 1. CVSE > > Length Length in bytes of the Value(data) field within > this extension. It does NOT include the bytes associated with the > Type, Length and the Reserved fields. > > > 2. NVSE > > Length Length in bytes of the Value(data) field within > this extension. It does NOT include the bytes associated with the > Type, Length and the Reserved fields. > > or > > Length Length in bytes of the Value(data) field within > this extension. It does NOT include the bytes associated with the > Type, Length fields. The Length field MUST be set to 2 plus the length > of the Value(data) field, where the additional two octets are required > to include the length of the Reserved field. > > Please clarify the Length field definition for the NVSE, from > among the two possible definitions suggested above, so that the text > in the 3GPP2 text can be updated appropriately for the usage of the > Length field associated with the NVSE. The suggested definitions > above, for the CVSE and the NVSE, are based on the recently published > RFC3220, section 1.9. There is no ambiguity with regard to the > existing definition for the Length field associated with the CVSE in > the RFC3115. Perhaps the references to RFC2002 would be replaced with > references to RFC3220. > > Thanks. > > Regards, > Sebastian > -- | | Kent Leung :|: :|: IOS Development :|||: :|||: Voice: 408.526.5030 :|||||||: :|||||||: Email: kleung@cisco.com .:|||||||||:.:|||||||||:. URL : http://wwwin-mobileip:8000 c i s c o S y s t e m s "Enabling the mobile wireless age!" From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 17 14:43:31 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10561 for ; Sun, 17 Feb 2002 14:43:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18679; Sun, 17 Feb 2002 11:40:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12174; Sun, 17 Feb 2002 11:38:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HJbDKL015957 for ; Sun, 17 Feb 2002 11:37:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HJbDS1015956 for mobile-ip-dist; Sun, 17 Feb 2002 11:37:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HJb9KL015949 for ; Sun, 17 Feb 2002 11:37:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28617 for ; Sun, 17 Feb 2002 11:37:11 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14411 for ; Sun, 17 Feb 2002 12:37:10 -0700 (MST) Received: from T23KEMPF (dhcp44.docomolabs-usa.com [172.21.96.44]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1HJb9e02497 for ; Sun, 17 Feb 2002 11:37:09 -0800 (PST) Message-ID: <004201c1b7ea$443922f0$2c6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Meaning of Alternate Care-of Address? Date: Sun, 17 Feb 2002 11:35:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi folks, Hopefullly, I can get some response on this between the excellent but voluminous MIPv6 security debate. Section 10.9 of draft-ietf-mobileip-ipv6-15.txt states: In any Binding Update sent by a mobile node, the care-of address (either the Source Address in the packet's IPv6 header or the Care-of Address in the Alternate Care-of Address Sub-Option of the Binding Update) MUST be set to one of the care-of addresses currently in use by the mobile node or to the mobile node's home address. What does "in use" mean? For example, in MIPv4, a non CoCoA is "in use" by the MN even though the MN never configures an interface actively because the FA is managing the CoA. Because MIPv6 has CoCoA exclusively, one would think that "in use" means "the MN has a network interface configured with the address," but that rules out some interesting applications. Suppose, for example, I want to hand off from my cell phone to my workstation when I walk into the office, and turn the cell phone off. I might like to implement this so that the workstation registers an alternate CoA for the cell phone's home address (presuming both the cell phone and the workstation have the same trust relationship with the HA). But, if the alternate CoA is restricted to being on the same host, then this application would be impossible. Comments? jak From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 17 15:35:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11097 for ; Sun, 17 Feb 2002 15:35:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22487; Sun, 17 Feb 2002 13:35:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01978; Sun, 17 Feb 2002 12:35:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HKYMKL016055 for ; Sun, 17 Feb 2002 12:34:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HKYMNY016054 for mobile-ip-dist; Sun, 17 Feb 2002 12:34:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HKYJKL016047 for ; Sun, 17 Feb 2002 12:34:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01894 for ; Sun, 17 Feb 2002 12:34:21 -0800 (PST) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17112 for ; Sun, 17 Feb 2002 12:34:21 -0800 (PST) Received: from attglobal.net (slip-12-64-18-33.mis.prserv.net[12.64.18.33]) by prserv.net (out4) with SMTP id <20020217203418204064lgmke>; Sun, 17 Feb 2002 20:34:18 +0000 Message-ID: <3C7013C8.95CF05D1@attglobal.net> Date: Sun, 17 Feb 2002 14:34:16 -0600 From: Sebastian Thalanany X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: gdommety@cisco.com Subject: Re: [mobile-ip] Length field definitions - rfc3115 References: <3C6FE255.C2FA49C3@attglobal.net> <3C6FEB76.650DEF8E@cisco.com> Content-Type: multipart/alternative; boundary="------------EBCC46E02AA04250DB7FD527" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------EBCC46E02AA04250DB7FD527 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Kent, Since rfc3115 is based on rfc2002, which was obsoleted last month by rfc3220, it would perhaps be preferrable to update rfc3115 with the general format specification for a skippable extension(NVSE) as specified in rfc3220. If the intent of the "Reserved" field is to extend the Type field, as indicated in section 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the following definitions for a CVSE element and an NVSE element may avoid ambiguities in interpretation: 1. CVSE Length Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the Type, Length and the Reserved fields. 2. NVSE Length Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the Type, Length and the Reserved fields. or Length Length in bytes of the Value(data) field within this extension. It does NOT include the bytes associated with the Type, Length fields. The Length field MUST be set to 2 plus the length of the Value(data) field, where the additional two octets are required to include the length of the Reserved field. For the NVSE, please confirm one of the two proposed definitions. Thanks. Regards, Sebastian kleung wrote: > Hi Sebastian. Good pt. > > 1. CVSE > > Length Length in bytes of this extension, not including > the > Type, Reserved, and Length fields. > > 2. NVSE > > Length Length in bytes of this extension, not including the Type > and Length bytes. > > Is this sufficient? This description is used by other RFCs and drafts > as > well. Though the text you provided is more descriptive. But the > Value(data) would have to be explained further for clarity too. > > Kent > > Sebastian Thalanany wrote: > > > Hello Gopal, > > The Length field definitions for the Mobile IP > > Vendor/Organization specific extensions, namely, the CVSE and the NVSE > > perhaps require clarifications. Here is the text for the definitions > > for the Length field for the CVSE and the NVSE elements: > > > > 1. CVSE > > > > Length Length in bytes of the Value(data) field within > > this extension. It does NOT include the bytes associated with the > > Type, Length and the Reserved fields. > > > > > > 2. NVSE > > > > Length Length in bytes of the Value(data) field within > > this extension. It does NOT include the bytes associated with the > > Type, Length and the Reserved fields. > > > > or > > > > Length Length in bytes of the Value(data) field within > > this extension. It does NOT include the bytes associated with the > > Type, Length fields. The Length field MUST be set to 2 plus the length > > of the Value(data) field, where the additional two octets are required > > to include the length of the Reserved field. > > > > Please clarify the Length field definition for the NVSE, from > > among the two possible definitions suggested above, so that the text > > in the 3GPP2 text can be updated appropriately for the usage of the > > Length field associated with the NVSE. The suggested definitions > > above, for the CVSE and the NVSE, are based on the recently published > > RFC3220, section 1.9. There is no ambiguity with regard to the > > existing definition for the Length field associated with the CVSE in > > the RFC3115. Perhaps the references to RFC2002 would be replaced with > > references to RFC3220. > > > > Thanks. > > > > Regards, > > Sebastian > > > > -- > | | Kent Leung > :|: :|: IOS Development > :|||: :|||: Voice: 408.526.5030 > :|||||||: :|||||||: Email: kleung@cisco.com > .:|||||||||:.:|||||||||:. URL : http://wwwin-mobileip:8000 > c i s c o S y s t e m s "Enabling the mobile wireless age!" --------------EBCC46E02AA04250DB7FD527 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Kent,
                      Since rfc3115 is based on rfc2002, which was obsoleted last month by rfc3220, it would perhaps be preferrable to update rfc3115 with the general format specification for a skippable extension(NVSE) as specified in rfc3220. If the intent of the "Reserved" field is to extend the Type field, as indicated in section 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the following definitions for a CVSE element and an NVSE element may avoid ambiguities in interpretation:

1. CVSE
         Length         Length in bytes of the Value(data) field within
 this extension.  It does NOT include the bytes associated with the
 Type, Length and the Reserved fields.
 

2. NVSE
       Length         Length in bytes of the Value(data) field within
 this extension.  It does NOT include the bytes associated with the
 Type, Length and the Reserved fields.

 or

        Length        Length in bytes of the Value(data) field within
 this extension. It does NOT include the bytes associated with the
Type, Length fields. The Length field MUST be set to 2 plus the length
of the Value(data) field, where the additional two octets are required
 to include the length of the Reserved field.

        For the NVSE, please confirm one of the two proposed definitions.

        Thanks.

Regards,
   Sebastian

kleung wrote:

Hi Sebastian.  Good pt.

1. CVSE

        Length         Length in bytes of  this extension, not including
the
              Type, Reserved, and Length fields.

2. NVSE

   Length     Length in bytes of this extension, not including the Type
              and Length bytes.

Is this sufficient?  This description is used by other RFCs and drafts
as
well.  Though the text you provided is more descriptive.  But the
Value(data) would have to be explained further for clarity too.

Kent

Sebastian Thalanany wrote:

> Hello Gopal,
>               The Length field definitions for the Mobile IP
> Vendor/Organization specific extensions, namely, the CVSE and the NVSE
> perhaps require clarifications. Here is the text for the definitions
> for the Length field for the CVSE and the NVSE elements:
>
> 1. CVSE
>
>         Length         Length in bytes of the Value(data) field within
> this extension.  It does NOT include the bytes associated with the
> Type, Length and the Reserved fields.
>
>
> 2. NVSE
>
>         Length         Length in bytes of the Value(data) field within
> this extension.  It does NOT include the bytes associated with the
> Type, Length and the Reserved fields.
>
> or
>
>         Length        Length in bytes of the Value(data) field within
> this extension. It does NOT include the bytes associated with the
> Type, Length fields. The Length field MUST be set to 2 plus the length
> of the Value(data) field, where the additional two octets are required
> to include the length of the Reserved field.
>
>         Please clarify the Length field definition for the NVSE, from
> among the two possible definitions suggested above, so that the text
> in the 3GPP2 text can be updated appropriately for the usage of the
> Length field associated with the NVSE. The suggested definitions
> above, for the CVSE and the NVSE, are based on the recently published
> RFC3220, section 1.9. There is no ambiguity with regard to the
> existing definition for the Length field associated with the CVSE in
> the RFC3115. Perhaps the references to RFC2002 would be replaced with
> references to RFC3220.
>
>         Thanks.
>
> Regards,
>     Sebastian
>

--
     |           |                   Kent Leung
    :|:         :|:                  IOS Development
   :|||:       :|||:                 Voice: 408.526.5030
  :|||||||:   :|||||||:              Email: kleung@cisco.com
.:|||||||||:.:|||||||||:.            URL  : http://wwwin-mobileip:8000
 c i s c o S y s t e m s             "Enabling the mobile wireless age!"

--------------EBCC46E02AA04250DB7FD527-- From owner-mobile-ip@sunroof.eng.sun.com Sun Feb 17 16:43:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11870 for ; Sun, 17 Feb 2002 16:43:28 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23683; Sun, 17 Feb 2002 13:43:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19104; Sun, 17 Feb 2002 13:43:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HLgHKL016182 for ; Sun, 17 Feb 2002 13:42:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1HLgHto016181 for mobile-ip-dist; Sun, 17 Feb 2002 13:42:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1HLgEKL016174 for ; Sun, 17 Feb 2002 13:42:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19062 for ; Sun, 17 Feb 2002 13:42:16 -0800 (PST) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00107 for ; Sun, 17 Feb 2002 14:42:15 -0700 (MST) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KEEW5H4RR290O6Z7@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 18 Feb 2002 08:42:09 +1100 Received: from kapow (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F02420005 for ; Sun, 17 Feb 2002 21:42:09 +0000 (/etc/localtime) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 6516020005 for ; Mon, 18 Feb 2002 08:42:05 +1100 (EST) Date: Mon, 18 Feb 2002 08:41:30 +1100 From: Greg Daley Subject: Re: [mobile-ip] Meaning of Alternate Care-of Address? To: mobile-ip@sunroof.eng.sun.com Message-id: <3C70238A.E043E48F@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <004201c1b7ea$443922f0$2c6015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James, quick answer below. James Kempf wrote: > > Hi folks, > > Hopefullly, I can get some response on this between the excellent but > voluminous MIPv6 security debate. > > Section 10.9 of draft-ietf-mobileip-ipv6-15.txt states: > > In any Binding Update > sent by a mobile node, the care-of address (either the Source Address > in the packet's IPv6 header or the Care-of Address in the Alternate > Care-of Address Sub-Option of the Binding Update) MUST be set to one > of the care-of addresses currently in use by the mobile node or to > the mobile node's home address. > > What does "in use" mean? In Hierarchical MIPv6, the Regional Care of Address (RCoA) is an address either of the MAP (Extended mode) or on a network adjacent to the map (Basic mode). This is present as the Alt-CoA in some binding updates (to HA/CNs). Additionally, the local host should be to configure this address (In basic mode) as a local address (maybe /128), but not in extended mode. I'm not about to comment on usage scenarios, but the Address does not have to be a locally configured interface address, but one valid to use (for example, in conjunction with HMIPv6); Greg From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 00:43:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18926 for ; Mon, 18 Feb 2002 00:43:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12333; Sun, 17 Feb 2002 22:42:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11222; Sun, 17 Feb 2002 21:42:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I5fbKL016734 for ; Sun, 17 Feb 2002 21:41:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1I5faVr016733 for mobile-ip-dist; Sun, 17 Feb 2002 21:41:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I5fXKL016726 for ; Sun, 17 Feb 2002 21:41:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA23698 for ; Sun, 17 Feb 2002 21:41:35 -0800 (PST) Received: from systat.com ([203.90.88.140]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA06362 for ; Sun, 17 Feb 2002 22:41:25 -0700 (MST) Received: from temp1 [192.9.200.164] by company.mail [192.9.200.9] with SMTP (MDaemon.PRO.PRO.v5.0.0.R) for ; Mon, 18 Feb 2002 11:13:04 +0530 Message-ID: <00c801c1b829$c13db060$a4c809c0@192.9.200.9> From: "thrineshwara" To: References: <001401c1b5dd$dfe34d20$a4c809c0@192.9.200.9> <018101c1b609$9efc99c0$8a1b6e0a@arenanet.fi> Subject: Re: [mobile-ip] Regarding security aspects for mobile IP Date: Mon, 18 Feb 2002 11:10:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MDRemoteIP: 192.9.200.164 X-Return-Path: thrineshwara@cranessoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks a lot Jari. I think now I am in sync. with what is going on at the moment. -Thrinesh ----- Original Message ----- From: "Jari Arkko" To: "thrineshwara" Cc: Sent: Friday, February 15, 2002 6:14 PM Subject: Re: [mobile-ip] Regarding security aspects for mobile IP > > As per my latest understanding, the current IPSec protocol is found either not suitable or inadequate in > > providing the security for Binding Update messages. New methods have to be identified yet. > > > > Could you please update me on the recent developments in this regard? > > You could check the archieve for the "few" messages on the subject, > if you want the recent developments ;-) > > But overall the situation is that understanding of the MIPv6 security requirements > has grown a lot during the last year or so. We have a better picture now on the kinds > of needs we have for global MN - CN signaling security, the need to check CoAs, > the potential dangers to third parties, and so on. An effort is in place to develop > a solution, and I believe we have most of the components as long as we could agree > on which ones to pick ;-) BU authorization itself we believe can be handled with > a few basic techniques called RR and CGA. > > Jari > > > > ______________________________________________________ This email with any attachments is for the exclusive use of the intended recipient/s & may contain confidential & legally privileged information. If you are not the intended recipient pls notify the sender immediately & delete the email from your system. Any unauthorised use, disclosure, printing, dissemination, forwarding or copying of this mail is strictly prohibited and unlawful. Visit us at: http://www.cranessoftware.com From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 01:22:23 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19349 for ; Mon, 18 Feb 2002 01:22:23 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28475; Sun, 17 Feb 2002 22:22:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23558; Sun, 17 Feb 2002 22:22:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I6LCKL016812 for ; Sun, 17 Feb 2002 22:21:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1I6LC1C016811 for mobile-ip-dist; Sun, 17 Feb 2002 22:21:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1I6L9KL016804 for ; Sun, 17 Feb 2002 22:21:09 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15325 for ; Sun, 17 Feb 2002 22:21:11 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17982 for ; Sun, 17 Feb 2002 22:21:10 -0800 (PST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1I6LAh11044; Sun, 17 Feb 2002 22:21:10 -0800 (PST) Received: from cisco.com (sjc-vpn1-33.cisco.com [10.21.96.33]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABT64338; Sun, 17 Feb 2002 22:20:51 -0800 (PST) Message-ID: <3C709D67.C14840A7@cisco.com> Date: Sun, 17 Feb 2002 22:21:27 -0800 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: gdommety@cisco.com Subject: Re: [mobile-ip] Length field definitions - rfc3115 References: <3C6FE255.C2FA49C3@attglobal.net> <3C6FEB76.650DEF8E@cisco.com> <3C7013C8.95CF05D1@attglobal.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sebastian Thalanany wrote: > Hello Kent, > Since rfc3115 is based on rfc2002, which was > obsoleted last month by rfc3220, it would perhaps be preferrable to > update rfc3115 with the general format specification for a skippable > extension(NVSE) as specified in rfc3220. If the intent of the > "Reserved" field is to extend the Type field, as indicated in section > 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the > following definitions for a CVSE element and an NVSE element may avoid > ambiguities in interpretation: > > 1. CVSE > Length Length in bytes of the Value(data) field > within > this extension. It does NOT include the bytes associated with the > Type, Length and the Reserved fields. > > > 2. NVSE > Length Length in bytes of the Value(data) field within > this extension. It does NOT include the bytes associated with the > Type, Length and the Reserved fields. > Not this. > > or > > Length Length in bytes of the Value(data) field within > this extension. It does NOT include the bytes associated with the > Type, Length fields. The Length field MUST be set to 2 plus the length > > of the Value(data) field, where the additional two octets are required > > to include the length of the Reserved field. > This one. Length is always what follows that field in the extension. This is consistent with 1.9, 1.10 and 1.11. Thanks. Kent > > For the NVSE, please confirm one of the two proposed > definitions. > > Thanks. > > Regards, > Sebastian From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 07:07:56 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00890 for ; Mon, 18 Feb 2002 07:07:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12938; Mon, 18 Feb 2002 04:07:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14501; Mon, 18 Feb 2002 04:07:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IC6EKL017257 for ; Mon, 18 Feb 2002 04:06:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IC6E91017256 for mobile-ip-dist; Mon, 18 Feb 2002 04:06:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IC6BKL017249 for ; Mon, 18 Feb 2002 04:06:11 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23963 for ; Mon, 18 Feb 2002 04:06:13 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23170 for ; Mon, 18 Feb 2002 04:06:07 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1IC5rB22645 for ; Mon, 18 Feb 2002 13:05:53 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Feb 18 13:05:52 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 13:05:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803258A98@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Mon, 18 Feb 2002 13:05:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Micheal, One addition/question below: > -----Original Message----- > From: Michael Roe [mailto:mroe@microsoft.com] > Sent: Thursday, February 14, 2002 11:27 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > My current view is that: > - you have to do RR for the CoA in all cases; => If you use RR+CGA, and assuming that a user switched off the address privacy knob so that the CoA is CG (same id as the HoA), wouldn't you avoid RR for the CoA after the BSA is established? Hesham > - if you have an IPSec SA, you don't need RR for the HoA; > - if the HoA is cryptographically generated, you still > need to check > that > it's RR > > Mike > From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 08:31:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02461 for ; Mon, 18 Feb 2002 08:31:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04915; Mon, 18 Feb 2002 06:31:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21331; Mon, 18 Feb 2002 05:31:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDULKL017361 for ; Mon, 18 Feb 2002 05:30:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IDULrs017358 for mobile-ip-dist; Mon, 18 Feb 2002 05:30:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDUCKL017335 for ; Mon, 18 Feb 2002 05:30:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IDU9l09785; Mon, 18 Feb 2002 14:30:09 +0100 (MET) Date: Mon, 18 Feb 2002 14:15:47 +0100 (CET) From: Erik Nordmark Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] To: Glenn Morrow Cc: Erik Nordmark , "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E0210ADA6@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Actually there is something new - some proposed decisions of the other DTs. > Apparently some have found that this proposed decison is somehow being use > to say we can't do piggybacking. > > I suggest that people may not understand exactly what this reasoning is and > that the persons who believe in this excuse not to do piggybacking detail, > with a precise and hopefully concise example, the exact scenario they are > thinking of. They need to answer the question of "why do you need a BSA to > use piggybacking?". > > I have also seen euphemisms such as "this makes me sick", etc.. referenced > by IPv6 WG members to whom it is well known that they do not see value in > MIP anyway much less RO'd MIP. While this could also be seen as constructive > criticism, I believe or rather hope, that the persons on this mail list do > see value in it and the "sick" reference refers to the persons inability to > see value in MIP itself, let alone the piggybacking and Route Optimization. > The fact that the security PDU portions of a binding are no longer > associated with IPSEC, allows piggybacking to work and makes the technical > portion of the arguments against piggybacking false. > > So it seems to me that there is no true technical excuse for not allowing > piggybacking and I can only infer logically that some deal making has been > done in order to progress the standard on some sort of deadline self-imposed > by some conflicting external SDOs. This prompted my initial criticism in > that I wanted to remind people that this is the IETF and we are supposed to > deal with the IP problem space - not the least common denominator link > layer. > > I hope you see this as constructive and not a bantor. Glenn, was the above sentence a question to me and Charlie (the "to" list) or to all of the WG? I don't see the constructive propopsal you are making for how to move forward. Could you clarify what it is? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 08:31:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02473 for ; Mon, 18 Feb 2002 08:31:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05040; Mon, 18 Feb 2002 06:31:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21358; Mon, 18 Feb 2002 05:31:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDUKKL017357 for ; Mon, 18 Feb 2002 05:30:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IDUKbl017355 for mobile-ip-dist; Mon, 18 Feb 2002 05:30:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDUBKL017334 for ; Mon, 18 Feb 2002 05:30:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IDU8l09777; Mon, 18 Feb 2002 14:30:08 +0100 (MET) Date: Mon, 18 Feb 2002 14:09:57 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: James Kempf Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <015f01c1b589$9ed9b7a0$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > If we don't start now, it will take even longer to get the change. I > don't > understand why we couldn't simply allow piggybacking > with the caveat that you shouldn't use it with IPSec, then start > working with the IPSec group to come up with a solution that will work. > The MN doesn't have to send the BU as part of an IPSec secured > TCP stream, it could send it separately. I don't want to replay the arguments that have been made on the mailing list on the subject of piggybacking, but I'm pretty sure this was discussed in the past. > > I think Jeff Schiller already pointed out (but I could misremember) > > that MIPv6 BUs don't fit with the available IPsec selectors which > would seem > > like a hint that we shouldn't expect IPsec to change. > > So I'm having a hard time seeing how to move forward at the moment. > > > > Sorry, since I wasn't part of the DT, I'm not up on the specifics of > this. This was done in the MIP working group as part Jeff's concerns. Either in his presentation or in email clarifying things later. > What is the problem with simply specifying that the BU header > is within the authenticated or encrypted part of the packet covered > by the AH or ESP header? Even if you don't do piggybacking you still have an issue of selector granularity - IPsec selectors don't operate on the content of destination option headers (i.e. on what options are present). Thus you couldn't express if this is a BU apply this IPsec processing if this is TCP to port 22 apply this IPsec processing etc since the first rule, without any piggybacking, can't be expressed given the selectors in RFC 2401. > I can't see any problem with it in general, just with respect to LMM > solutions that depend on route optimization. OK Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 08:32:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02521 for ; Mon, 18 Feb 2002 08:32:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25656; Mon, 18 Feb 2002 06:31:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21398; Mon, 18 Feb 2002 05:31:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDUKKL017356 for ; Mon, 18 Feb 2002 05:30:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IDUKL3017354 for mobile-ip-dist; Mon, 18 Feb 2002 05:30:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDUBKL017333 for ; Mon, 18 Feb 2002 05:30:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IDU9l09781; Mon, 18 Feb 2002 14:30:09 +0100 (MET) Date: Mon, 18 Feb 2002 14:11:19 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: James Kempf Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <019a01c1b58b$07c7f0f0$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > Do you know if this piggybacking is end-to-end in the i-mode network > > i.e. the signalling is delivered to the http server? > > Or do they just share the same packet over the radio link with > > the signalling message being delivered to some other entity? > > > > The signaling is delivered to the i-mode server which is a proxy > that converts the HTTP message from the proprietary > TCP-like protocol that is optimized for PDC into > regular TCP. I don't know if the signaling is used by > the i-mode server or not, but it is certainly not used > by the IP network. > > If you want, I can try to find out more details. If you have additional details you can share I'd be interested. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 08:40:06 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02650 for ; Mon, 18 Feb 2002 08:40:06 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA25439; Mon, 18 Feb 2002 05:40:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22659; Mon, 18 Feb 2002 05:39:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDdIKL017502 for ; Mon, 18 Feb 2002 05:39:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IDdI1l017501 for mobile-ip-dist; Mon, 18 Feb 2002 05:39:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IDdEKL017494 for ; Mon, 18 Feb 2002 05:39:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05705 for ; Mon, 18 Feb 2002 05:39:17 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07345 for ; Mon, 18 Feb 2002 06:39:16 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g1IDcqt18952 for ; Mon, 18 Feb 2002 14:38:52 +0100 (MET) Message-ID: <3C7103ED.1A174C6D@inrialpes.fr> Date: Mon, 18 Feb 2002 14:38:53 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <4DA6EA82906FD511BE2F00508BCF053803258A98@Esealnt861.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------C3E5A4BB926771C3C544E1DD" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------C3E5A4BB926771C3C544E1DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit " Hi Hesham, Hesham Soliman (ERA)" wrote: > Micheal, > > One addition/question below: > > > -----Original Message----- > > From: Michael Roe [mailto:mroe@microsoft.com] > > Sent: Thursday, February 14, 2002 11:27 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > > My current view is that: > > - you have to do RR for the CoA in all cases; > > => If you use RR+CGA, and assuming that a user > switched off the address privacy knob so that the > CoA is CG (same id as the HoA), wouldn't you avoid RR > for the CoA after the BSA is established? > using a CGA CoA will prevent a malicious host from using your address as CoA in order to bomd you....however a malicious could still register a bogus CGA address of your network just for the sake of flooding your network (not a particular host)....that why RR might still be useful in this case... Regards, Claude. > > Hesham > > > - if you have an IPSec SA, you don't need RR for the HoA; > > - if the HoA is cryptographically generated, you still > > need to check > > that > > it's RR > > > > > Mike > > -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------C3E5A4BB926771C3C544E1DD Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit "
Hi Hesham,

Hesham Soliman (ERA)" wrote:

Micheal,

One addition/question below:

  > -----Original Message-----
  > From: Michael Roe [mailto:mroe@microsoft.com]
  > Sent: Thursday, February 14, 2002 11:27 PM
  > To: mobile-ip@sunroof.eng.sun.com
  > Subject: Re: [mobile-ip] Piggybacking - DT recommendation
  >
  >  My current view is that:
  >  - you have to do RR for the CoA in all cases;

=> If you use RR+CGA, and assuming that a user
switched off the address privacy knob so that the
CoA is CG (same id as the HoA), wouldn't you avoid RR
for the CoA after the BSA is established?
 

using a CGA CoA will prevent a malicious host from using your address as CoA
in order to bomd you....however a malicious could still register a bogus
CGA address of your network just for the sake of flooding your network (not
a particular host)....that why RR might still be useful in this case...

Regards,

Claude.
 

 
Hesham

  >  - if you have an IPSec SA, you don't need RR for the HoA;
  >  - if the HoA is cryptographically generated, you still
  > need to check
  > that
  >    it's RR

  >
  > Mike
  >

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------C3E5A4BB926771C3C544E1DD-- From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 10:40:08 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05121 for ; Mon, 18 Feb 2002 10:40:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14009; Mon, 18 Feb 2002 07:40:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13698; Mon, 18 Feb 2002 07:39:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFcsKL017615 for ; Mon, 18 Feb 2002 07:38:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IFcsTD017614 for mobile-ip-dist; Mon, 18 Feb 2002 07:38:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFcmKL017604 for ; Mon, 18 Feb 2002 07:38:49 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IFcdl19963; Mon, 18 Feb 2002 16:38:39 +0100 (MET) Date: Mon, 18 Feb 2002 16:32:03 +0100 (CET) From: Erik Nordmark Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: "Your message with ID" <15468.19393.193839.79@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In fact, there are three different kinds of > state: > > 1) cached state > 2) soft state > 3) hard state > > Route optimization was in class (1). Requiring > that HAO's not be accepted until there be a RR etc > test first pushes it into class (2). It was my > mistake at last IETF to claim that they were hard > state (3) such as TCP state, as Thomas Narten > correctly pointed out. > > However, moving from (1) to (2) is still quite > a significant change. Since I don't have the definition of the above types of state I can't tell exactly what you are saying. The difference with HOA verification against a BCE appears when the BCE has been lost on the CN. But if the BCE is merely stale (i.e. a binding update didn't reach the CN when the MN moved from one CoA to another) then whether or not the HOA is verified against the BCE doesn't appear to matter - if it isn't packets towards the MN will go to the old CoA and presumably be dropped on the floor. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 10:40:24 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05134 for ; Mon, 18 Feb 2002 10:40:24 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20605; Mon, 18 Feb 2002 08:40:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13733; Mon, 18 Feb 2002 07:40:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFciKL017595 for ; Mon, 18 Feb 2002 07:38:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IFciZs017594 for mobile-ip-dist; Mon, 18 Feb 2002 07:38:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFceKL017587 for ; Mon, 18 Feb 2002 07:38:41 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IFcdl19959; Mon, 18 Feb 2002 16:38:39 +0100 (MET) Date: Mon, 18 Feb 2002 16:28:56 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: mroe@microsoft.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > There seem to be two separate authorization checks that are needed > before accepting a binding update: > (a) Check that the sender is authorized to use the HoA > (b) Check that the sender is authorized to the the CoA > > As far as I can see, an IPsec SA established using, for example, > X.509 certificates with IP addresses (not DNS names) in them is > perfectly adequate for checking HoA authorization. > It's not so good for checking CoA authorization, because at the time > the > certificate is issued you don't know what CoA the node is going to be > using. Mike, The above assumes that there are CAs for PKIs that will actually put IP addresses as subject(Alt)name, and that folks will actually trust those CAs to have correct IP addresses in the certs. It also assumes that the IETF community thinks it is a bad idea to keep IP addresses in certificates. RFC 2956, which is a report from an IAB workshop, in section 3.4 seems to indicate that this might not be considered a good idea but instead something that should be avoided. > My current view is that: > - you have to do RR for the CoA in all cases; > - if you have an IPSec SA, you don't need RR for the HoA; Given your text above I think you omitted a few conditionals here like - the subject(atl)name in the certificate used to create the IPsec SA is the HoA, and - the IKE implementation verified that this IP address was used during the key exchange > - if the HoA is cryptographically generated, you still need to check > that > it's RR Yep. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 10:40:25 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05145 for ; Mon, 18 Feb 2002 10:40:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14006; Mon, 18 Feb 2002 07:40:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13697; Mon, 18 Feb 2002 07:39:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFcoKL017609 for ; Mon, 18 Feb 2002 07:38:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IFco5A017605 for mobile-ip-dist; Mon, 18 Feb 2002 07:38:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFcjKL017597 for ; Mon, 18 Feb 2002 07:38:46 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IFccl19942; Mon, 18 Feb 2002 16:38:38 +0100 (MET) Date: Mon, 18 Feb 2002 15:45:13 +0100 (CET) From: Erik Nordmark Subject: Re: (MANY) Re: [mobile-ip] Home Address Option: design team recommendation To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200202161523.g1GFNHg30033@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In your previous mail you wrote: > > > => basically BCE state will become hard state. > > => should be more "harder" than "hard". > > Per what definition of hard and soft state? Per what definition of "harder"? > => in the HAO/BCE case, the problem is the MN should have a good idea > of the state of its BCEs on its CNs. So the BU/BA has to be more robust > and there is a need for "will delete" messages from CNs to MNs. > Nothing hard (:-) but this should give a heavier protocol... I agree about the need for the MN to be able to know whether a CN has a BCE for it, and how to "resynchronize" when the MN's knowledge doesn't match the state at the CN. This is an effect of making the BCE state matter when receiving packets from the MN. But attempts at assigning labels like "hard" or "harder" misses the actual point IMHO. Even when using the BCE state for packets sending to the MN it is critical to not have stale BCEs since they are likely to cause packets to be dropped on the floor because they get sent to an old CoA. So keeping the BCE state current is needed without the proposed HAO changes. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 10:51:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05559 for ; Mon, 18 Feb 2002 10:51:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16409; Mon, 18 Feb 2002 07:51:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15154; Mon, 18 Feb 2002 07:51:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFoPKL017769 for ; Mon, 18 Feb 2002 07:50:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IFoPfO017768 for mobile-ip-dist; Mon, 18 Feb 2002 07:50:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFoLKL017761 for ; Mon, 18 Feb 2002 07:50:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IFoJl20926; Mon, 18 Feb 2002 16:50:20 +0100 (MET) Date: Mon, 18 Feb 2002 16:45:55 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Home Address Option: design team recommendation To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C6C597B.37821942@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 2.1. THREAT IS NOT SIGNIFICANT > > > > While the exact nature and seriousness of the threat may be > > discussed, it seems that the "do no harm" principle is not > > fulfilled. This is because the threat appears harder than the > > one caused by regular source address spoofing. > > I think that the threat is significant, but not drastically significant. > I think that, even without remedy, no self-respecting Internet > wrecker would mess with it, since there are other better and > more effective ways to go about it. Charlie, Do you have specific examples of what better and more effective ways will exist for the attackers? Thanks, Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 10:57:19 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05703 for ; Mon, 18 Feb 2002 10:57:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18495; Mon, 18 Feb 2002 08:57:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15652; Mon, 18 Feb 2002 07:57:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFuLKL017835 for ; Mon, 18 Feb 2002 07:56:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IFuL0t017834 for mobile-ip-dist; Mon, 18 Feb 2002 07:56:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IFuIKL017827 for ; Mon, 18 Feb 2002 07:56:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10154 for ; Mon, 18 Feb 2002 07:56:19 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26890 for ; Mon, 18 Feb 2002 08:56:19 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA27398; Mon, 18 Feb 2002 07:56:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1IFuHK02341; Mon, 18 Feb 2002 07:56:17 -0800 X-mProtect:  Mon, 18 Feb 2002 07:56:17 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3onzZH; Mon, 18 Feb 2002 07:56:15 PST Message-ID: <3C7123C1.634EEDE9@iprg.nokia.com> Date: Mon, 18 Feb 2002 07:54:41 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Mobile IP Working Group Subject: Re: [mobile-ip] Home Address Option: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, Yes, I do. I do not want to discuss that on this mailing list. Regards, Charlie P. Erik Nordmark wrote: > > > 2.1. THREAT IS NOT SIGNIFICANT > > > > > > While the exact nature and seriousness of the threat may be > > > discussed, it seems that the "do no harm" principle is not > > > fulfilled. This is because the threat appears harder than the > > > one caused by regular source address spoofing. > > > > I think that the threat is significant, but not drastically significant. > > I think that, even without remedy, no self-respecting Internet > > wrecker would mess with it, since there are other better and > > more effective ways to go about it. > > Charlie, > > Do you have specific examples of what better and more effective > ways will exist for the attackers? > > Thanks, > Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 11:07:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06121 for ; Mon, 18 Feb 2002 11:07:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18930; Mon, 18 Feb 2002 08:07:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16912; Mon, 18 Feb 2002 08:07:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IG6mKL017930 for ; Mon, 18 Feb 2002 08:06:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IG6l16017929 for mobile-ip-dist; Mon, 18 Feb 2002 08:06:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IG6hKL017922 for ; Mon, 18 Feb 2002 08:06:44 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IG6gl22604; Mon, 18 Feb 2002 17:06:43 +0100 (MET) Date: Mon, 18 Feb 2002 17:02:18 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: charliep@iprg.nokia.com Cc: Mobile IP Working Group In-Reply-To: "Your message with ID" <3C6C7780.4CFAA7B4@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > For UnVCoAs, more care is needed. We can make some simple > improvements to the way that correspondent nodes handle UnvHAOs > that will substantially reduce or eliminate any residual threat > of a viable reflector attack. The first weapon in the arsenal > against these attacks is to tag outgoing packets with the > unverifiable care-of address. Charlie, How would this tagging work in particular how would it work with protocols on top of UDP without requiring modifications to the socket API? Later you talk about a UnvHOA cache - is the assumption that a packet received with an unverified HOA would cause an entry to be created in this cache? (if a matching entry doesn't already exist) If so how could the CN behave when this UnvHOA cache is full? > There is a very simple firewall policy that will add a lot of > protection for general networks. That is, a firewall can > drop packets that have the care-of address tag, if there is > no reasonable home agent which might tunnel such a packet to > a mobile node. This will add further protection, in addition > to the traceability of the care-of address. If I was implementing a MIPv6 MN taking the above into consideration it would seem like the way to minimize the risk of firewalls dropping packets destined to the MN the prudent thing would be to only send packet with HOA when it is known that the CN has a BCE. So it seems like the net result of allowing the behavior would be the same as with the design team's recommendation, with substancial additional complexity in the specification. If this need for relaxing HAO processing on the CN is needed it can be added later as far as I can tell. > I hope that this will be sufficient to persuade the design > team members to endorse continued operation of the Home Address > Option, and thus to maintain the improvements in performance > which would be lost if reverse tunneling were always required > until a Binding Cache entry could be established. That process > could take hundreds of milliseconds, amounting to a quite > noticeable loss of responsivity. Why loss of connectivity? Before the BCE is established the MN and CN can communicate using bidirectional tunneling. Do you count that as "loss of connectivity"? > Furthermore, if a correspondent > node loses its Binding Cache entry for any reason, then packets > from the mobile node would be black-holed. This is intolerable, > especially because it is guaranteed that somewhere, sometime, > we will see correspondent nodes losing their cache entries. > My proposed mechanism will represent a much more robust way > to handle this problem. The design team's recommendation was talking about using an error notification mechanism to handle this case. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 11:23:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07149 for ; Mon, 18 Feb 2002 11:23:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23927; Mon, 18 Feb 2002 09:23:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09498; Mon, 18 Feb 2002 08:23:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IGMaKL018003 for ; Mon, 18 Feb 2002 08:22:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IGMasx018002 for mobile-ip-dist; Mon, 18 Feb 2002 08:22:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IGMXKL017995 for ; Mon, 18 Feb 2002 08:22:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04326 for ; Mon, 18 Feb 2002 08:22:35 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21710 for ; Mon, 18 Feb 2002 08:22:34 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1IGIUH01007; Mon, 18 Feb 2002 10:18:31 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CYXM>; Mon, 18 Feb 2002 10:18:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E021B64ED@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark Cc: Erik Nordmark , "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] Date: Mon, 18 Feb 2002 10:18:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B897.E7BB9F90" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B897.E7BB9F90 Content-Type: text/plain; charset="iso-8859-1" I guess this was to the whole WG and people such as yourself. Realistically it seems that existing implementations have a desire to use IPSEC with the MIP. Also it seems that quite a few implementation actually did implement piggybacking. So why don't we just use IPSEC and restrict the piggybacking. This seems like the fastest path to agreement, it also fits in well with the whole wireline IPSEC story in that code is still reused. It also doesn't sacrifice the advantages of piggybacking. I honestly think the MIP option signaling should be protected by ESP integrity at a minimum instead of the AH and piggybacking disallowed when the credentials are different. This seems like a very reasonable way forward with as Charlie mentions the caveat that work should continue to do piggybacking even when the credentials are different. I still see or rather hope that the BSA vs RR only question is disjunct. These are my thoughts on how it should end up at this particular point in time. This also seems to be the most amicable for the existing implementations and IPv6 stack size in general. I am open to other thoughts though but I don't think we need to kill piggybacking and the solutions should not assume that it is. Thanks, Glenn > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, February 18, 2002 7:16 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: Erik Nordmark; Charles E. Perkins; mobile-ip@sunroof.eng.sun.com > Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] > > > > Actually there is something new - some proposed decisions > of the other DTs. > > Apparently some have found that this proposed decison is > somehow being use > > to say we can't do piggybacking. > > > > I suggest that people may not understand exactly what this > reasoning is and > > that the persons who believe in this excuse not to do > piggybacking detail, > > with a precise and hopefully concise example, the exact > scenario they are > > thinking of. They need to answer the question of "why do > you need a BSA to > > use piggybacking?". > > > > I have also seen euphemisms such as "this makes me sick", > etc.. referenced > > by IPv6 WG members to whom it is well known that they do > not see value in > > MIP anyway much less RO'd MIP. While this could also be > seen as constructive > > criticism, I believe or rather hope, that the persons on > this mail list do > > see value in it and the "sick" reference refers to the > persons inability to > > see value in MIP itself, let alone the piggybacking and > Route Optimization. > > The fact that the security PDU portions of a binding are no longer > > associated with IPSEC, allows piggybacking to work and > makes the technical > > portion of the arguments against piggybacking false. > > > > So it seems to me that there is no true technical excuse > for not allowing > > piggybacking and I can only infer logically that some deal > making has been > > done in order to progress the standard on some sort of > deadline self-imposed > > by some conflicting external SDOs. This prompted my initial > criticism in > > that I wanted to remind people that this is the IETF and we > are supposed to > > deal with the IP problem space - not the least common > denominator link > > layer. > > > > I hope you see this as constructive and not a bantor. > > Glenn, > was the above sentence a question to me and Charlie (the "to" list) or > to all of the WG? > > I don't see the constructive propopsal you are making for how > to move forward. > Could you clarify what it is? > > Erik > > ------_=_NextPart_001_01C1B897.E7BB9F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: Re: [mobile-ip] Piggybacking - DT = recommendation]

I guess this was to the whole WG and people such as = yourself.

Realistically it seems that existing implementations = have a desire to use IPSEC with the MIP. Also it seems that quite a few = implementation actually did implement piggybacking.

So why don't we just use IPSEC and restrict the = piggybacking.

This seems like the fastest path to agreement, it = also fits in well with the whole wireline IPSEC story in that code is = still reused. It also doesn't sacrifice the advantages of = piggybacking.

I honestly think the MIP option signaling should be = protected by ESP integrity at a minimum instead of the AH and = piggybacking disallowed when the credentials are different.

This seems like a very reasonable way forward with as = Charlie mentions the caveat that work should continue to do = piggybacking even when the credentials are different.

I still see or rather hope that the BSA vs RR only = question is disjunct.

These are my thoughts on how it should end up at this = particular point in time. This also seems to be the most amicable for = the existing implementations and IPv6 stack size in general.

I am open to other thoughts though but I don't think = we need to kill piggybacking and the solutions should not assume that = it is.

Thanks,
Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
> Sent: Monday, February 18, 2002 7:16 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: Erik Nordmark; Charles E. Perkins; = mobile-ip@sunroof.eng.sun.com
> Subject: RE: [Fwd: Re: [mobile-ip] Piggybacking = - DT recommendation]
>
>
> > Actually there is something new - some = proposed decisions
> of the other DTs.
> > Apparently some have found that this = proposed decison is
> somehow being use
> > to say we can't do piggybacking.
> >
> > I suggest that people may not understand = exactly what this
> reasoning is and
> > that the persons who believe in this = excuse not to do
> piggybacking detail,
> > with a precise and hopefully concise = example, the exact
> scenario they are
> > thinking of. They need to answer the = question of "why do
> you need a BSA to
> > use piggybacking?".
> >
> > I have also seen euphemisms such as = "this makes me sick",
> etc.. referenced
> > by IPv6 WG members to whom it is well = known that they do
> not see value in
> > MIP anyway much less RO'd MIP. While this = could also be
> seen as constructive
> > criticism, I believe or rather hope, that = the persons on
> this mail list do
> > see value in it and the "sick" = reference refers to the
> persons inability to
> > see value in MIP itself, let alone the = piggybacking and
> Route Optimization.
> > The fact that the security PDU portions of = a binding are no longer
> > associated with IPSEC, allows piggybacking = to work and
> makes the technical
> > portion of the arguments against = piggybacking false.
> >
> > So it seems to me that there is no true = technical excuse
> for not allowing
> > piggybacking and I can only infer = logically that some deal
> making has been
> > done in order to progress the standard on = some sort of
> deadline self-imposed
> > by some conflicting external SDOs. This = prompted my initial
> criticism in
> > that I wanted to remind people that this = is the IETF and we
> are supposed to
> > deal with the IP problem space - not the = least common
> denominator link
> > layer.
> >
> > I hope you see this as constructive and = not a bantor.
>
> Glenn,
> was the above sentence a question to me and = Charlie (the "to" list) or
> to all of the WG?
>
> I don't see the constructive propopsal you are = making for how
> to move forward.
> Could you clarify what it is?
>
>   Erik
>
>

------_=_NextPart_001_01C1B897.E7BB9F90-- From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 12:35:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10257 for ; Mon, 18 Feb 2002 12:35:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00911; Mon, 18 Feb 2002 10:35:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29862; Mon, 18 Feb 2002 09:35:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IHYIKL018168 for ; Mon, 18 Feb 2002 09:34:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IHYI8K018167 for mobile-ip-dist; Mon, 18 Feb 2002 09:34:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IHYDKL018157 for ; Mon, 18 Feb 2002 09:34:13 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IHYAx02388; Mon, 18 Feb 2002 18:34:11 +0100 (MET) Date: Mon, 18 Feb 2002 18:23:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C6DBA06.D416F143@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I would like to second this simple compromise. It would > solve the IPsec issue short term with no change requirement > to protocol specs other than possibly an implementation > note to MIPv6. > > Once a policy rule is inserted for BUs, don't piggyback. > Existence of the rule can, e.g., be a per-HoA BCE > flag set when inserting the IPsec policy. It is then known > to the part of code deciding on piggybacking. This is one > of the simplest way, other ways exist, too. > > BUs have a new extension header number to solve the > orthogonal-to-piggybacking problem of distinguishing > from non-MIPv6 DstHdr traffic. Jari, A clarifying question. Are you assuming that the BU packets will use a new extension header type (so that IPsec policies can tell them apart from other packets) and that new extension header has the ability to also carry another packet payload (such as a TCP packet)? Erik > There seem to be two threads on piggybacking, IPsec and L2. > I see above some first signs of progress towards a compromise > in the former. To me this is a new development compared to > discussions last fall. > > BR, > > -Jari M. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 12:35:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10269 for ; Mon, 18 Feb 2002 12:35:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17729; Mon, 18 Feb 2002 10:35:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29887; Mon, 18 Feb 2002 09:35:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IHYDKL018159 for ; Mon, 18 Feb 2002 09:34:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IHYDKD018158 for mobile-ip-dist; Mon, 18 Feb 2002 09:34:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IHY9KL018147 for ; Mon, 18 Feb 2002 09:34:09 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IHXxx02382; Mon, 18 Feb 2002 18:34:00 +0100 (MET) Date: Mon, 18 Feb 2002 18:19:53 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Home Address Option: design team recommendation To: Charlie Perkins Cc: Erik Nordmark , Mobile IP Working Group In-Reply-To: "Your message with ID" <3C7123C1.634EEDE9@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Yes, I do. I do not want to discuss that on this mailing list. Why not? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 12:35:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10287 for ; Mon, 18 Feb 2002 12:35:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21005; Mon, 18 Feb 2002 10:35:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29952; Mon, 18 Feb 2002 09:35:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IHYAKL018149 for ; Mon, 18 Feb 2002 09:34:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IHYAW2018148 for mobile-ip-dist; Mon, 18 Feb 2002 09:34:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IHY5KL018140 for ; Mon, 18 Feb 2002 09:34:06 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IHXpx02378; Mon, 18 Feb 2002 18:33:52 +0100 (MET) Date: Mon, 18 Feb 2002 18:07:52 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: charliep@iprg.nokia.com Cc: Pekka Nikander , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C6D4858.8747AEEB@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > To the zeroth level, I would be satisfied with a solution that only > works for connected sockets. I do not think it would be wise at > this point to require changes to user programs. However, I would > have to go back and try to see what common UDP applications > do with their sockets. What about DNS? Charlie, Most UDP applications do not use connected sockets, and all of the server ends (as opposed to client end) of UDP applications needs to have a non-connected socket in order to accept UDP packets from any sender. DNS is no exception - a DNS server has a non-connected UDP socket receiving packets from anybody. A DNS client/resolver might use connected UDP sockets in some cases - I think the BIND source code has some support for this. So what would it mean to have a solution that only works for connected sockets? Would a UDP packet with an unverified HoA sent to a non-connected UDP socket be silently dropped? Cause an error to be returned? Something else? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 13:07:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11886 for ; Mon, 18 Feb 2002 13:07:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09004; Mon, 18 Feb 2002 11:07:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23401; Mon, 18 Feb 2002 10:07:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1II6pKL018423 for ; Mon, 18 Feb 2002 10:06:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1II6pCF018422 for mobile-ip-dist; Mon, 18 Feb 2002 10:06:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1II6mKL018415 for ; Mon, 18 Feb 2002 10:06:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23263 for ; Mon, 18 Feb 2002 10:06:51 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25758 for ; Mon, 18 Feb 2002 11:06:50 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04416 for ; Mon, 18 Feb 2002 10:06:50 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1II6n907668 for ; Mon, 18 Feb 2002 10:06:49 -0800 X-mProtect:  Mon, 18 Feb 2002 10:06:49 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdJbU7H7; Mon, 18 Feb 2002 10:06:30 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA94630 for ; Mon, 18 Feb 2002 10:06:30 -0800 (PST) Message-ID: <3C7142A6.5E14C726@iprg.nokia.com> Date: Mon, 18 Feb 2002 10:06:30 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > Jari, > > A clarifying question. > Are you assuming that the BU packets will use a new extension > header type (so that IPsec policies can tell them apart from other packets) > and that new extension header has the ability to also carry another > packet payload (such as a TCP packet)? Yes. But with the strict restriction that use of such extension header with a subsequent (e.g. final) header could happen only if sender of BU/BAck/BR does not use IPsec for protecting mobility signaling, i.e., there is no policy for that. In all other cases this new protocol would be the final one available as a selector component. In the future, when selectors get extended to support extensions with subsequent packet, minimal or no protocol change would be needed, only relaxation of the above rule. At least this is how I understood James's compromise could be applied. > Erik BR, -Jari M From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 13:42:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13100 for ; Mon, 18 Feb 2002 13:42:41 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18112; Mon, 18 Feb 2002 11:42:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00513; Mon, 18 Feb 2002 10:42:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IIfdKL018749 for ; Mon, 18 Feb 2002 10:41:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IIfcdL018748 for mobile-ip-dist; Mon, 18 Feb 2002 10:41:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IIfZKL018741 for ; Mon, 18 Feb 2002 10:41:35 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12516 for ; Mon, 18 Feb 2002 10:41:37 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07309 for ; Mon, 18 Feb 2002 11:41:36 -0700 (MST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1IIfZt23117 for ; Mon, 18 Feb 2002 10:41:36 -0800 (PST) Received: from oranlt ([161.44.238.48]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACB37711; Mon, 18 Feb 2002 10:41:45 -0800 (PST) From: "David R. Oran" To: Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Mon, 18 Feb 2002 13:41:26 -0500 Organization: Cisco Systems Message-ID: <00a301c1b8ab$e001d760$30ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C7142A6.5E14C726@iprg.nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please excuse this message from left field. I've been reading all the email of people talking past each other, and looked at some of the quantitative results posted on the benefits of piggybacking. It seems to me that you can have all the benefits, with none of the tricky tradeoffs with security and processing semantics of piggybacked BUs if instead of doing intra-packet piggybacking, we simply defined a simple way to put two or more IP packets into one L2 frame, and hence one radio frame transmission. My reading of why piggybacking wins is because you avoid re-arbitrating and re-scheduling the radio channel, not because one packet is all that much smaller than two (with header compression and the two packets going between the same pair of addresses, the two-packet header scheme might be even shorter)! The blocking approach is clearly MUCH more general, and even allows the blocked packets to go to different places. I think it can be done without even having an extra encapsulation header, as long as the L2 explicitly signals frame length to the IP layer, and there is a way to let the peer know you are doing this at link establishment time. The only downside I can think of is if there is a requirement that the two packets be received and processed together (i.e. they have semantic or timing interdependencies). In some cases, at least in theory, I can see that, but is this true for Binding Updates? I don't think so (but am happy to be corrected). Sorry for the interruption. Back to your regularly scheduled broadcast. Dave. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 13:56:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13600 for ; Mon, 18 Feb 2002 13:56:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21885; Mon, 18 Feb 2002 11:56:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02411; Mon, 18 Feb 2002 10:56:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IItKKL018816 for ; Mon, 18 Feb 2002 10:55:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IItKub018815 for mobile-ip-dist; Mon, 18 Feb 2002 10:55:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IItFKL018808 for ; Mon, 18 Feb 2002 10:55:16 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1IItCx08710; Mon, 18 Feb 2002 19:55:13 +0100 (MET) Date: Mon, 18 Feb 2002 19:50:46 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7142A6.5E14C726@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Yes. But with the strict restriction that use of such > extension header with a subsequent (e.g. final) header > could happen only if sender of BU/BAck/BR does not use > IPsec for protecting mobility signaling, i.e., there is > no policy for that. In all other cases this new protocol > would be the final one available as a selector component. Presumably both the B* part and the piggybacked payload should be sent in the clear according to IPsec policy in order for the piggybacking to be applied. I think such an approach would solve the IPsec interaction issues related to piggybacking. The other main arguments against piggybacking seems to be 1. complexity in all the receivers in order to process piggybacked packets. 2. Issues where the receiver of the piggybacked packets might not want piggybacking e.g. due to channel or QoS concerns on the last few hops towards the receiver. I think #1 can be handled by being able to describe the processing of the piggybacked packet on the receiver succinctly. The simplest seems to be that a packet containing IPv6 header [+ extension headers] + B* header + piggybacked payload be effectively fed back into ip_input() as IPv6 header [+ extension headers] + piggybacked payload after the B* part of the packet have been processed. I don't know if there are any difficult details with such an approach. But I don't have a good idea how to address #2 short of piggybacking being negotiable. I do observe that when using RR to secure the BU the 2a/2b packets sent from the CN to the MN could contain a "piggybacking ok/notok" flag. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 14:42:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15363 for ; Mon, 18 Feb 2002 14:42:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21419; Mon, 18 Feb 2002 12:42:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23088; Mon, 18 Feb 2002 11:42:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IJfhKL018946 for ; Mon, 18 Feb 2002 11:41:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1IJfh8w018945 for mobile-ip-dist; Mon, 18 Feb 2002 11:41:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1IJfeKL018938 for ; Mon, 18 Feb 2002 11:41:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09761 for ; Mon, 18 Feb 2002 11:41:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18792 for ; Mon, 18 Feb 2002 12:41:41 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA11162 for ; Mon, 18 Feb 2002 11:41:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1IJfdU27953 for ; Mon, 18 Feb 2002 11:41:39 -0800 X-mProtect:  Mon, 18 Feb 2002 11:41:39 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZNcFvg; Mon, 18 Feb 2002 11:41:38 PST Message-ID: <3C7158F2.29D54300@iprg.nokia.com> Date: Mon, 18 Feb 2002 11:41:38 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Erik, comment on the issue #2. (snipped all other text) Erik Nordmark wrote: > 2. Issues where the receiver of the piggybacked packets might not want > piggybacking e.g. due to channel or QoS concerns on the last few hops > towards the receiver. > > But I don't have a good idea how to address #2 short of piggybacking > being negotiable. > I do observe that when using RR to secure the BU the 2a/2b packets sent from > the CN to the MN could contain a "piggybacking ok/notok" flag. Piggybacking could be described generically as putting an extension header (routing header, destination options) onto a payload. I am not sure what you mean by 'channel or QoS concerns'. I can read it two ways. a) The piggybacked packet could exceed the maximum MTU on the last few hops towards the receiver. b) The receiver has negotiated a very tight channel in which it is allowed only a fixed number of bytes per packet/second. and the piggybacked packet results in exceeding the allocated resouces. For a), it sounds like a Path MTU issue. Basically you assume the sender does not know a valid Path MTU, otherwise it wouldn't have piggybacked. There I would say any link should adhere to IPv6 minimum recommendation. For b), it seems like a special case of a) where QoS negotiation has established a limit for packet size. In principle, if sender knows this limit by means of Path MTU, it would not piggyback here either. I would see these, especially b), to be more generic IPv6 issues. This concerns all variable-length traffic over such channels or QoS negotiated last hop(s). Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 16:42:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19590 for ; Mon, 18 Feb 2002 16:42:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18205; Mon, 18 Feb 2002 14:42:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00617; Mon, 18 Feb 2002 13:42:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ILfOKL019138 for ; Mon, 18 Feb 2002 13:41:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1ILfOe8019137 for mobile-ip-dist; Mon, 18 Feb 2002 13:41:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1ILfLKL019130 for ; Mon, 18 Feb 2002 13:41:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19356 for ; Mon, 18 Feb 2002 13:41:24 -0800 (PST) Received: from prserv.net (out2.prserv.net [32.97.166.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11399 for ; Mon, 18 Feb 2002 14:41:23 -0700 (MST) Received: from attglobal.net (slip-12-64-0-74.mis.prserv.net[12.64.0.74]) by prserv.net (out2) with SMTP id <2002021821412220204slajre>; Mon, 18 Feb 2002 21:41:22 +0000 Message-ID: <3C717501.7874707F@attglobal.net> Date: Mon, 18 Feb 2002 15:41:21 -0600 From: Sebastian Thalanany X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: gdommety@cisco.com Subject: Re: [mobile-ip] Length field definitions - rfc3115 References: <3C6FE255.C2FA49C3@attglobal.net> <3C6FEB76.650DEF8E@cisco.com> <3C7013C8.95CF05D1@attglobal.net> <3C709D67.C14840A7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Kent, Thanks for the confirmation. Regards, Sebastian kleung wrote: > Sebastian Thalanany wrote: > > > Hello Kent, > > Since rfc3115 is based on rfc2002, which was > > obsoleted last month by rfc3220, it would perhaps be preferrable to > > update rfc3115 with the general format specification for a skippable > > extension(NVSE) as specified in rfc3220. If the intent of the > > "Reserved" field is to extend the Type field, as indicated in section > > 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the > > following definitions for a CVSE element and an NVSE element may avoid > > ambiguities in interpretation: > > > > 1. CVSE > > Length Length in bytes of the Value(data) field > > within > > this extension. It does NOT include the bytes associated with the > > Type, Length and the Reserved fields. > > > > > > 2. NVSE > > Length Length in bytes of the Value(data) field within > > this extension. It does NOT include the bytes associated with the > > Type, Length and the Reserved fields. > > > > Not this. > > > > > or > > > > Length Length in bytes of the Value(data) field within > > this extension. It does NOT include the bytes associated with the > > Type, Length fields. The Length field MUST be set to 2 plus the length > > > > of the Value(data) field, where the additional two octets are required > > > > to include the length of the Reserved field. > > > > This one. Length is always what follows that field in the > extension. This is consistent with 1.9, 1.10 and 1.11. > > Thanks. > > Kent > > > > > For the NVSE, please confirm one of the two proposed > > definitions. > > > > Thanks. > > > > Regards, > > Sebastian From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 18 18:55:51 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23926 for ; Mon, 18 Feb 2002 18:55:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03324; Mon, 18 Feb 2002 15:55:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08113; Mon, 18 Feb 2002 15:55:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1INsWKL019272 for ; Mon, 18 Feb 2002 15:54:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1INsWNV019271 for mobile-ip-dist; Mon, 18 Feb 2002 15:54:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1INsSKL019264 for ; Mon, 18 Feb 2002 15:54:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02345 for ; Mon, 18 Feb 2002 15:54:31 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14798 for ; Mon, 18 Feb 2002 16:54:30 -0700 (MST) Received: from T23KEMPF (dhcp142.docomolabs-usa.com [172.21.96.142]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1INsSe03206 for ; Mon, 18 Feb 2002 15:54:28 -0800 (PST) Message-ID: <001001c1b8d7$6167da40$8e6015ac@T23KEMPF> From: "James Kempf" To: References: <00a301c1b8ab$e001d760$30ee2ca1@cisco.com> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Mon, 18 Feb 2002 15:52:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Dave, > It seems to me that you can have all the benefits, with none of the > tricky tradeoffs with security and processing semantics of piggybacked > BUs if instead of doing intra-packet piggybacking, we simply defined a > simple way to put two or more IP packets into one L2 frame, and hence > one radio frame transmission. > I think what you mean is two or more IP packets per scheduled packet transmission slot. Radio L2 frame sizes vary, of course, but on most cellular systems they are on the order of 40 bytes. This would be just enough to carry one uncompressed IPv6 header with no header options. > My reading of why piggybacking wins is because you avoid re-arbitrating > and re-scheduling the radio channel, not because one packet is all that > much smaller than two (with header compression and the two packets going > between the same pair of addresses, the two-packet header scheme might > be even shorter)! > Don't know about the last point, but I agree that being able to schedule more than one packet per packet transmission slot could potentially have the same effect as piggybacking. The problem is that this falls into the same category as Hesham's suggestion that IP signaling be done over a separate signaling channel. I don't believe it works that way today. One argument people have expressed for getting rid of piggybacking is: "It interferes with IPSec and Jeff Schiller has indicated that we should not expect IPSec to change to accommodate Mobile IP in the near future (or possibly ever?, that wasn't clear)." If changing IPSec in the near future is hard, then I'd venture to guess that changing the 3GPP or 3GPP2 MAC layers is probably nigh on impossible. But certainly 3GPP and 3GPP2 are not the last cellular radio protocols that will ever get designed and if we can ever get together a comprehensive set of recommendations to L2 designers about what makes a good radio L2 for IP, this would be high among the recommendations. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 02:05:38 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10277 for ; Tue, 19 Feb 2002 02:05:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA09266; Mon, 18 Feb 2002 23:05:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29966; Mon, 18 Feb 2002 23:05:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1J74WKL019676 for ; Mon, 18 Feb 2002 23:04:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1J74WHI019675 for mobile-ip-dist; Mon, 18 Feb 2002 23:04:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1J74SKL019668 for ; Mon, 18 Feb 2002 23:04:28 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29817 for ; Mon, 18 Feb 2002 23:04:19 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03611 for ; Mon, 18 Feb 2002 23:04:17 -0800 (PST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020219070416.RNSJ24910.fep01-app.kolumbus.fi@jariws1>; Tue, 19 Feb 2002 09:04:16 +0200 Message-ID: <01fe01c1b913$a9fe0a40$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "James Kempf" , References: <00a301c1b8ab$e001d760$30ee2ca1@cisco.com> <001001c1b8d7$6167da40$8e6015ac@T23KEMPF> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 19 Feb 2002 09:04:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I think what you mean is two or more IP packets per scheduled packet > transmission slot. Radio L2 frame sizes vary, of course, but on most > cellular > systems they are on the order of 40 bytes. This would be just enough to > carry one uncompressed IPv6 header with no header options. Particularly with v6, there *has* to be header compression. I wonder how many voice packets you could fit on 40 bytes with compression... As far as changing 3GPP or 3GPP2 goes I too think it's hard but maybe not *so* hard. There's for instance examples on how fast those folks have adopted header compression when they have seen the benefits. Come to think of it, maybe I should I ask my compression colleagues if they have thought of putting multiple packets on a single frame... Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 02:56:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12040 for ; Tue, 19 Feb 2002 02:56:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26680; Tue, 19 Feb 2002 00:56:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18160; Mon, 18 Feb 2002 23:56:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1J7tjKL019760 for ; Mon, 18 Feb 2002 23:55:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1J7tiCO019759 for mobile-ip-dist; Mon, 18 Feb 2002 23:55:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1J7tfKL019752 for ; Mon, 18 Feb 2002 23:55:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18024 for ; Mon, 18 Feb 2002 23:55:42 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA07302 for ; Tue, 19 Feb 2002 00:55:42 -0700 (MST) Received: from pyegani-w2k2.cisco.com (rtp-vpn1-273.cisco.com [10.82.225.17]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id XAA13142; Mon, 18 Feb 2002 23:55:40 -0800 (PST) Message-Id: <4.3.2.7.2.20020218231309.00b92ed0@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Feb 2002 23:56:49 -0800 To: mobile-ip@sunroof.eng.sun.com, "James Kempf" From: Parviz Yegani Subject: Re: [mobile-ip] Piggybacking - DT recommendation Cc: pyegani@cisco.com In-Reply-To: <01fe01c1b913$a9fe0a40$8a1b6e0a@arenanet.fi> References: <00a301c1b8ab$e001d760$30ee2ca1@cisco.com> <001001c1b8d7$6167da40$8e6015ac@T23KEMPF> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jari/Jim, Comments inline... At 09:04 AM 2/19/2002 +0200, Jari Arkko wrote: > > I think what you mean is two or more IP packets per scheduled packet > > transmission slot. Radio L2 frame sizes vary, of course, but on most > > cellular > > systems they are on the order of 40 bytes. This would be just enough to > > carry one uncompressed IPv6 header with no header options. > >Particularly with v6, there *has* to be header compression. I wonder >how many voice packets you could fit on 40 bytes with compression... >As far as changing 3GPP or 3GPP2 goes I too think it's hard but maybe >not *so* hard. There's for instance examples on how fast those folks have >adopted header compression when they have seen the benefits. Come >to think of it, maybe I should I ask my compression colleagues if they >have thought of putting multiple packets on a single frame... In cellular, you don't want to send any header bytes over the air. It would eat up capacity. For example, for a data rate of 14.4 Kbps a 4-byte header would cost you slightly more than 11% of radio link capacity. So, the penalty is BIG!! To avoid this situation you are forced to remove RTP/UDP/IP headers (total of 40 bytes) all together when you send packets over the air. This can be accomplished by using 0-byte header compression schemes. In 3GPP2, for example, there are two 0-byte header compression options: Header Stripping and Generation or HSG (based on GEHCO) and LLA-ROHC which recently reached an RFC status. HSG is already been adopted and LLA-ROHC in under consideration. For both of these schemes you need to send update packets (eg, full header packets) once a while when the transmitter and receiver go out of sync. Once both ends are in sync then you can send IP packets over the air with no additional overhead. In this case, the number of packets that can fit in a single L2 radio frame depends only on the packet size. For short packets (less than 20 bytes) you can pack multiple packets in a single L2 radio frame. -Parviz >Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 12:32:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28473 for ; Tue, 19 Feb 2002 12:32:13 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16569; Tue, 19 Feb 2002 10:32:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05728; Tue, 19 Feb 2002 09:31:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JHUjKL020762 for ; Tue, 19 Feb 2002 09:30:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JHUj8a020761 for mobile-ip-dist; Tue, 19 Feb 2002 09:30:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JHUgKL020754 for ; Tue, 19 Feb 2002 09:30:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03678 for ; Tue, 19 Feb 2002 09:30:44 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15699 for ; Tue, 19 Feb 2002 10:30:43 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JHUfO20699 for ; Tue, 19 Feb 2002 11:30:42 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H228ZN>; Tue, 19 Feb 2002 11:30:42 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0221F0D7@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 19 Feb 2002 11:30:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B96B.264FFCA0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B96B.264FFCA0 Content-Type: text/plain; charset="iso-8859-1" From a cellular perspective I only see a few tenable solutions: One way would be to RF temporarily pump up the volume a bit in order to send a little bit more information in a smaller amount of time; however, I suspect many will say it is better to keep the volume at the same level for a longer time. They may also say we don't want to change the MAC/LAC layer to do this? Another method would be to use ROHC or their LMM device to separate the PDUs and send the BU over another variable bearer on the reverse path to the receiving mobile. The way the MIPv6 signaling and IPv6 (no checksum) are defined it can be separated. In both cases on the forward path a mobile would likely not piggyback when connected to these cellular links. But again these are access specific solutions and issues. So the point is that there are work-arounds for this that can be done in the access SDOs. Thanks, Glenn > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, February 18, 2002 5:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > Hi Dave, > > > It seems to me that you can have all the benefits, with none of the > > tricky tradeoffs with security and processing semantics of > piggybacked > > BUs if instead of doing intra-packet piggybacking, we > simply defined a > > simple way to put two or more IP packets into one L2 frame, > and hence > > one radio frame transmission. > > > > I think what you mean is two or more IP packets per scheduled packet > transmission slot. Radio L2 frame sizes vary, of course, but on most > cellular > systems they are on the order of 40 bytes. This would be just > enough to > carry one uncompressed IPv6 header with no header options. > > > My reading of why piggybacking wins is because you avoid > re-arbitrating > > and re-scheduling the radio channel, not because one packet is all > that > > much smaller than two (with header compression and the two packets > going > > between the same pair of addresses, the two-packet header > scheme might > > be even shorter)! > > > > Don't know about the last point, but I agree that being able > to schedule > more than one packet per packet transmission slot could > potentially have > the same effect as piggybacking. > > The problem is that this falls into the same category as Hesham's > suggestion that IP signaling be done over a separate > signaling channel. > I don't believe it works that way today. One argument people have > expressed for > getting rid of piggybacking is: "It interferes with IPSec and Jeff > Schiller > has indicated that we should not expect IPSec to change to accommodate > Mobile IP in the near future (or possibly ever?, that wasn't > clear)." If > changing IPSec in the near future is hard, then I'd venture to guess > that > changing the 3GPP or 3GPP2 MAC layers is probably nigh on impossible. > > But certainly 3GPP and 3GPP2 are not the last cellular radio protocols > that will ever get designed and if we can ever get together a > comprehensive > set of recommendations to L2 designers about what makes a good radio > L2 for IP, this would be high among the recommendations. > > jak > > > > ------_=_NextPart_001_01C1B96B.264FFCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Piggybacking - DT recommendation

From a cellular perspective I only see a few tenable = solutions:

One way would be to RF temporarily pump up the volume = a bit in order to send a little bit more information in a smaller = amount of time; however, I suspect many will say it is better to keep = the volume at the same level for a longer time. They may also say we = don't want to change the MAC/LAC layer to do this?


Another method would be to use ROHC or their LMM = device to separate the PDUs and send the BU over another variable = bearer on the reverse path to the receiving  mobile. The way the = MIPv6 signaling and IPv6 (no checksum) are defined it can be = separated.

In both cases on the forward path a mobile would = likely not piggyback when connected to these cellular links.  =


But again these are access specific solutions and = issues. So the point is that there are work-arounds for this that can = be done in the access SDOs.

Thanks,

Glenn

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com= ]
> Sent: Monday, February 18, 2002 5:53 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Piggybacking - DT = recommendation
>
>
> Hi Dave,
>
> > It seems to me that you can have all the = benefits, with none of the
> > tricky tradeoffs with security and = processing semantics of
> piggybacked
> > BUs if instead of doing intra-packet = piggybacking, we
> simply defined a
> > simple way to put two or more IP packets = into one L2 frame,
> and hence
> > one radio frame transmission.
> >
>
> I think what you mean is two or more IP packets = per scheduled packet
> transmission slot. Radio L2 frame sizes vary, = of course, but on most
> cellular
> systems they are on the order of 40 bytes. This = would be just
> enough to
> carry one uncompressed IPv6 header with no = header options.
>
> > My reading of why piggybacking wins is = because you avoid
> re-arbitrating
> > and re-scheduling the radio channel, not = because one packet is all
> that
> > much smaller than two (with header = compression and the two packets
> going
> > between the same pair of addresses, the = two-packet header
> scheme might
> > be even shorter)!
> >
>
> Don't know about the last point, but I agree = that being able
> to schedule
> more than one packet per packet transmission = slot could
> potentially have
> the same effect as piggybacking.
>
> The problem is that this falls into the same = category as Hesham's
> suggestion that IP signaling be done over a = separate
> signaling channel.
> I don't believe it works that way today. One = argument people have
> expressed for
> getting rid of piggybacking is: "It = interferes with IPSec and Jeff
> Schiller
> has indicated that we should not expect IPSec = to change to accommodate
> Mobile IP in the near future (or possibly = ever?, that wasn't
> clear)." If
> changing IPSec in the near future is hard, then = I'd venture to guess
> that
> changing the 3GPP or 3GPP2 MAC layers is = probably nigh on impossible.
>
> But certainly 3GPP and 3GPP2 are not the last = cellular radio protocols
> that will ever get designed and if we can ever = get together a
> comprehensive
> set of recommendations to L2 designers about = what makes a good radio
> L2 for IP, this would be high among the = recommendations.
>
>          = ;   jak
>
>
>
>

------_=_NextPart_001_01C1B96B.264FFCA0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 13:15:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00045 for ; Tue, 19 Feb 2002 13:15:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10119; Tue, 19 Feb 2002 11:15:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22326; Tue, 19 Feb 2002 10:15:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JIDxKL020884 for ; Tue, 19 Feb 2002 10:13:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JIDxPW020883 for mobile-ip-dist; Tue, 19 Feb 2002 10:13:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JIDuKL020876 for ; Tue, 19 Feb 2002 10:13:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17215 for ; Tue, 19 Feb 2002 10:13:59 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11730 for ; Tue, 19 Feb 2002 11:13:58 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JIDuO14557 for ; Tue, 19 Feb 2002 12:13:57 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H229YT>; Tue, 19 Feb 2002 12:13:57 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02278088@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 19 Feb 2002 12:13:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B971.31D10730" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B971.31D10730 Content-Type: text/plain; charset="iso-8859-1" I also need to mention that this is only an issue for these optimized voice bearers. For instance non voice traffic doesn't really have this problem because they use more flexible variable bearers. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Tuesday, February 19, 2002 11:31 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation From a cellular perspective I only see a few tenable solutions: One way would be to RF temporarily pump up the volume a bit in order to send a little bit more information in a smaller amount of time; however, I suspect many will say it is better to keep the volume at the same level for a longer time. They may also say we don't want to change the MAC/LAC layer to do this? Another method would be to use ROHC or their LMM device to separate the PDUs and send the BU over another variable bearer on the reverse path to the receiving mobile. The way the MIPv6 signaling and IPv6 (no checksum) are defined it can be separated. In both cases on the forward path a mobile would likely not piggyback when connected to these cellular links. But again these are access specific solutions and issues. So the point is that there are work-arounds for this that can be done in the access SDOs. Thanks, Glenn > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: Monday, February 18, 2002 5:53 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > Hi Dave, > > > It seems to me that you can have all the benefits, with none of the > > tricky tradeoffs with security and processing semantics of > piggybacked > > BUs if instead of doing intra-packet piggybacking, we > simply defined a > > simple way to put two or more IP packets into one L2 frame, > and hence > > one radio frame transmission. > > > > I think what you mean is two or more IP packets per scheduled packet > transmission slot. Radio L2 frame sizes vary, of course, but on most > cellular > systems they are on the order of 40 bytes. This would be just > enough to > carry one uncompressed IPv6 header with no header options. > > > My reading of why piggybacking wins is because you avoid > re-arbitrating > > and re-scheduling the radio channel, not because one packet is all > that > > much smaller than two (with header compression and the two packets > going > > between the same pair of addresses, the two-packet header > scheme might > > be even shorter)! > > > > Don't know about the last point, but I agree that being able > to schedule > more than one packet per packet transmission slot could > potentially have > the same effect as piggybacking. > > The problem is that this falls into the same category as Hesham's > suggestion that IP signaling be done over a separate > signaling channel. > I don't believe it works that way today. One argument people have > expressed for > getting rid of piggybacking is: "It interferes with IPSec and Jeff > Schiller > has indicated that we should not expect IPSec to change to accommodate > Mobile IP in the near future (or possibly ever?, that wasn't > clear)." If > changing IPSec in the near future is hard, then I'd venture to guess > that > changing the 3GPP or 3GPP2 MAC layers is probably nigh on impossible. > > But certainly 3GPP and 3GPP2 are not the last cellular radio protocols > that will ever get designed and if we can ever get together a > comprehensive > set of recommendations to L2 designers about what makes a good radio > L2 for IP, this would be high among the recommendations. > > jak > > > > ------_=_NextPart_001_01C1B971.31D10730 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Piggybacking - DT recommendation
I also need to mention that this is only an issue for these optimized voice bearers. For instance non voice traffic doesn't really have this problem because they use more flexible variable bearers.
-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Tuesday, February 19, 2002 11:31 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Piggybacking - DT recommendation

From a cellular perspective I only see a few tenable solutions:

One way would be to RF temporarily pump up the volume a bit in order to send a little bit more information in a smaller amount of time; however, I suspect many will say it is better to keep the volume at the same level for a longer time. They may also say we don't want to change the MAC/LAC layer to do this?


Another method would be to use ROHC or their LMM device to separate the PDUs and send the BU over another variable bearer on the reverse path to the receiving  mobile. The way the MIPv6 signaling and IPv6 (no checksum) are defined it can be separated.

In both cases on the forward path a mobile would likely not piggyback when connected to these cellular links. 


But again these are access specific solutions and issues. So the point is that there are work-arounds for this that can be done in the access SDOs.

Thanks,

Glenn

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Monday, February 18, 2002 5:53 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Piggybacking - DT recommendation
>
>
> Hi Dave,
>
> > It seems to me that you can have all the benefits, with none of the
> > tricky tradeoffs with security and processing semantics of
> piggybacked
> > BUs if instead of doing intra-packet piggybacking, we
> simply defined a
> > simple way to put two or more IP packets into one L2 frame,
> and hence
> > one radio frame transmission.
> >
>
> I think what you mean is two or more IP packets per scheduled packet
> transmission slot. Radio L2 frame sizes vary, of course, but on most
> cellular
> systems they are on the order of 40 bytes. This would be just
> enough to
> carry one uncompressed IPv6 header with no header options.
>
> > My reading of why piggybacking wins is because you avoid
> re-arbitrating
> > and re-scheduling the radio channel, not because one packet is all
> that
> > much smaller than two (with header compression and the two packets
> going
> > between the same pair of addresses, the two-packet header
> scheme might
> > be even shorter)!
> >
>
> Don't know about the last point, but I agree that being able
> to schedule
> more than one packet per packet transmission slot could
> potentially have
> the same effect as piggybacking.
>
> The problem is that this falls into the same category as Hesham's
> suggestion that IP signaling be done over a separate
> signaling channel.
> I don't believe it works that way today. One argument people have
> expressed for
> getting rid of piggybacking is: "It interferes with IPSec and Jeff
> Schiller
> has indicated that we should not expect IPSec to change to accommodate
> Mobile IP in the near future (or possibly ever?, that wasn't
> clear)." If
> changing IPSec in the near future is hard, then I'd venture to guess
> that
> changing the 3GPP or 3GPP2 MAC layers is probably nigh on impossible.
>
> But certainly 3GPP and 3GPP2 are not the last cellular radio protocols
> that will ever get designed and if we can ever get together a
> comprehensive
> set of recommendations to L2 designers about what makes a good radio
> L2 for IP, this would be high among the recommendations.
>
>             jak
>
>
>
>

------_=_NextPart_001_01C1B971.31D10730-- From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 16:34:20 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06205 for ; Tue, 19 Feb 2002 16:34:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20308; Tue, 19 Feb 2002 14:34:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15494; Tue, 19 Feb 2002 13:33:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JLWRKL021256 for ; Tue, 19 Feb 2002 13:32:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JLWQbc021255 for mobile-ip-dist; Tue, 19 Feb 2002 13:32:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JLWNKL021248 for ; Tue, 19 Feb 2002 13:32:23 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00543; Tue, 19 Feb 2002 13:32:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20668; Tue, 19 Feb 2002 13:32:26 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA24101; Tue, 19 Feb 2002 13:32:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1JLWPk09759; Tue, 19 Feb 2002 13:32:25 -0800 X-mProtect:  Tue, 19 Feb 2002 13:32:25 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin33.iprg.nokia.com (205.226.20.227, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4aclXk; Tue, 19 Feb 2002 13:32:23 PST Message-ID: <3C72C407.B99C5A9E@iprg.nokia.com> Date: Tue, 19 Feb 2002 13:30:47 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I'll try to write more later. But, I think that the two arguments as summarized in your note do not stand up to analysis: > The other main arguments against piggybacking seems to be > 1. complexity in all the receivers in order to process piggybacked packets. The receivers are already supposed to implement everything that is needed for this, just because of the way that IPv6 headers are supposed to be processed. Thus, this is no impediment, as you point out later in your note. > > 2. Issues where the receiver of the piggybacked packets might not want > piggybacking e.g. due to channel or QoS concerns on the last few hops > towards the receiver. QoS concerns should always be resolved by QoS negotiations. Furthermore, channel reservations such as are envisioned by those who are not in favor of piggybacking, should properly resolve issues about assignations of microflows to various bearer channels, and this would typically trigger the right kind of processing to send Binding Updates correctly. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 17:21:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06894 for ; Tue, 19 Feb 2002 17:21:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11027; Tue, 19 Feb 2002 15:21:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27537; Tue, 19 Feb 2002 14:20:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JMJtKL021423 for ; Tue, 19 Feb 2002 14:19:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JMJsE5021422 for mobile-ip-dist; Tue, 19 Feb 2002 14:19:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JMJpKL021415 for ; Tue, 19 Feb 2002 14:19:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16708 for ; Tue, 19 Feb 2002 14:19:53 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24426 for ; Tue, 19 Feb 2002 14:19:52 -0800 (PST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id <1L6R3LH3>; Tue, 19 Feb 2002 17:13:21 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" , James Kempf Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 19 Feb 2002 17:13:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I *think* we're getting into enough info about specific L2s to confuse the issues, but not enough info to clarify them. There are layers of framing, for example.... So, could we avoid this bit of rathole, or is it essential for the discussion? > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Tuesday, February 19, 2002 2:04 AM > To: James Kempf; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > > I think what you mean is two or more IP packets per > scheduled packet > > transmission slot. Radio L2 frame sizes vary, of course, > but on most > > cellular systems they are on the order of 40 bytes. This > would be just > > enough to carry one uncompressed IPv6 header with no header options. > > Particularly with v6, there *has* to be header compression. I > wonder how many voice packets you could fit on 40 bytes with > compression... As far as changing 3GPP or 3GPP2 goes I too > think it's hard but maybe not *so* hard. There's for instance > examples on how fast those folks have adopted header > compression when they have seen the benefits. Come to think > of it, maybe I should I ask my compression colleagues if they > have thought of putting multiple packets on a single frame... > > Jari > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 17:31:33 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07311 for ; Tue, 19 Feb 2002 17:31:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19935; Tue, 19 Feb 2002 14:31:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00221; Tue, 19 Feb 2002 14:31:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JMTxKL021475 for ; Tue, 19 Feb 2002 14:29:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JMTxIu021474 for mobile-ip-dist; Tue, 19 Feb 2002 14:29:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JMTtKL021467 for ; Tue, 19 Feb 2002 14:29:55 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1JMTox07326; Tue, 19 Feb 2002 23:29:50 +0100 (MET) Date: Tue, 19 Feb 2002 23:25:21 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: vijayd@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7158F2.29D54300@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I am not sure what you mean by 'channel or QoS concerns'. I can read it > two ways. > > a) The piggybacked packet could exceed the maximum MTU on the last few > hops > towards the receiver. > > b) The receiver has negotiated a very tight channel in which it is > allowed > only a fixed number of bytes per packet/second. and the piggybacked > packet > results in exceeding the allocated resouces. I meant (b) mostly. > For a), it sounds like a Path MTU issue. Basically you assume the sender > does not know a valid Path MTU, otherwise it wouldn't have piggybacked. > There I would say any link should adhere to IPv6 minimum recommendation. > > For b), it seems like a special case of a) where QoS negotiation has > established a limit for packet size. In principle, if sender knows > this limit by means of Path MTU, it would not piggyback here either. > I would see these, especially b), to be more generic IPv6 issues. > This concerns all variable-length traffic over such channels or QoS > negotiated last hop(s). It's my understanding that the NSIS WG is at least looking into signalling that isn't end-to-end i.e. the receiver might have done QoS signalling one or a few hops into the network but not all the way through the network. Thus the sender wouldn't necessarily know this as part of some QoS signalling mechanisms. But it seems like all it would need to know is "don't piggyback to this destination" or perhaps "don't piggyback on packets to this destination ". The former is just one bit, but the latter requires more knowledge and signalling. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 18:48:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08576 for ; Tue, 19 Feb 2002 18:48:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09923; Tue, 19 Feb 2002 16:48:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13984; Tue, 19 Feb 2002 15:47:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JNkuKL021571 for ; Tue, 19 Feb 2002 15:46:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1JNkujK021570 for mobile-ip-dist; Tue, 19 Feb 2002 15:46:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JNksKL021563 for ; Tue, 19 Feb 2002 15:46:54 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21492 for ; Tue, 19 Feb 2002 18:46:56 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA03535 for mobile-ip@sunroof.eng.sun.com; Tue, 19 Feb 2002 18:47:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1GMGsKL014364 for ; Sat, 16 Feb 2002 14:16:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20578 for ; Sat, 16 Feb 2002 14:16:55 -0800 (PST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20644 for ; Sat, 16 Feb 2002 14:16:55 -0800 (PST) Received: from yasmine.ece.arizona.edu (yasmine [128.196.28.123]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g1GMGs3S005242 for ; Sat, 16 Feb 2002 15:16:54 -0700 (MST) Received: (from krunz@localhost) by yasmine.ece.arizona.edu (8.10.2+Sun/8.10.2) id g1GMKGe11699 for mobile-ip@sunroof.eng.sun.com; Sat, 16 Feb 2002 15:20:16 -0700 (MST) Date: Sat, 16 Feb 2002 15:20:16 -0700 (MST) Message-Id: <200202162220.g1GMKGe11699@yasmine.ece.arizona.edu> From: krunz@ece.arizona.edu To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MOBICOM 2002 - DEADLINE EXTENDED Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [my appologies if you receive duplicates of this message] Please note that the deadline for Mobicom 2002 has been EXTENDED to March 8. M. Krunz ********************************************************************* Call for Papers *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Paper Submission Deadline (extended): March 8, 2002 ********************************************************************* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: - No longer than 12 pages (double column); in font no smaller than 10 points - Fit properly on US Letter-sized paper (8.5 ' 11 inches) with reasonable margins - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier,Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: * Paper submissions due: March 8, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 * Tutorial proposals: May 1, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu EXECUTIVE COMMITTEE: -------------------- * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Mercury Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Co-Chairs: - Suresh Singh, Portland State University - Robin Kravets, University of Illinois, Urbana-Champaign * Student Poster Co-Chairs: - Elizabeth M. Belding-Royer, University of California, Santa Barbara - Sung-Ju Lee, HP Laboratories * Student Travel Award Co-Chairs: - Yuguang Fang, University of Florida - Violet R. Syrotiuk, University of Texas at Dallas * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Webmaster: Michael E. Kounavis, Columbia University PROGRAM COMMITTEE: -------------------- Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University Program Committee: - Arup Acharya, IBM Research - Prathima Agrawal, Telcordia - B. R. Badrinath, Rutgers University - Victor Bahl, Microsoft Research - Stefano Basagni, Northeastern University - Roberto Battiti, University of Trento - Pravin Bhagwat, ReefEdge - Chatschik Bisdikian, IBM Research - Scott Corson, Flarion - Sajal Das, University Texas at Arlington - Nigel Davies, Lancaster University - Dan Duchamp, Stevens Institute of Technology - Maria Ebling, IBM Research - Magda El-Zarki, University of California, Irvine - Anthony Ephremides, University of Maryland - Deborah Estrin, University of California, Los Angeles - J.J. Garcia-Luna-Aceves, University of California at Santa Cruz - Mario Gerla, University of California, Los Angeles - Ramesh Govindan, USC/ISI - Ravi Jain, Telcordia - David B. Johnson, Rice University - Anthony Joseph, University of California, Berkeley - Edward Knightly, Rice University - Tom LaPorta, Lucent Technologies - Songwu Lu, University of California, Los Angeles - Robert Morris, MIT - S. Muthukrishnan, AT&T Research - Brian Noble, University of Michigan - Venkat Padmanabhan, Microsoft Research - Charles Perkins, Nokia - Chiara Petrioli, University "La Sapienza" - George Polyzos, Athens University of Economics and Business - Parmesh Ramanathan, University of Wisconsin - Madison - Ram Ramanathan, BBN Technologies - Ramachandran Ramjee, Lucent Technologies - Daniela Rus, Dartmouth College - Srinivasan Seshan, Carnegie Mellon University - Kang G. Shin, University of Michigan - Suresh Singh, Portland State University - Mani Srivastava, University of California, Los Angeles - Frank Stajano, AT&T Laboratories Cambridge - Martha Steenstrup, Stow Research - Violet R. Syrotiuk, University of Texas at Dallas - Leandros Tassiulas, University of Maryland - Nitin H. Vaidya, University of Illinois at Urbana-Champaign - Andras Valko, Ericsson Research - Adam Wolisz, Technical University of Berlin - Michele Zorzi, Universita di Ferrara From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 19:17:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09084 for ; Tue, 19 Feb 2002 19:17:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24156; Tue, 19 Feb 2002 17:17:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01988; Tue, 19 Feb 2002 16:17:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K0G1KL021821 for ; Tue, 19 Feb 2002 16:16:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K0G1Wl021820 for mobile-ip-dist; Tue, 19 Feb 2002 16:16:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K0FvKL021813 for ; Tue, 19 Feb 2002 16:15:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00467 for ; Tue, 19 Feb 2002 16:16:00 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20961 for ; Tue, 19 Feb 2002 17:15:59 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA05035; Tue, 19 Feb 2002 16:15:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1K0Fwx11156; Tue, 19 Feb 2002 16:15:58 -0800 X-mProtect:  Tue, 19 Feb 2002 16:15:58 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNH36HB; Tue, 19 Feb 2002 16:15:55 PST Message-ID: <3C72EABB.BF0496CF@iprg.nokia.com> Date: Tue, 19 Feb 2002 16:15:55 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Erik, Erik Nordmark wrote: > > b) The receiver has negotiated a very tight channel in which it is > > allowed > > only a fixed number of bytes per packet/second. and the piggybacked > > packet > > results in exceeding the allocated resouces. > > I meant (b) mostly. > > > For a), it sounds like a Path MTU issue. Basically you assume the sender > > does not know a valid Path MTU, otherwise it wouldn't have piggybacked. > > There I would say any link should adhere to IPv6 minimum recommendation. > > > > For b), it seems like a special case of a) where QoS negotiation has > > established a limit for packet size. In principle, if sender knows > > this limit by means of Path MTU, it would not piggyback here either. > > I would see these, especially b), to be more generic IPv6 issues. > > This concerns all variable-length traffic over such channels or QoS > > negotiated last hop(s). > > It's my understanding that the NSIS WG is at least looking into > signalling that isn't end-to-end i.e. the receiver might have done QoS > signalling one or a few hops into the network but not all the way through > the network. > Thus the sender wouldn't necessarily know this as part of some QoS signalling > mechanisms. > But it seems like all it would need to know is "don't piggyback to this > destination" or perhaps "don't piggyback on packets to this destination > ". The former is just one bit, but the latter requires > more knowledge and signalling. But isnt this again a generic IPv6 issue? IPv6 extension headers can never be added onto IPv6 packets on such QoS negotiated links. The real issue seems to be the ability of such link layers to handle variable length IPv6 packets. Sorry for saying the same thing again (or am I missing something very obvious). regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 19 23:49:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14745 for ; Tue, 19 Feb 2002 23:49:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17824; Tue, 19 Feb 2002 21:49:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09138; Tue, 19 Feb 2002 20:49:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K4mKKL022571 for ; Tue, 19 Feb 2002 20:48:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K4mKcB022570 for mobile-ip-dist; Tue, 19 Feb 2002 20:48:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K4mHKL022563 for ; Tue, 19 Feb 2002 20:48:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07454 for ; Tue, 19 Feb 2002 20:48:20 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15857 for ; Tue, 19 Feb 2002 20:48:20 -0800 (PST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1K4mJe14226 for ; Tue, 19 Feb 2002 20:48:19 -0800 (PST) Message-ID: <000901c1b9c9$9867f780$1b6015ac@T23KEMPF> From: "James Kempf" To: References: <00a301c1b8ab$e001d760$30ee2ca1@cisco.com> <001001c1b8d7$6167da40$8e6015ac@T23KEMPF> <01fe01c1b913$a9fe0a40$8a1b6e0a@arenanet.fi> Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Tue, 19 Feb 2002 17:55:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jari, Sorry, didn't mean to imply that there should be no header compression. The point I was trying to make is 40 bytes isn't much. Header compression is a MUST. jak ----- Original Message ----- From: "Jari Arkko" To: "James Kempf" ; Sent: Monday, February 18, 2002 11:04 PM Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > I think what you mean is two or more IP packets per scheduled packet > > transmission slot. Radio L2 frame sizes vary, of course, but on most > > cellular > > systems they are on the order of 40 bytes. This would be just enough to > > carry one uncompressed IPv6 header with no header options. > > Particularly with v6, there *has* to be header compression. I wonder > how many voice packets you could fit on 40 bytes with compression... > As far as changing 3GPP or 3GPP2 goes I too think it's hard but maybe > not *so* hard. There's for instance examples on how fast those folks have > adopted header compression when they have seen the benefits. Come > to think of it, maybe I should I ask my compression colleagues if they > have thought of putting multiple packets on a single frame... > > Jari > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 01:33:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15808 for ; Wed, 20 Feb 2002 01:33:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26566; Tue, 19 Feb 2002 22:32:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21171; Tue, 19 Feb 2002 22:32:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K6VgKL022733 for ; Tue, 19 Feb 2002 22:31:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K6VfWm022732 for mobile-ip-dist; Tue, 19 Feb 2002 22:31:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K6VbKL022725 for ; Tue, 19 Feb 2002 22:31:37 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18611 for ; Tue, 19 Feb 2002 22:31:36 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11736 for ; Tue, 19 Feb 2002 22:31:35 -0800 (PST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020220063133.IPH24910.fep01-app.kolumbus.fi@jariws1>; Wed, 20 Feb 2002 08:31:33 +0200 Message-ID: <05a001c1b9d8$4890acc0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Phil Roberts" , , "James Kempf" References: Subject: Re: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 20 Feb 2002 08:31:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I *think* we're getting into enough info about specific L2s to confuse > the issues, but not enough info to clarify them. There are layers > of framing, for example.... > > So, could we avoid this bit of rathole, or is it essential for the > discussion? I think we could probably avoid this discussion. We know the theoretical possibilities anyway, such as that link layers could employ header compression, could pack several packets onto a single frame, might have QoS channels, etc. Or then again might not have any of these. Assuming v6 lives longer than v4, the relevance of current specific link layers might not be so great. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 02:10:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23981 for ; Wed, 20 Feb 2002 02:10:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24633; Wed, 20 Feb 2002 00:10:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28307; Tue, 19 Feb 2002 23:10:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K79tKL022838 for ; Tue, 19 Feb 2002 23:09:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1K79t4Q022837 for mobile-ip-dist; Tue, 19 Feb 2002 23:09:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1K79qKL022830 for ; Tue, 19 Feb 2002 23:09:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24012 for ; Tue, 19 Feb 2002 23:09:55 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23300 for ; Wed, 20 Feb 2002 00:09:53 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1K7A0Z17398 for ; Wed, 20 Feb 2002 09:10:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Feb 2002 09:09:51 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 09:09:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 20 Feb 2002 09:08:09 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64956@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Piggybacking - DT recommendation Thread-Index: AcG5lURRF4D54lIISyiAatpmxWFp9AARyErQ To: X-OriginalArrivalTime: 20 Feb 2002 07:09:51.0189 (UTC) FILETIME=[96CB2050:01C1B9DD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1K79qKL022831 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Erik, > It's my understanding that the NSIS WG is at least looking into > signalling that isn't end-to-end i.e. the receiver might have done QoS > signalling one or a few hops into the network but not all the > way through the network. Thus the sender wouldn't necessarily know this > as part of some QoS signalling mechanisms. As NSIS chair, I sense this QoS discussion, in my opinion, is best discussed else where (like NSIS). We are currently discussing requirements, and I am sensing a requirement here. Personally, I think this issue with respect to piggybacking should be limited to: 1) MIP implementations should ensure that piggybacked data does not excede path MTU. 2) If a tight QoS channel is negotiated, piggybacking should be considered. I think point 1 is something that should be located in the MIPv6 document, while point 2 should be put into the NSIS requirements document. Is this sensible? Additionally, NSIS is trying to ensure that QoS is still end-to-end, but some of the QoS reservations may not be. For example, one might like to explicitly reserve resources in an access network, while not reserving anything in the backbone / transit network. However, to insure fairness, there should be a mechanism in place to be able inform on an end-to-end basis about the signaled QoS. best regards, John From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 08:17:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29557 for ; Wed, 20 Feb 2002 08:17:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22372; Wed, 20 Feb 2002 06:16:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08027; Wed, 20 Feb 2002 05:16:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KDG1KL023243 for ; Wed, 20 Feb 2002 05:16:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KDG1it023242 for mobile-ip-dist; Wed, 20 Feb 2002 05:16:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KDFwKL023235 for ; Wed, 20 Feb 2002 05:15:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07776 for ; Wed, 20 Feb 2002 05:16:00 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24011 for ; Wed, 20 Feb 2002 05:16:00 -0800 (PST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1KDFsE20066; Wed, 20 Feb 2002 05:15:58 -0800 (PST) Received: from oranlt ([161.44.238.48]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACB70911; Wed, 20 Feb 2002 05:15:56 -0800 (PST) From: "David R. Oran" To: , "'Phil Roberts'" , "'James Kempf'" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 20 Feb 2002 08:15:30 -0500 Organization: Cisco Systems Message-ID: <00ca01c1ba10$b0d95240$30ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <05a001c1b9d8$4890acc0$8a1b6e0a@arenanet.fi> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Jari Arkko > Sent: Wednesday, February 20, 2002 1:32 AM > To: Phil Roberts; mobile-ip@sunroof.eng.sun.com; James Kempf > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > > I *think* we're getting into enough info about specific L2s > to confuse > > the issues, but not enough info to clarify them. There are > layers of > > framing, for example.... > > > > So, could we avoid this bit of rathole, or is it essential for the > > discussion? > > I think we could probably avoid this discussion. We know the > theoretical possibilities anyway, such as that link layers > could employ header compression, could pack several packets > onto a single frame, might have QoS channels, etc. Or then > again might not have any of these. Assuming v6 lives longer > than v4, the relevance of current specific link layers might > not be so great. > There is no reason why multi-packet blocking has to be link-layer specific, any more than IPHC is link-layer specific. Some compression schemes have link-layer dependencies (e.g. cRTP), but that's because they are trying to compress the link-layer headers as well. I think that punting multi-packet blocking as a "theoretical" alternative to piggybacking because "current link layers don't do it" would be a mistake. Note that there was an interesting I.D. by Mark Handley a couple of years ago that did this for RTP. He wrote it as an alternative to some bizzare RTP multiplexing schemes that people were proposing at the time. We could look at it for guidance if there's any interest in pursuing this direction. Now, if people reach consensus that piggybacking isn't problematical for BUs with IPv6, then looking at alternatives like blocking is de-focusing. OTOH I do not see such a consensus emerging, even after nearly a year of arguing. Dave. > Jari > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 10:39:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04105 for ; Wed, 20 Feb 2002 10:39:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15184; Wed, 20 Feb 2002 08:39:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07659; Wed, 20 Feb 2002 07:38:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFbvKL023528 for ; Wed, 20 Feb 2002 07:37:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KFbvhE023527 for mobile-ip-dist; Wed, 20 Feb 2002 07:37:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFbsKL023520 for ; Wed, 20 Feb 2002 07:37:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21192 for ; Wed, 20 Feb 2002 07:37:56 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26172 for ; Wed, 20 Feb 2002 08:37:55 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1KFdqQ04156 for ; Wed, 20 Feb 2002 09:39:53 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Feb 2002 09:37:53 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 09:37:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Closure on new RH or DO Date: Wed, 20 Feb 2002 09:37:07 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12739@daebe007.NOE.Nokia.com> Thread-Topic: Closure on new RH or DO Thread-Index: AcG6JHN0lJHNSyYWEdaxoAAAhj/HZA== To: X-OriginalArrivalTime: 20 Feb 2002 15:37:08.0351 (UTC) FILETIME=[74C178F0:01C1BA24] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1KFbsKL023521 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, Issue: New RH Type (2) or a new DO to carry the HoA towards the mobile node Consensus: New RH Type Hence this issue is now closed. -Chairs From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 10:39:29 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04123 for ; Wed, 20 Feb 2002 10:39:28 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15071; Wed, 20 Feb 2002 07:39:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07765; Wed, 20 Feb 2002 07:39:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFcNKL023544 for ; Wed, 20 Feb 2002 07:38:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KFcNko023543 for mobile-ip-dist; Wed, 20 Feb 2002 07:38:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFcJKL023536 for ; Wed, 20 Feb 2002 07:38:19 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07549 for ; Wed, 20 Feb 2002 07:38:21 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25833 for ; Wed, 20 Feb 2002 07:38:20 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KFcJh14072 for ; Wed, 20 Feb 2002 07:38:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX64225; Wed, 20 Feb 2002 07:37:51 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA29849; Wed, 20 Feb 2002 07:38:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.49899.99483.482844@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 07:38:19 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64956@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64956@esebe004.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi Erik, > > > It's my understanding that the NSIS WG is at least looking into > > signalling that isn't end-to-end i.e. the receiver might have done QoS > > signalling one or a few hops into the network but not all the > > way through the network. Thus the sender wouldn't necessarily know this > > as part of some QoS signalling mechanisms. > > As NSIS chair, I sense this QoS discussion, in my opinion, is best discussed > else where (like NSIS). We are currently discussing requirements, and > I am sensing a requirement here. No. This entire subject has to do with whether piggybacking is useful for mac/phy's whose method for allocating bandwidth for elevated QoS is to give fixed sized slots. DOCSIS USG is a perfect example, and is illustrative of how bandwidth can be parceled out on a shared media. Wireless has *many* of the same considerations. For those kinds of media, piggybacking is a distinct disadvantage, especially if it affects downstream flows (which a sender would be clueless about). This has nothing to do with L3 QoS signaling. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 10:52:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04479 for ; Wed, 20 Feb 2002 10:52:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00938; Wed, 20 Feb 2002 08:51:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11803; Wed, 20 Feb 2002 07:51:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KFovKL023737 for ; Wed, 20 Feb 2002 07:50:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KFovZe023736 for mobile-ip-dist; Wed, 20 Feb 2002 07:50:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KForKL023726 for ; Wed, 20 Feb 2002 07:50:53 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11629 for ; Wed, 20 Feb 2002 07:50:55 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01064 for ; Wed, 20 Feb 2002 07:50:54 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KFopD10052 for ; Wed, 20 Feb 2002 09:50:51 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H2JL7L>; Wed, 20 Feb 2002 09:50:51 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E022D54F7@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 20 Feb 2002 09:50:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA26.5E836EC0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA26.5E836EC0 Content-Type: text/plain; charset="iso-8859-1" John, The use of the MTU seems to be extremely reasonable and quite simple, too. Thanks, Glenn > 1) MIP implementations should ensure that piggybacked data > does not excede > path MTU. > 2) If a tight QoS channel is negotiated, piggybacking should > be considered. > > I think point 1 is something that should be located in the > MIPv6 document, > while point 2 should be put into the NSIS requirements document. > > Is this sensible? > > Additionally, NSIS is trying to ensure that QoS is still end-to-end, > but some of the QoS reservations may not be. For example, one might > like to explicitly reserve resources in an access network, while not > reserving anything in the backbone / transit network. However, > to insure fairness, there should be a mechanism in place to be able > inform on an end-to-end basis about the signaled QoS. > > best regards, > John > ------_=_NextPart_001_01C1BA26.5E836EC0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Piggybacking - DT recommendation

John,

The use of the MTU seems to be extremely reasonable and quite simple, too.

Thanks,

Glenn

> 1) MIP implementations should ensure that piggybacked data
> does not excede
>    path MTU.
> 2) If a tight QoS channel is negotiated, piggybacking should
> be considered.
>
> I think point 1 is something that should be located in the
> MIPv6 document,
> while point 2 should be put into the NSIS requirements document.
>
> Is this sensible?
>
> Additionally, NSIS is trying to ensure that QoS is still end-to-end,
> but some of the QoS reservations may not be.  For example, one might
> like to explicitly reserve resources in an access network, while not
> reserving anything in the backbone / transit network.  However,
> to insure fairness, there should be a mechanism in place to be able
> inform on an end-to-end basis about the signaled QoS.
>
> best regards,
> John
>

------_=_NextPart_001_01C1BA26.5E836EC0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 11:39:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05876 for ; Wed, 20 Feb 2002 11:39:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09521; Wed, 20 Feb 2002 09:39:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26037; Wed, 20 Feb 2002 08:39:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGcCKL023874 for ; Wed, 20 Feb 2002 08:38:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KGcCOK023873 for mobile-ip-dist; Wed, 20 Feb 2002 08:38:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KGc9KL023866 for ; Wed, 20 Feb 2002 08:38:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25732 for ; Wed, 20 Feb 2002 08:38:11 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05979 for ; Wed, 20 Feb 2002 08:38:10 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1KGcHZ29153 for ; Wed, 20 Feb 2002 18:38:17 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Feb 2002 18:38:09 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 18:38:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 20 Feb 2002 18:38:09 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6498D@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Piggybacking - DT recommendation Thread-Index: AcG6JNo/GLDutPtwRTarXXS3B4RL8QAB9B+Q To: X-OriginalArrivalTime: 20 Feb 2002 16:38:09.0230 (UTC) FILETIME=[FACF46E0:01C1BA2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1KGc9KL023867 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Michael, > No. This entire subject has to do with whether > piggybacking is useful for mac/phy's whose method > for allocating bandwidth for elevated QoS is to > give fixed sized slots. DOCSIS USG is a perfect > example, and is illustrative of how bandwidth > can be parceled out on a shared media. Wireless > has *many* of the same considerations. For > those kinds of media, piggybacking is a > distinct disadvantage, especially if it affects > downstream flows (which a sender would be > clueless about). So, if a layer 2 API which had QoS info that a MIP implementation could leverage, there may not be complications. Of course, this is an IF ... however, I think Erik did bring NSIS into the discussion, and I'd be happy to get some input on level 3 MIP QoS needs in NSIS. thanks, John From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 12:31:02 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09870 for ; Wed, 20 Feb 2002 12:30:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14800; Wed, 20 Feb 2002 09:30:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13365; Wed, 20 Feb 2002 09:30:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KHTgKL024120 for ; Wed, 20 Feb 2002 09:29:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KHTgVv024119 for mobile-ip-dist; Wed, 20 Feb 2002 09:29:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KHTdKL024112 for ; Wed, 20 Feb 2002 09:29:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10366 for ; Wed, 20 Feb 2002 09:29:42 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23431 for ; Wed, 20 Feb 2002 09:29:41 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KHTeh03203 for ; Wed, 20 Feb 2002 09:29:40 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX66189; Wed, 20 Feb 2002 09:29:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA29866; Wed, 20 Feb 2002 09:29:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.56578.372769.972745@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 09:29:38 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC6498D@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC6498D@esebe004.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit john.loughney@nokia.com writes: > Hi Michael, > > > No. This entire subject has to do with whether > > piggybacking is useful for mac/phy's whose method > > for allocating bandwidth for elevated QoS is to > > give fixed sized slots. DOCSIS USG is a perfect > > example, and is illustrative of how bandwidth > > can be parceled out on a shared media. Wireless > > has *many* of the same considerations. For > > those kinds of media, piggybacking is a > > distinct disadvantage, especially if it affects > > downstream flows (which a sender would be > > clueless about). > > So, if a layer 2 API which had QoS info that a MIP implementation > could leverage, there may not be complications. Of course, this > is an IF ... however, I think Erik did bring NSIS into the > discussion, and I'd be happy to get some input on level 3 > MIP QoS needs in NSIS. This isn't an issue of information and/or signaling. It's an issue of how bits are placed on the wire. Many shared media L2 QoS schemes like fixed sized slots, and piggybacking is harmful when they are used willy-nilly, especially by senders who don't know that altering the payload size of a flow is harmful. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 13:31:43 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15037 for ; Wed, 20 Feb 2002 13:31:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13671; Wed, 20 Feb 2002 11:31:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03412; Wed, 20 Feb 2002 10:31:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KIUTKL024295 for ; Wed, 20 Feb 2002 10:30:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KIUT7T024294 for mobile-ip-dist; Wed, 20 Feb 2002 10:30:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KIUPKL024287 for ; Wed, 20 Feb 2002 10:30:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07667 for ; Wed, 20 Feb 2002 10:30:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12959 for ; Wed, 20 Feb 2002 11:30:26 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA20890 for ; Wed, 20 Feb 2002 10:30:25 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1KIUPO25006; Wed, 20 Feb 2002 10:30:25 -0800 X-mProtect:  Wed, 20 Feb 2002 10:30:25 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1ciVDu; Wed, 20 Feb 2002 10:30:21 PST Message-ID: <3C73EB3D.B264177E@iprg.nokia.com> Date: Wed, 20 Feb 2002 10:30:21 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: charliep@iprg.nokia.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <200202161808.g1GI8ig30602@givry.rennes.enst-bretagne.fr> Content-Type: multipart/mixed; boundary="------------EB4DB5867965145216FF0529" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------EB4DB5867965145216FF0529 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > PS: a detail: is it required/useful to add a tag to every packets? Hello Francis, Jari M and I have the attached text on tagging HAO. It addresses the issue that Pekka Nikander brought up. Comments would be appreciated. Regards, -Rajeev ps. the state machine comes out better in the attachment. --------------EB4DB5867965145216FF0529 Content-Type: text/plain; charset=us-ascii; name="tag-or-not.txt" Content-Disposition: inline; filename="tag-or-not.txt" Content-Transfer-Encoding: 7bit To Tag or Not to Tag ? I. Tagging A CN, in the absence of a BCE, includes the source IP address in the received packet on out-going packets to the Home Address. The source IP address (CoA) and the HoA can be stored in a small buffer; the mapping could also be part of destination cache (cf. Francis Dupont's note to the mailing list). This process of including the CoA in the absence of an authorized BCE is called tagging, and the CoA thus included is called the tagged entry. II. Tagging requirements a) should allow a MN to use unverified HAO b) should allow non-mobile Generic Node (GN) to operate with no added harm III. Basic operation - always tag (with an exception below in IV.b) in the presence of unverified HAO and in absence of authorized BCE. However, - when there is no HAO, the CN does not create HoA <-> CoA entry. This applies for communication with a GN and when a MN is at home. So, the solution has to be able to distinguish between a MN away from home and a malicious node attempting to create a bogus tagged entry at the CN. For this, IV. Basic CN rules: a) packets without HAO overide the tagged entry b) transition from ``no-tagging'' to ``tagging'' state is slow when a remote node is actively communicating without HAO; - at least `n' consecutive packets with HAO containing a particular CoA must arrive before that CoA is added to the unverified BCE. However, if the CN is creating a fresh destination cache entry, it does not apply this rule so that ``cold start'' packets contain tags. c) transition from ``tagging'' state to ``no-tagging'' state is immediate; a single packet without HAO removes the tagged entry; - a randomized timer disallows creating the CoA entry again until the timer expires. Moreover, the lifetime of a tag is short; unless recently refreshed with HAO, CN transitions to ``no-tagging'' state. [Note: this rule assumes that an attacker cannot spoof the MN's current CoA] d) In the ``no-tagging'' state, the CN drops packets with HAO. The CN state machine can be described as below. ------ | | longer | V ---------- | no | |tagging | | | ---------- ^ | faster | | slower (for active communication) | | | V ---------- | | |tagging | | | ---------- ^ | | | shorter (unless refreshed) ------ With this, V. GN operation a) when a GN is not in active communication, an attacker can create an unverified BCE tagging the GN's address with a genuine or bogus CoA. - before the CN does anything, if the GN _initiates_ packets to CN, the tag disappears - if the CN transmitts packets to the GN, GN's response (e.g., TCP ack, RTCP packet) will remove the tag from unverified BCE - if the GN's site is configured to filter packets containing the tag, those packets will be dropped. Since the lifetime of unverified BCE is small, the entry will expire unless the attacker keeps on refreshing the entry. In any case, this is similar to DoS today; the tag provides the option to inspect the ``true source'' of the packet. b) the attacker attempts to tag an entry during active communication between a CN and a GN with the hope that the GN's firewall will drop packets - any packet transmission from GN to CN will force it not to tag - only when the GN is a ``one-way'' listener, and its firewall drops all tagged packets the GN would notice disruption. However, such sessions are rare in practice, since if a GN is interested at all in the packet stream from CN, it has to act when it does not receive packets (for an extended stretch). It is likely that rate limiting the tagged packets will facilitate faster repair of the CN's unverified BCE. --------------EB4DB5867965145216FF0529-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 13:50:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15697 for ; Wed, 20 Feb 2002 13:50:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00802; Wed, 20 Feb 2002 11:49:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11320; Wed, 20 Feb 2002 10:49:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KImoKL024399 for ; Wed, 20 Feb 2002 10:48:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KImoZJ024398 for mobile-ip-dist; Wed, 20 Feb 2002 10:48:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KImlKL024391 for ; Wed, 20 Feb 2002 10:48:47 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13748 for ; Wed, 20 Feb 2002 10:48:48 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04162 for ; Wed, 20 Feb 2002 10:48:48 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1KImlE29194 for ; Wed, 20 Feb 2002 10:48:47 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX68638; Wed, 20 Feb 2002 10:48:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA29879; Wed, 20 Feb 2002 10:48:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.61322.438392.658870@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 10:48:42 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A new proposal for handling Home Address destination options In-Reply-To: <3C6C7780.4CFAA7B4@iprg.nokia.com> References: <3C6C7780.4CFAA7B4@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins writes: > For UnVCoAs, more care is needed. We can make some simple > improvements to the way that correspondent nodes handle UnvHAOs > that will substantially reduce or eliminate any residual threat > of a viable reflector attack. The first weapon in the arsenal > against these attacks is to tag outgoing packets with the > unverifiable care-of address. These packets will then reach > the home agent. The home agent has to look up its Binding > Cache entry for the mobile node. If the care-of address does > not match the care-of address tagged by the correspondent node, > then the home agent can begin diagnostics or tracing for a > possible attacker, and then it would drop such packets. If the > care-of address matches, then we are back to good, with much > better security. Typically, along with tagging the packet, > the correspondent node would also take action to establish a > Binding Cache entry so that the care-of address would become > verifiable. I haven't been following closely, but I hope that somebody's pointed out that: 1) The home agent may be either non-existant or under the control of the attacker 2) That a CN's stack which accepted home address options from an unknown source address would be subject to a spoofing attack which defeats ingress filtering. In short, this doesn't seem to increase security. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 14:22:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16888 for ; Wed, 20 Feb 2002 14:22:22 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09933; Wed, 20 Feb 2002 12:22:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27156; Wed, 20 Feb 2002 11:22:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KJLDKL024475 for ; Wed, 20 Feb 2002 11:21:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KJLCYh024474 for mobile-ip-dist; Wed, 20 Feb 2002 11:21:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KJL9KL024467 for ; Wed, 20 Feb 2002 11:21:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26807 for ; Wed, 20 Feb 2002 11:21:11 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17188 for ; Wed, 20 Feb 2002 12:21:09 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KJL7D26702 for ; Wed, 20 Feb 2002 13:21:08 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H2JR2Z>; Wed, 20 Feb 2002 13:21:08 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E022D5B77@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Wed, 20 Feb 2002 13:21:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA43.BE96E5E0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA43.BE96E5E0 Content-Type: text/plain; charset="iso-8859-1" Some more thoughts came up on this: Perhaps we should use SDP to indicate something like MTU or piggybacking preference and alter the socket API to allow per-flow/media policy. This would allow these non-transparent bearers to exist while not detracting the benefits of piggybacking when it simply isn't a concern. Of course this would be doing extra work in the upper layers and APIs just for these special link layers and the jitter point would still be an area of contention. regards, Glenn > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, February 20, 2002 11:30 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Piggybacking - DT recommendation > > > john.loughney@nokia.com writes: > > Hi Michael, > > > > > No. This entire subject has to do with whether > > > piggybacking is useful for mac/phy's whose method > > > for allocating bandwidth for elevated QoS is to > > > give fixed sized slots. DOCSIS USG is a perfect > > > example, and is illustrative of how bandwidth > > > can be parceled out on a shared media. Wireless > > > has *many* of the same considerations. For > > > those kinds of media, piggybacking is a > > > distinct disadvantage, especially if it affects > > > downstream flows (which a sender would be > > > clueless about). > > > > So, if a layer 2 API which had QoS info that a MIP implementation > > could leverage, there may not be complications. Of course, this > > is an IF ... however, I think Erik did bring NSIS into the > > discussion, and I'd be happy to get some input on level 3 > > MIP QoS needs in NSIS. > > This isn't an issue of information and/or > signaling. It's an issue of how bits are placed > on the wire. Many shared media L2 QoS schemes > like fixed sized slots, and piggybacking is > harmful when they are used willy-nilly, > especially by senders who don't know that > altering the payload size of a flow is harmful. > > Mike > ------_=_NextPart_001_01C1BA43.BE96E5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Piggybacking - DT recommendation

Some more thoughts came up on this:

Perhaps we should use SDP to indicate something like = MTU or piggybacking preference and alter the socket API to allow = per-flow/media policy.

This would allow these non-transparent bearers to = exist while not detracting the benefits of piggybacking when it simply = isn't a concern.

Of course this would be doing extra work in the upper = layers and APIs just for these special link layers and the jitter point = would still be an area of contention.

regards,

Glenn

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Wednesday, February 20, 2002 11:30 = AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Piggybacking - DT = recommendation
>
>
> john.loughney@nokia.com writes:
>  > Hi Michael,
>  >
>  > >    No. This = entire subject has to do with whether
>  > >    piggybacking = is useful for mac/phy's whose method
>  > >    for = allocating bandwidth for elevated QoS is to
>  > >    give fixed = sized slots. DOCSIS USG is a perfect
>  > >    example, and = is illustrative of how bandwidth
>  > >    can be = parceled out on a shared media. Wireless
>  > >    has *many* of = the same considerations. For
>  > >    those kinds = of media, piggybacking is a
>  > >    distinct = disadvantage, especially if it affects
>  > >    downstream = flows (which a sender would be
>  > >    clueless = about).
>  >
>  > So, if a layer 2 API which had QoS = info that a MIP implementation
>  > could leverage, there may not be = complications.  Of course, this
>  > is an IF ... however, I think Erik = did bring NSIS into the
>  > discussion, and I'd be happy to get = some input on level 3
>  > MIP QoS needs in NSIS.
>
>    This isn't an issue of = information and/or
>    signaling. It's an issue of = how bits are placed
>    on the wire. Many shared = media L2 QoS schemes
>    like fixed sized slots, and = piggybacking is
>    harmful when they are used = willy-nilly,
>    especially by senders who = don't know that
>    altering the payload size of = a flow is harmful.
>
>          = Mike
>

------_=_NextPart_001_01C1BA43.BE96E5E0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 14:24:06 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16977 for ; Wed, 20 Feb 2002 14:24:06 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10987; Wed, 20 Feb 2002 12:24:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27900; Wed, 20 Feb 2002 11:23:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KJN8KL024513 for ; Wed, 20 Feb 2002 11:23:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KJN8Yh024512 for mobile-ip-dist; Wed, 20 Feb 2002 11:23:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KJN5KL024505 for ; Wed, 20 Feb 2002 11:23:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26911 for ; Wed, 20 Feb 2002 11:23:06 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21607 for ; Wed, 20 Feb 2002 11:23:06 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1KJMmh09553; Wed, 20 Feb 2002 11:22:48 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX69734; Wed, 20 Feb 2002 11:22:20 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA29888; Wed, 20 Feb 2002 11:22:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15475.63367.511387.192568@thomasm-u1.cisco.com> Date: Wed, 20 Feb 2002 11:22:47 -0800 (PST) To: Pekka Nikander Cc: mat@cisco.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options In-Reply-To: <3C73F519.9010603@nomadiclab.com> References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <15475.61322.438392.658870@thomasm-u1.cisco.com> <3C73F519.9010603@nomadiclab.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander writes: > Mike, > > Would you please clarify what you are thinking. I just > don't follow. It seems that there's a general proposition in the proposal that the Home Agent can protect a correspondent node from misbehaving MN's, and that will provide an adequate defense against misuse. The problem is that the CN generally has no trust relationship with the HA, if indeed the HA exists at all. This seems like a permutation on my HA cookies draft which says that HA's can potentially be used as optimizations for security, but their existence are not certain, and when they exist, their trustworthiness must be considered to be the same trustworthiness of the MN. Mike > > > Charlie Perkins writes: > > > For UnVCoAs, more care is needed. > > > ... to tag outgoing packets with the > > > unverifiable care-of address. ... > > Michael Thomas wrote: > > I haven't been following closely, but I hope that > > somebody's pointed out that: > > > > 1) The home agent may be either non-existant or > > under the control of the attacker > > 2) That a CN's stack which accepted home address > > options from an unknown source address would be > > subject to a spoofing attack which defeats > > ingress filtering. > > > > In short, this doesn't seem to increase security. > > > At least for me, the only purpose of tagging is to make > sure that whenever a CN replies to the HoA instead of CoA, > the CoA address is carried in the reply. That indeed > has the danger that the CN sends a reply to an address > where an attacker, assumedly located at the CoA (or close > thereof), cannot send packets directly to. However, this > can be noted and acted upon since the replies contain the > tag. > > Thus, the tag does increase security in two ways: > > - it prevents information about the CoA > from being lost at CN, thereby making traceback > etc. easier > > - it allows packets to be filtered based on the > existense or contents of the tag. > > IMHO, these seem good enough that HOAs could again > be used with triangular routing. Provided, of course, > that the tagging can be performed correctly in the > first place. The suggestion by Rajeev and Jari M. > seem to achieve that, but at least I need to think about > it more before I can form my opinion upon it. There > may be nasty details that we are still missing; I just > don't know. > > --Pekka Nikander > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 14:47:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17879 for ; Wed, 20 Feb 2002 14:47:36 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00435; Wed, 20 Feb 2002 12:47:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06469; Wed, 20 Feb 2002 11:47:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KJkMKL024704 for ; Wed, 20 Feb 2002 11:46:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KJkMYT024703 for mobile-ip-dist; Wed, 20 Feb 2002 11:46:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KJkJKL024696 for ; Wed, 20 Feb 2002 11:46:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29647 for ; Wed, 20 Feb 2002 11:46:21 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21431 for ; Wed, 20 Feb 2002 12:46:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA27111; Wed, 20 Feb 2002 11:46:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1KJkJD00723; Wed, 20 Feb 2002 11:46:19 -0800 X-mProtect:  Wed, 20 Feb 2002 11:46:19 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin19.iprg.nokia.com (205.226.20.249, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHOVThx; Wed, 20 Feb 2002 11:46:16 PST Message-ID: <3C73FCA7.7712F98B@iprg.nokia.com> Date: Wed, 20 Feb 2002 11:44:39 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Oran CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <00ca01c1ba10$b0d95240$30ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "David R. Oran" wrote: > Now, if people reach consensus that piggybacking isn't problematical for > BUs with IPv6, then looking at alternatives like blocking is > de-focusing. OTOH I do not see such a consensus emerging, even after > nearly a year of arguing. What do you think about my suggestion that managing resources on tight data channels is, in essence, a QoS problem? I thought this was pretty clear; the very statement that a particular channel needs to be reserved purely for one kind of data stream is almost tautologically a QoS problem. I note in this connection, that even the most fervent proponents of eliminating piggybacking have no solution to offer if some other node sends a packet to the bandwidth-constrained channel which is currently consumed with the single-sized packet stream. An appropriate QoS solution would, on the other hand, solve both problems neatly. I am optimistic that we will reach consensus soon. I really think there is an answer that will satisfy everyone's needs. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 20 15:37:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19208 for ; Wed, 20 Feb 2002 15:37:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04613; Wed, 20 Feb 2002 13:36:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22139; Wed, 20 Feb 2002 12:35:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KKYLKL024833 for ; Wed, 20 Feb 2002 12:34:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1KKYLVC024832 for mobile-ip-dist; Wed, 20 Feb 2002 12:34:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1KKYIKL024825 for ; Wed, 20 Feb 2002 12:34:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12323 for ; Wed, 20 Feb 2002 12:34:21 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19935 for ; Wed, 20 Feb 2002 12:34:20 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 2E603A; Wed, 20 Feb 2002 21:14:14 +0200 (EET) Message-ID: <3C73F519.9010603@nomadiclab.com> Date: Wed, 20 Feb 2002 21:12:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020212 X-Accept-Language: en-us MIME-Version: 1.0 To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <15475.61322.438392.658870@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, Would you please clarify what you are thinking. I just don't follow. > Charlie Perkins writes: > > For UnVCoAs, more care is needed. > > ... to tag outgoing packets with the > > unverifiable care-of address. ... Michael Thomas wrote: > I haven't been following closely, but I hope that > somebody's pointed out that: > > 1) The home agent may be either non-existant or > under the control of the attacker > 2) That a CN's stack which accepted home address > options from an unknown source address would be > subject to a spoofing attack which defeats > ingress filtering. > > In short, this doesn't seem to increase security. At least for me, the only purpose of tagging is to make sure that whenever a CN replies to the HoA instead of CoA, the CoA address is carried in the reply. That indeed has the danger that the CN sends a reply to an address where an attacker, assumedly located at the CoA (or close thereof), cannot send packets directly to. However, this can be noted and acted upon since the replies contain the tag. Thus, the tag does increase security in two ways: - it prevents information about the CoA from being lost at CN, thereby making traceback etc. easier - it allows packets to be filtered based on the existense or contents of the tag. IMHO, these seem good enough that HOAs could again be used with triangular routing. Provided, of course, that the tagging can be performed correctly in the first place. The suggestion by Rajeev and Jari M. seem to achieve that, but at least I need to think about it more before I can form my opinion upon it. There may be nasty details that we are still missing; I just don't know. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 07:35:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15008 for ; Thu, 21 Feb 2002 07:35:41 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04959; Thu, 21 Feb 2002 05:35:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08796; Thu, 21 Feb 2002 04:35:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LCYZKL026908 for ; Thu, 21 Feb 2002 04:34:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LCYZRU026907 for mobile-ip-dist; Thu, 21 Feb 2002 04:34:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LCYVKL026900 for ; Thu, 21 Feb 2002 04:34:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14292 for ; Thu, 21 Feb 2002 04:34:34 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25278 for ; Thu, 21 Feb 2002 04:34:33 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 90A85A; Thu, 21 Feb 2002 14:36:19 +0200 (EET) Message-ID: <3C74E924.9090807@nomadiclab.com> Date: Thu, 21 Feb 2002 14:33:40 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <15475.61322.438392.658870@thomasm-u1.cisco.com> <3C73F519.9010603@nomadiclab.com> <15475.63367.511387.192568@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, Thanks for the clarification. > It seems that there's a general proposition in the > proposal that the Home Agent can protect a correspondent > node from misbehaving MN's, and that will provide an > adequate defense against misuse. The problem is that > the CN generally has no trust relationship with the > HA, if indeed the HA exists at all. > > This seems like a permutation on my HA cookies draft > which says that HA's can potentially be used as > optimizations for security, but their existence > are not certain, and when they exist, their > trustworthiness must be considered to be the > same trustworthiness of the MN. First, it looks like the implementation proposal by Rajeev and Jari M. takes care of the case when there is no HA at all. It aims at protecting innocent non-mobile nodes from attacks where somebody tries to cause their packets to be inappropriately tagget so that they get dropped by some firewall. What comes to the trustworthiness of an existing HA, I don't immediately see how it is relevant here. As far as I can see, unauthenticated HAOs are mainly a threat against "the others" in the internet, not the mobile nodes or home agents. The basic threat is that somebody sends HAOs that contain a bogus HoA, and the basic consequences include DoS against the node at the claimed CoA and DDoS against the network at the claimed HoA. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 08:49:30 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16961 for ; Thu, 21 Feb 2002 08:49:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29199; Thu, 21 Feb 2002 05:49:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23689; Thu, 21 Feb 2002 05:49:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LDm9KL027024 for ; Thu, 21 Feb 2002 05:48:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LDm96j027023 for mobile-ip-dist; Thu, 21 Feb 2002 05:48:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LDm4KL027016 for ; Thu, 21 Feb 2002 05:48:05 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1LDm2x16069; Thu, 21 Feb 2002 14:48:03 +0100 (MET) Date: Thu, 21 Feb 2002 14:43:32 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: Vijay Devarapalli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C72EABB.BF0496CF@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > But isnt this again a generic IPv6 issue? IPv6 extension headers can > never be added onto IPv6 packets on such QoS negotiated links. The > real issue seems to be the ability of such link layers to handle > variable length IPv6 packets. Sorry for saying the same thing again > (or am I missing something very obvious). It is generic in the sense that if there was a generic protocol or mechanism for the IP layer or the applications using it to determine which extension headers to add then such a generic protocol or mechanism would need to at least think about this issue. But there is no such generic protocol or mechanism right now, and I don't know of any plans for one. SO this is not our problem. If applications explicitly specify extension headers that cause problems at the other end the application and/or app protocol would presumably have a way to deal with that. So this is not our problem. If somebody has a mechanism that, unknown to the application, causes the IP packets to have other information piggybacked, then we have a specific protocol to worry about and the "its the application's problem" above doesn't apply. This is the case here. So I don't think saying that the problem in theory exists elsewhere is a good reason to not consider this particular practical instanciation of the problem. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 09:07:01 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17664 for ; Thu, 21 Feb 2002 09:07:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02807; Thu, 21 Feb 2002 06:06:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27632; Thu, 21 Feb 2002 06:06:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LE64KL027077 for ; Thu, 21 Feb 2002 06:06:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LE64ND027076 for mobile-ip-dist; Thu, 21 Feb 2002 06:06:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LE61KL027069 for ; Thu, 21 Feb 2002 06:06:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25806 for ; Thu, 21 Feb 2002 06:06:04 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22447 for ; Thu, 21 Feb 2002 06:06:04 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA18000 for ; Thu, 21 Feb 2002 07:06:03 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA09062 for ; Thu, 21 Feb 2002 07:06:03 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 21 Feb 2002 07:06:00 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9F9022EC83; Thu, 21 Feb 2002 15:00:15 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Vijay Devarapalli , Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: From: Alexandru Petrescu Date: 21 Feb 2002 15:05:54 +0100 In-Reply-To: Message-Id: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik Nordmark writes: > If somebody has a mechanism that, unknown to the application, causes > the IP packets to have other information piggybacked, then we have > a specific protocol to worry about and the "its the application's problem" > above doesn't apply. This is the case here. Hi Erik, I don't want to intrude too much into your discussion, but I see the simple AH usage as a form of piggybacking that might fit your definition above. The application (web browser using TCP) is not aware that someone has manually set an SA between this node and a web server. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 10:17:39 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19959 for ; Thu, 21 Feb 2002 10:17:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17013; Thu, 21 Feb 2002 07:17:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06440; Thu, 21 Feb 2002 07:17:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFGQKL027369 for ; Thu, 21 Feb 2002 07:16:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LFGQEp027368 for mobile-ip-dist; Thu, 21 Feb 2002 07:16:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFGMKL027361 for ; Thu, 21 Feb 2002 07:16:23 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1LFGKx24390; Thu, 21 Feb 2002 16:16:20 +0100 (MET) Date: Thu, 21 Feb 2002 16:11:48 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I don't want to intrude too much into your discussion, but I see the > simple AH usage as a form of piggybacking that might fit your > definition above. The application (web browser using TCP) is not > aware that someone has manually set an SA between this node and a web > server. Agreed. This means there is another category that is similar to the one I had about applications. If the admin on H1 sets up an IPsec policy for packets to H2 it will effect the size of packets sent to and received from H2 (the policies better be symmeric). Thus in this case the admin of H1 has some control and can presumably deal with problems caused by this. This is quite different than when H2 decides to use piggybacking for packets sent to H1 - neither applications nor admin on H1 is aware or can control this. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 10:45:27 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21210 for ; Thu, 21 Feb 2002 10:45:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23640; Thu, 21 Feb 2002 07:45:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11013; Thu, 21 Feb 2002 07:45:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFi6KL027443 for ; Thu, 21 Feb 2002 07:44:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LFi6qw027442 for mobile-ip-dist; Thu, 21 Feb 2002 07:44:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LFi3KL027435 for ; Thu, 21 Feb 2002 07:44:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11358 for ; Thu, 21 Feb 2002 07:44:05 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15706 for ; Thu, 21 Feb 2002 08:44:04 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA08604 for ; Thu, 21 Feb 2002 08:44:03 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA18462 for ; Thu, 21 Feb 2002 08:44:02 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Thu, 21 Feb 2002 09:44:01 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7EF552EC83; Thu, 21 Feb 2002 16:38:20 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Vijay Devarapalli , Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: From: Alexandru Petrescu Date: 21 Feb 2002 16:43:59 +0100 In-Reply-To: Message-Id: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik Nordmark writes: > This is quite different than when H2 decides to use piggybacking for > packets sent to H1 - neither applications nor admin on H1 is aware or > can control this. In the previous case I described with AH being piggybacked, the SA could be set dynamically, right? Using your notation, H2 is a web client and decides to securely interogate H1 which is a web server. H1 initially has no knowledge about H2, nor does it trust it. Then H2 can still securely communicate with H1, relying on IKE. H2 provokes the dynamic creation of the SA on H1, in the same way that an MN would provoke the creation of a binding cache entry on CN. But, as you said, this only exposes that other mechanisms have the same issue, and not necessarily that it's good to live with it. I don't know. Or: I know, but I often change my mind. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 12:49:58 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26332 for ; Thu, 21 Feb 2002 12:49:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25628; Thu, 21 Feb 2002 09:49:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09012; Thu, 21 Feb 2002 09:49:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LHm7KL027960 for ; Thu, 21 Feb 2002 09:48:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LHm7e6027959 for mobile-ip-dist; Thu, 21 Feb 2002 09:48:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LHm2KL027952 for ; Thu, 21 Feb 2002 09:48:03 -0800 (PST) Received: from lillen (vpn-129-159-0-30.EMEA.Sun.COM [129.159.0.30]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1LHlwx08724; Thu, 21 Feb 2002 18:47:58 +0100 (MET) Date: Thu, 21 Feb 2002 18:43:25 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Vijay Devarapalli , Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In the previous case I described with AH being piggybacked, the SA > could be set dynamically, right? Using your notation, H2 is a web > client and decides to securely interogate H1 which is a web server. IPsec isn't guaranteed to work unless the policies are symmetrical as far as I understand. The SAs can be created dynamically e.g. using IKE which I think is what you are referring to. I think implementations of IPsec (as opposed to the spec) allow the type of server you talk about where each connection will be latched to a policy based on whether the SYN was secured or not. > H1 initially has no knowledge about H2, nor does it trust it. Then H2 > can still securely communicate with H1, relying on IKE. H2 provokes > the dynamic creation of the SA on H1, in the same way that an MN would > provoke the creation of a binding cache entry on CN. > > But, as you said, this only exposes that other mechanisms have the > same issue, and not necessarily that it's good to live with it. I > don't know. Or: I know, but I often change my mind. I think in the above case an IPsec aware application running with this "allow secure or non-secure - latch in each connection" could of course tell (using some IPsec specific API to ask about the resulting IPsec policy for the connection). And in general, for security reasons, I think an app with that policy would like to know. So it still is a bit different than getting unsuspecting piggybacking. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 14:39:59 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01116 for ; Thu, 21 Feb 2002 14:39:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20907; Thu, 21 Feb 2002 11:39:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16020; Thu, 21 Feb 2002 11:39:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LJcPKL028247 for ; Thu, 21 Feb 2002 11:38:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LJcPcU028246 for mobile-ip-dist; Thu, 21 Feb 2002 11:38:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LJcMKL028239 for ; Thu, 21 Feb 2002 11:38:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15578 for ; Thu, 21 Feb 2002 11:38:24 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11167 for ; Thu, 21 Feb 2002 12:38:23 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1LJcME23279; Thu, 21 Feb 2002 11:38:22 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAX94203; Thu, 21 Feb 2002 11:37:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00264; Thu, 21 Feb 2002 11:38:22 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15477.19629.796937.947498@thomasm-u1.cisco.com> Date: Thu, 21 Feb 2002 11:38:21 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Michael Thomas Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options In-Reply-To: <3C74E924.9090807@nomadiclab.com> References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <15475.61322.438392.658870@thomasm-u1.cisco.com> <3C73F519.9010603@nomadiclab.com> <15475.63367.511387.192568@thomasm-u1.cisco.com> <3C74E924.9090807@nomadiclab.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander writes: > Mike, > > Thanks for the clarification. > > > It seems that there's a general proposition in the > > proposal that the Home Agent can protect a correspondent > > node from misbehaving MN's, and that will provide an > > adequate defense against misuse. The problem is that > > the CN generally has no trust relationship with the > > HA, if indeed the HA exists at all. > > > > This seems like a permutation on my HA cookies draft > > which says that HA's can potentially be used as > > optimizations for security, but their existence > > are not certain, and when they exist, their > > trustworthiness must be considered to be the > > same trustworthiness of the MN. > > > First, it looks like the implementation proposal by > Rajeev and Jari M. takes care of the case when there > is no HA at all. It aims at protecting innocent non-mobile > nodes from attacks where somebody tries to cause their > packets to be inappropriately tagget so that they get > dropped by some firewall. > > What comes to the trustworthiness of an existing HA, > I don't immediately see how it is relevant here. > As far as I can see, unauthenticated HAOs are mainly > a threat against "the others" in the internet, not > the mobile nodes or home agents. The basic threat is that > somebody sends HAOs that contain a bogus HoA, and the > basic consequences include DoS against the node at > the claimed CoA and DDoS against the network at the > claimed HoA. I fear we might not be communicating here. It's not just the DoS attack. Any IPv6 node can add any HAO they want to add. Right now, there's no ingress filtering which prevents that, and I remain pretty skeptical there will be any time soon. As such, if a "CN" accepts a HAO which hasn't had some sort of bogosity test applied (RR, CGA, etc), a random non-mobile node can launch a source-spoofing attack against a random host. As far as I can see, better Home Agent policing doesn't help that attack at all since you cannot assume that there's any HA around. Thus, if the gold standard here is "do no more harm than the non-mobile case", I think that opening up a source spoofing attack which cannot be countered by existing ingress filtering is certainly adding harm. Since it doesn't seem likely that it is fixable, it becomes permanent harm, and thus I don't see that there's any choice but to add soft state and testing somewhere (probably the CN) to meet our gold standard. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 18:01:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06846 for ; Thu, 21 Feb 2002 18:01:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29048; Thu, 21 Feb 2002 16:01:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16588; Thu, 21 Feb 2002 15:01:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LN09KL028544 for ; Thu, 21 Feb 2002 15:00:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1LN09uJ028543 for mobile-ip-dist; Thu, 21 Feb 2002 15:00:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LN07KL028536 for ; Thu, 21 Feb 2002 15:00:07 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13327 for ; Thu, 21 Feb 2002 18:00:08 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id SAA04253 for mobile-ip@sunroof.eng.sun.com; Thu, 21 Feb 2002 18:00:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1LINTKL028046 for ; Thu, 21 Feb 2002 10:23:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23251 for ; Thu, 21 Feb 2002 10:23:30 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23098 for ; Thu, 21 Feb 2002 11:23:29 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 6C56F29DD for ; Thu, 21 Feb 2002 10:23:14 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 09B6D172C for ; Thu, 21 Feb 2002 12:23:27 -0600 (CST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1LINPR20959; Thu, 21 Feb 2002 13:23:25 -0500 (EST) Received: from compaq.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id NAA0000080496; Thu, 21 Feb 2002 13:23:24 -0500 (EST) Message-ID: <3C753B1C.60FED435@compaq.com> Date: Thu, 21 Feb 2002 13:23:24 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <4DA6EA82906FD511BE2F00508BCF053802C6A9EE@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello I've been trying to catch up with the flurry of mail on this and other threads so forgive me if this was asked and answered already... From what I've see and read about MIPv6, it was never designed to cater to any specifc link layer. It made some optional privisions that would work more optimally with some link layers. So my question is why are we trying to cater to specific link layers that don't like piggibacking? Did I misunderstand something??? Thanks -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich IPv6 Project Lead Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Tel: (603) 884-1079 Nashua, NH 03062 Fax: (435) 514-6884 From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 21 23:42:47 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13495 for ; Thu, 21 Feb 2002 23:42:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13678; Thu, 21 Feb 2002 21:42:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09141; Thu, 21 Feb 2002 20:42:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M4e1KL029373 for ; Thu, 21 Feb 2002 20:40:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1M4e1EQ029372 for mobile-ip-dist; Thu, 21 Feb 2002 20:40:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M4dwKL029365 for ; Thu, 21 Feb 2002 20:39:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08675 for ; Thu, 21 Feb 2002 20:40:01 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17342 for ; Thu, 21 Feb 2002 21:40:00 -0700 (MST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1M4e0t04086; Thu, 21 Feb 2002 20:40:00 -0800 (PST) Received: from oranlt ([161.44.238.49]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACC17563; Thu, 21 Feb 2002 20:40:09 -0800 (PST) From: "David R. Oran" To: Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Thu, 21 Feb 2002 23:39:31 -0500 Organization: Cisco Systems Message-ID: <002e01c1bb5a$ec443bb0$31ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C73FCA7.7712F98B@iprg.nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of > Charlie Perkins > Sent: Wednesday, February 20, 2002 2:45 PM > To: David Oran > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > > "David R. Oran" wrote: > > > Now, if people reach consensus that piggybacking isn't > problematical > > for BUs with IPv6, then looking at alternatives like blocking is > > de-focusing. OTOH I do not see such a consensus emerging, > even after > > nearly a year of arguing. > > What do you think about my suggestion that managing resources > on tight data channels is, in essence, a QoS problem? Sure, just as jitter is a QoS problem. Are there in fact any arguments in favor of piggybacking that AREN'T QoS arguments? I have to admit that I am following this whole thing with about 2% of my brain capacity, because my day job is completely unrelated, and the signal to noise ratio on the mailing list is abysmal. So, if you want to take the trouble to educate me via a private back-channel, I'm game (although as a non-combatant in this debate you might wish to put your efforts elsewhere). What I'm struggling to understand is whether there are any CAUSAL or TEMPORAL dependencies between the BU and the data it is piggybacked with that can actually be exploited. If so, then either nobody has clearly articulated them on the mailing list, or I am losing it. If not, then you'll have to explain to me how piggybacking is more than a QoS technique to cut down on bandwidth and amortize a channel scheduling slot across two packets. > I > thought this was pretty clear; the very statement that a > particular channel needs to be reserved purely for one kind > of data stream is almost tautologically a QoS problem. I think there are in fact other motivations besides QoS for separate channels (e.g. secure demultiplexing, redundancy, quasi-related control channels like power reporting on CDMA) but I don't think any of them apply to the current debate, so let's leave this out of the discussion. > I note > in this connection, that even the most fervent proponents of > eliminating piggybacking have no solution to offer if some > other node sends a packet to the bandwidth-constrained > channel which is currently consumed with the single-sized > packet stream. An appropriate QoS solution would, on the > other hand, solve both problems neatly. > The situation you allude to is one where the bottleneck link is *not* the link emanating from the original transmitter, right? Well, in fact a smart flow-based channel scheduler would not run into difficulty with cross-traffic as long as bursts from original sources stay together (which they tend to if not explicitly broken up). So, explain why piggybacking wins here (again, I'm operating under the assumption of no causal or temporal dependency). I would think splitting the BU from the data packet would win (assuming moderate header compression efficiency) because you could mark the jitter-sensitive data with EF, while letting the BU go best effort. I *must* be missing something here since my cRTP an LFI measurements on bandwidth-constrained links all seem to confirm this. My suggestion of using packet blocking at the L3/L2 interface is simply to optimize channel scheduling. This can win even on relatively fast links, like DOCSIS uplinks. > I am optimistic that we will reach consensus soon. I really > think there is an answer that will satisfy everyone's needs. > Good luck! I wish I understood the benefits of piggybacking better, since they're just not obvious to me. Dave. > Regards, > Charlie P. > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 00:59:17 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14875 for ; Fri, 22 Feb 2002 00:59:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01082; Thu, 21 Feb 2002 22:59:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA25106; Thu, 21 Feb 2002 21:57:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M5uwKL029497 for ; Thu, 21 Feb 2002 21:56:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1M5uwHj029496 for mobile-ip-dist; Thu, 21 Feb 2002 21:56:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M5utKL029489 for ; Thu, 21 Feb 2002 21:56:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21802 for ; Thu, 21 Feb 2002 21:56:57 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA10884 for ; Thu, 21 Feb 2002 22:56:56 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA14320; Thu, 21 Feb 2002 21:56:56 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1M5utX15862; Thu, 21 Feb 2002 21:56:55 -0800 X-mProtect:  Thu, 21 Feb 2002 21:56:55 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin9.iprg.nokia.com (205.226.20.239, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtdQTqQ; Thu, 21 Feb 2002 21:56:51 PST Message-ID: <3C75DD42.11ACAAF4@iprg.nokia.com> Date: Thu, 21 Feb 2002 21:55:14 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Oran CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <002e01c1bb5a$ec443bb0$31ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Dave, Continuing... I hope you'll be able to carry this discussion a bit further. "David R. Oran" wrote: > > What do you think about my suggestion that managing resources > > on tight data channels is, in essence, a QoS problem? > Sure, just as jitter is a QoS problem. Are there in fact any arguments > in favor of piggybacking that AREN'T QoS arguments? My basic premise is that "piggybacking" is actually just another word for basic IPv6 functionality. IPv6 allows IP options to be encoded in extension headers. Binding Update is an IP option encoded in an extension header. IPv6 allows such things to have payloads. It turns out that this is a performance enhancement in general for all links that implement IPv6 MTU. > So, if you want to take the trouble to educate me via a private > back-channel, I'm game (although as a non-combatant in this debate you > might wish to put your efforts elsewhere). I wish it weren't combat in anyone's mind. > What I'm struggling to understand is whether there are any CAUSAL or > TEMPORAL dependencies between the BU and the data it is piggybacked with > that can actually be exploited. If so, then either nobody has clearly > articulated them on the mailing list, or I am losing it. If not, then > you'll have to explain to me how piggybacking is more than a QoS > technique to cut down on bandwidth and amortize a channel scheduling > slot across two packets. The payload and the IP option signaling are logically able to be separated, or otherwise people would not be arguing about it. Thus, I don't think you can find the answer there. I believe that logical processing flow indicates a reasonable win for piggybacking. But I don't think it is fair to equate all performance improvements as "QoS issues". I expect you already know this. I would rather think of QoS as a way to "reserve resources". The proponents of removing the basic IPv6 functionality of including payload with IP options/ extensions want to reserve resources without explicitly saying so, by the brute force mechanism of just saying no. This is on the assumption that they are already claiming IPv6 conformance of the underlying link. If the latter is not so, then I think the situation is even worse. > > I thought this was pretty clear; the very statement that a > > particular channel needs to be reserved purely for one kind > > of data stream is almost tautologically a QoS problem. > I think there are in fact other motivations besides QoS for separate > channels (e.g. secure demultiplexing, redundancy, quasi-related control > channels like power reporting on CDMA) but I don't think any of them > apply to the current debate, so let's leave this out of the discussion. O.K., but in the abstract my statement still holds without reference to any such layer-2 features. > > I note > > in this connection, that even the most fervent proponents of > > eliminating piggybacking have no solution to offer if some > > other node sends a packet to the bandwidth-constrained > > channel which is currently consumed with the single-sized > > packet stream. An appropriate QoS solution would, on the > > other hand, solve both problems neatly. > > > The situation you allude to is one where the bottleneck link is *not* > the link emanating from the original transmitter, right? I was thinking about the bottleneck link at the receiver. > Well, in fact a > smart flow-based channel scheduler would not run into difficulty with > cross-traffic as long as bursts from original sources stay together > (which they tend to if not explicitly broken up). This smart flow-based scheduler is then likely to perform some sort of implicit QoS by snooping the packets to make sure they deserve this preferential treatment. Otherwise, you just cannot be sure that such bursts will stay together, unless you somehow manage to avoid sending other kinds of data. The latter sounds like putting the whole IPv6 platform back on restrictions that make it resemble circuit-switched voice. Why do we want to go that direction? > So, explain why > piggybacking wins here (again, I'm operating under the assumption of no > causal or temporal dependency). I would think splitting the BU from the > data packet would win (assuming moderate header compression efficiency) > because you could mark the jitter-sensitive data with EF, while letting > the BU go best effort. I *must* be missing something here since my cRTP > an LFI measurements on bandwidth-constrained links all seem to confirm > this. Well, the way you say it here, of course I have to agree, because marking jitter-sensitive data with EF amounts to doing some sort of QoS signaling, and I have been trying to suggest that such signaling is exactly what is needed to make things work that way. Furthermore, I suggest that such signaling should, on appropriate links, cause the packet scheduler to assign the separate microflows to separate channels. Finally, it seems likely that the initial signaling (end-to-end) could cause the application to exert the appropriate controls so that Binding Updates are separated out if that is needed by the bandwidth manager on the appropriate link. This isn't absolutely necessary, though. I can imagine that the voice/control signaling packets could be fragmented across both bearer channels for even better performance. I don't see that it is very likely people would design systems that way, but they could. > My suggestion of using packet blocking at the L3/L2 interface is simply > to optimize channel scheduling. This can win even on relatively fast > links, like DOCSIS uplinks. I'm not at all against such things. I only say that we don't need to solve that problem in order to move forward. That would be a lot of work. We just have to agree not to break basic IPv6 functionality. > > I am optimistic that we will reach consensus soon. I really > > think there is an answer that will satisfy everyone's needs. > > > Good luck! I wish I understood the benefits of piggybacking better, > since they're just not obvious to me. The benefits are as previously noted: - Reduced jitter - Fewer media accesses - Natural processing (using already existing IPv6 code) - Some reduction in bandwidth utilization - Probably better compression, depending on how compression/decompression engines handle separate microflows. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 03:27:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24317 for ; Fri, 22 Feb 2002 03:27:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10573; Fri, 22 Feb 2002 01:27:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27895; Fri, 22 Feb 2002 00:27:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M8QWKL029763 for ; Fri, 22 Feb 2002 00:26:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1M8QV1o029762 for mobile-ip-dist; Fri, 22 Feb 2002 00:26:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M8QSKL029755 for ; Fri, 22 Feb 2002 00:26:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21913 for ; Fri, 22 Feb 2002 00:26:30 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26774 for ; Fri, 22 Feb 2002 00:26:29 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 68377A; Fri, 22 Feb 2002 10:28:14 +0200 (EET) Message-ID: <3C76007F.4020804@nomadiclab.com> Date: Fri, 22 Feb 2002 10:25:35 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Michael Thomas Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C6C7780.4CFAA7B4@iprg.nokia.com> <15475.61322.438392.658870@thomasm-u1.cisco.com> <3C73F519.9010603@nomadiclab.com> <15475.63367.511387.192568@thomasm-u1.cisco.com> <3C74E924.9090807@nomadiclab.com> <15477.19629.796937.947498@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, [Please include my address in to or cc if you want to have timely replies. Otherwise I'll read your reply later when I browse through the mailing lists.] I think this is an important issue to understand thoroughly, since some people really really seem to think that triangular routing is beneficial, and we are trying to find out a secure way of doing triangular routing. > .... It's > not just the DoS attack. Any IPv6 node can add > any HAO they want to add. Right now, there's no > ingress filtering which prevents that, and I > remain pretty skeptical there will be any time > soon. As such, if a "CN" accepts a HAO which > hasn't had some sort of bogosity test applied > (RR, CGA, etc), a random non-mobile node can > launch a source-spoofing attack against a > random host. So far I agree, even though I am not quite sure what you mean with the "source-spoofing attack". If you mean that the CN is under an attack since may create a socket that is bound to the claimed HoA instead of the (assumedly rpf-filtered) CoA, yes, you are right. That is the whole function of Mobile IP, to create sockets that are bound to one address and communicate with another address. If you take that path, you can argue that the whole Mobile IP is a security mistake. (If you take that position, you may tempt me to agree :-) :-) But, in this case, the CN decides (because of the HAO) that it is really communicating with the HoA instead of CoA. However, since the CN doesn't _know_ anything about the whereabouts of the HoA, it MUST reply to the HoA. From my point of view, so far so good. Somebody says that it wants to talk to me, and I reply to that somebody. I agree with you that the problem has its root in the fact that the HAO doesn't carry any topological information, i.e. it is not likely to be ingress filtered in any way. Thus, it may be completely bogus. But, if it is, the replies the CN sends will go to the bogus address. Presumedly, if there is somebody at the bogus address, that somebody is not prepared to receive those replies, and will drop them or send back an error message. I think this is the stage people came to long ago. Now, the new realization here is that the HAO can be used as a vehicle for DDoS attack, as initially noted I think by Pekka Savola and discussed several times. And the method Charlie proposed is to carry a tag in the replies the CN sends. That is, each reply that a CN sends as a result of processing a packet containing a HAO will contain a new DO (say OAH for symmetry sake) that contains the CoA from the received HAO. This has two effects. Firstly, it allows all packets that carry the OAH to be dropped by firewall if there are no HAs behind the firewall. This is fairly effective measure against the basic DDoS threat. Secondly, it allows more complex filtering in the case there is a HA, as Charlie pointed out. > As far as I can see, better > Home Agent policing doesn't help that > attack at all since you cannot assume that > there's any HA around. Not quite. The existense of the tag (the OAH option) allows you to very effectively filter out all replies that carry it. Thus, if there is no HA, you just drop all packets that carry the OAH. > Thus, if the gold standard here is "do no more > harm than the non-mobile case", I think that > opening up a source spoofing attack which > cannot be countered by existing ingress > filtering is certainly adding harm. I still don't quite see what is the source spoofing attack you are discussing about. If you are concerned about the CN, see my argument above about the whole purpose of Mobile IP. If you are concerned about the reply packets sent by the CN, with Charlie's tagging proposal they *do* carry the same information as the HOA-containing request packets sent to the CN. Thus, I see no difference there. Please feel free to continue, there may be something that I am missing. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 10:05:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04899 for ; Fri, 22 Feb 2002 10:05:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01821; Fri, 22 Feb 2002 08:05:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02083; Fri, 22 Feb 2002 07:05:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MF4eKL000125 for ; Fri, 22 Feb 2002 07:04:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1MF4eA0000124 for mobile-ip-dist; Fri, 22 Feb 2002 07:04:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MF4aKL000117 for ; Fri, 22 Feb 2002 07:04:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05683 for ; Fri, 22 Feb 2002 07:04:38 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25936 for ; Fri, 22 Feb 2002 08:04:36 -0700 (MST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1MF4Yh21130; Fri, 22 Feb 2002 07:04:34 -0800 (PST) Received: from oranlt ([161.44.238.49]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ACC23415; Fri, 22 Feb 2002 07:04:42 -0800 (PST) From: "David R. Oran" To: "'Charlie Perkins'" Cc: Subject: RE: [mobile-ip] Piggybacking - DT recommendation Date: Fri, 22 Feb 2002 10:04:02 -0500 Organization: Cisco Systems Message-ID: <00c401c1bbb2$2bb85cc0$31ee2ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C75DD42.11ACAAF4@iprg.nokia.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, February 22, 2002 12:55 AM > To: David Oran > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Piggybacking - DT recommendation > > > > Hello Dave, > > Continuing... I hope you'll be able to carry this discussion > a bit further. > OK, but you're not going to like what I have to say. Now that you've clarified your technical arguments in favor of piggybacking, I find them less persuasive than before rather than more. I didn't want to get sucked in here. AD's and WG chairs - if I'm just stirring the pot here and not helping, just send me a private note and I'll be MORE than happy to shut up. Dave. My comments are inline: > "David R. Oran" wrote: > > > > What do you think about my suggestion that managing resources on > > > tight data channels is, in essence, a QoS problem? > > Sure, just as jitter is a QoS problem. Are there in fact > any arguments > > in favor of piggybacking that AREN'T QoS arguments? > > My basic premise is that "piggybacking" is actually just > another word for basic IPv6 functionality. IPv6 allows IP > options to be encoded in extension headers. Binding Update > is an IP option encoded in an extension header. IPv6 allows > such things to have payloads. It turns out that this is a > performance enhancement in general for all links that > implement IPv6 MTU. > I believe that the BU is actually a special case, compared with other options. All the other options I know of (correct me if I'm wrong) are there to influence the processing of *the packet in which they are placed*, either by intermediate routers or the destination host (in other words, they would not be effective if sent in a different packet). The BU piggybacking does not change the handling of the packet containing the BU, but instead is a separate control signal to ask for the installation of a binding cache entry for return packets to the sending host. Said a different way, since unlike other options you CAN send the BU in a separate packet, why piggyback it? Your contention is a substantial performance win, worth making things more complicated in other dimensions (e.g. IPSEC processing). On the issue of substantial performance improvement, if you assume header compression is in place on low-bandwidth links, it is far from clear to me that "this is a performance enhancement in general for all links that implement IPv6 MTU". Perhaps you could elaborate on how it wins compared to plain header compression (apart from the channel scheduling argument, which I understand and later argue that blocking at the L3/L2 interface is equally or more effective at). > > So, if you want to take the trouble to educate me via a private > > back-channel, I'm game (although as a non-combatant in this > debate you > > might wish to put your efforts elsewhere). > > I wish it weren't combat in anyone's mind. > > > What I'm struggling to understand is whether there are any > CAUSAL or > > TEMPORAL dependencies between the BU and the data it is piggybacked > > with that can actually be exploited. If so, then either nobody has > > clearly articulated them on the mailing list, or I am losing it. If > > not, then you'll have to explain to me how piggybacking is > more than a > > QoS technique to cut down on bandwidth and amortize a channel > > scheduling slot across two packets. > > The payload and the IP option signaling are logically able to > be separated, or otherwise people would not be arguing about > it. Thus, I don't think you can find the answer there. I > believe that logical processing flow indicates a reasonable > win for piggybacking. > That's where I'm lost. What about the "logical processing flow" produces the win for piggybacking? > But I don't think it is fair to equate all performance > improvements as "QoS issues". I expect you already know > this. Well, on intermediate nodes I do think all the improvements are "QoS issues". On the source and destination hosts, I'll grant your point, but I'm still struggling to see just what those performance improvements are. Sorry to be so dense! > I would rather think of QoS as a way to "reserve > resources". Don't tell the diffserv guys that :-) > The proponents of removing the basic IPv6 > functionality of including payload with IP options/ > extensions want to reserve resources without explicitly > saying so, by the brute force mechanism of just saying no. I'm not following this part. Are you equating packet scheduling and channel scheduling with "reserving resources"? I don't. I think of reserving resources as putting them aside ahead of time and denying use to others on the speculation that traffic will arrive to use those resources. Clearly some layer 2's need to do this to minimize latency (e.g. cellular, docsis), but I don't see how this affects the question of piggybacking versus alternatives. > This is on the assumption that they are already claiming IPv6 > conformance of the underlying link. If the latter is not so, > then I think the situation is even worse. > You've lost me. Sorry. I don't see how any of this has to do with whether the link is capable of handling arbitrary IPv6 traffic, only with what the QoS tradeoffs are for various traffic patterns arriving for that link. > > > I thought this was pretty clear; the very statement that a > > > particular channel needs to be reserved purely for one > kind of data > > > stream is almost tautologically a QoS problem. > > I think there are in fact other motivations besides QoS for > separate > > channels (e.g. secure demultiplexing, redundancy, quasi-related > > control channels like power reporting on CDMA) but I don't > think any > > of them apply to the current debate, so let's leave this out of the > > discussion. > > O.K., but in the abstract my statement still holds without > reference to any such layer-2 features. > Yes, and I agree. > > > I note > > > in this connection, that even the most fervent proponents of > > > eliminating piggybacking have no solution to offer if some other > > > node sends a packet to the bandwidth-constrained channel which is > > > currently consumed with the single-sized packet stream. An > > > appropriate QoS solution would, on the other hand, solve both > > > problems neatly. > > > > > The situation you allude to is one where the bottleneck > link is *not* > > the link emanating from the original transmitter, right? > > I was thinking about the bottleneck link at the receiver. > OK, but is there anything special about the link terminating at the receiving host compared to intermediate hops? I know the first link emanating from the transmitter is special (because the packet generator has access to the link scheduing directly), but why is the receiver link different from any of the other links? Perhaps if you could explain this one I could start to see what you're getting at. > > Well, in fact a > > smart flow-based channel scheduler would not run into > difficulty with > > cross-traffic as long as bursts from original sources stay together > > (which they tend to if not explicitly broken up). > > This smart flow-based scheduler is then likely to perform > some sort of implicit QoS by snooping the packets to make > sure they deserve this preferential treatment. That's not implicit. That's explicit. The QoS treatment is explicitly encoded in the packet header by the DSCP marking in the diffserv case, and by the session flow state instantiated by RSVP in the Intserv case. Why do I get the feeling we're talking past each other here? > Otherwise, > you just cannot be sure that such bursts will stay together, > unless you somehow manage to avoid sending other kinds of > data. The latter sounds like putting the whole IPv6 platform > back on restrictions that make it resemble circuit-switched > voice. Why do we want to go that direction? > Where did you get that from what I said? Current practice in the IP world is to: (a)differentiate traffic flows either by diffserv marking or RSVP flow state, (b)schedule the links by mapping either flows or aggregates to queues, (c)maintain packet ordering within flows/aggregates. How does that equate to circuit-switching? > > So, explain why > > piggybacking wins here (again, I'm operating under the > assumption of > > no causal or temporal dependency). I would think splitting > the BU from > > the data packet would win (assuming moderate header compression > > efficiency) because you could mark the jitter-sensitive > data with EF, > > while letting the BU go best effort. I *must* be missing something > > here since my cRTP an LFI measurements on > bandwidth-constrained links > > all seem to confirm this. > > Well, the way you say it here, of course I have to agree, > because marking jitter-sensitive data with EF amounts to > doing some sort of QoS signaling, and I have been trying to > suggest that such signaling is exactly what is needed to make > things work that way. Ah, a breakthrough! :-) > Furthermore, I suggest that such > signaling should, on appropriate links, cause the packet > scheduler to assign the separate microflows to separate > channels. Finally, it seems likely that the initial > signaling (end-to-end) could cause the application to exert > the appropriate controls so that Binding Updates are > separated out if that is needed by the bandwidth manager on > the appropriate link. This isn't absolutely necessary, > though. I can imagine that the voice/control signaling > packets could be fragmented across both bearer channels for > even better performance. I don't see that it is very likely > people would design systems that way, but they could. > Gee, we already ship stuff that does this...it's called MLPPP. I think lots of folks have it. > > > My suggestion of using packet blocking at the L3/L2 interface is > > simply to optimize channel scheduling. This can win even on > relatively > > fast links, like DOCSIS uplinks. > > I'm not at all against such things. I only say that we don't > need to solve that problem in order to move forward. That > would be a lot of work. We just have to agree not to break > basic IPv6 functionality. > Why does choosing to not exploit a feature (piggybacked BU's) equate to "breaking" IPv6? > > > I am optimistic that we will reach consensus soon. I > really think > > > there is an answer that will satisfy everyone's needs. > > > > > Good luck! I wish I understood the benefits of piggybacking better, > > since they're just not obvious to me. > So, to sum up my problems with your list of benefits: > The benefits are as previously noted: > - Reduced jitter > - Fewer media accesses Both of these can be achieved in other ways, as I've noted. Blocking at the L3/L2 boundary is much more general and in fact unless you can demonstrate that there is benefit to having the BU and the packet it is piggybacked on getting the same QoS treatment, separating them with different QoS marking would seem to be a much bigger win. We have some relevant data for DOCSIS, which isn't Mobile IP packets, but may be analogous. In the DOCSIS case, media packets go with EF, but the ssociated control channel (RTCP) goes best effort. This wins big on slotted channels like DOCSIS. > - Natural processing (using already existing IPv6 code) I'd view this as neutral, since standalone BU's are equally "natural" > - Some reduction in bandwidth utilization > - Probably better compression, depending on how > compression/decompression engines handle separate > microflows. It would be interesting to acutally compute the numbers here, comparing piggybacking to IPHC on consecutive packets. > > Regards, > Charlie P. > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 11:11:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07980 for ; Fri, 22 Feb 2002 11:11:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28623; Fri, 22 Feb 2002 09:11:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15349; Fri, 22 Feb 2002 08:11:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MGAIKL000343 for ; Fri, 22 Feb 2002 08:10:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1MGAIYa000342 for mobile-ip-dist; Fri, 22 Feb 2002 08:10:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MGAFKL000335 for ; Fri, 22 Feb 2002 08:10:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16654 for ; Fri, 22 Feb 2002 08:10:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02504 for ; Fri, 22 Feb 2002 09:10:16 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA05048; Fri, 22 Feb 2002 08:10:16 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1MGAFR15382; Fri, 22 Feb 2002 08:10:15 -0800 X-mProtect:  Fri, 22 Feb 2002 08:10:15 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin21.iprg.nokia.com (205.226.20.251, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdcao03i; Fri, 22 Feb 2002 08:10:10 PST Message-ID: <3C766D01.A80859F2@iprg.nokia.com> Date: Fri, 22 Feb 2002 08:08:33 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David R. Oran" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation References: <00c401c1bbb2$2bb85cc0$31ee2ca1@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Dave, "David R. Oran" wrote: > I didn't want to get sucked in here. AD's and WG chairs - if I'm just > stirring the pot here and not helping, just send me a private note and > I'll be MORE than happy to shut up. If this happens, then I hope someone will tell me about what kinds of messages to the list are considered appropriate. I thought your messages were quite appropriate. > I believe that the BU is actually a special case, compared with other > options. All the other options I know of (correct me if I'm wrong) are > there to influence the processing of *the packet in which they are > placed*, either by intermediate routers or the destination host (in > other words, they would not be effective if sent in a different packet). You are correct that BU is different in this way from other IP options. However, all other options also have special features that make each of them unique compared to all other options. I think that BU looks for sure like an IP option, since it controls the contents of the Binding Cache. It is more effective along with the payload, because it more surely enables the "next packet" from the correspondent node to go to the right place. Putting the option into a separate packet does not give the same assurance. I don't say that sending separate packets is completely broken. I only say it's not as good, and that we already have done all the work to be able to standardize the "better" approach: specification, testing, interoperability. There is no reason to go backwards. > On the issue of substantial performance improvement, if you assume > header compression is in place on low-bandwidth links, it is far from > clear to me that "this is a performance enhancement in general for all > links that implement IPv6 MTU". Perhaps you could elaborate on how it > wins compared to plain header compression (apart from the channel > scheduling argument, which I understand and later argue that blocking at > the L3/L2 interface is equally or more effective at). If the compression profile allows optional presence of Binding Update, then this is a win compared to having separate compressed packets for payload and Binding Update packets. Of course, if the Binding Update packet is uncompressed, then the win for piggybacking is even greater, but that wouldn't be a fair comparison. However, it is worth noting that the latter is a real possibility in various implementations. > > The payload and the IP option signaling are logically able to > > be separated, or otherwise people would not be arguing about > > it. Thus, I don't think you can find the answer there. I > > believe that logical processing flow indicates a reasonable > > win for piggybacking. > > > That's where I'm lost. What about the "logical processing flow" produces > the win for piggybacking? On the receiving side, the difference is that it is more likely that the correspondent node will have the "correct" care-of address at the time it sends the "next" packet to the mobile node. On the sending side, I think there are two reasonable ways to insert the Binding Update: 1. At the same time that the mobile node sends a packet to the correspondent node. 2. In a packet which is scheduled for delivery either before or after (1). In case (1), it is very likely that it's appropriate to send the Binding Update. In case (2), it could be that the Binding Update didn't need to be sent at all. I think there is a good chance that sending the BU to all correspondent nodes in the Binding List, if it is done as soon as the new care-of address is acquired, will produce "too many" Binding Update packets. This will happen at the worst possible time -- i.e., just as a handover is completing. I reckon that other things are likely to be happening at that time, and we should avoid congesting the channel with perhaps untimely control information. To put it another way, suppose there are 10 correspondent nodes in the Binding List. Now let's have a handover. The mobile node (taking the most likely strategy) will send 10 Binding Updates as soon as it gets the new care-of address. This is in addition to some other likely signaling for fast handovers, and whatever data happens to be in progress. This would be bad. So, we can make things algorithmically more complicated, in some way that so far nobody has told me about. Or we can do the simple thing, and piggyback Binding Updates along with natural data transmission. Mandating randomized delays seems clearly wrong, so that should not be chosen as a remedy for sending out too many Binding Updates at handover time. > > But I don't think it is fair to equate all performance > > improvements as "QoS issues". I expect you already know > > this. > Well, on intermediate nodes I do think all the improvements are "QoS > issues". On the source and destination hosts, I'll grant your point, but > I'm still struggling to see just what those performance improvements > are. Sorry to be so dense! Dave, when I think of times I have discussed with you, the word "dense" does not come to mind. > > I would rather think of QoS as a way to "reserve > > resources". > Don't tell the diffserv guys that :-) Isn't diffserv a way to characterize aggregated but reservable resources? > > The proponents of removing the basic IPv6 > > functionality of including payload with IP options/ > > extensions want to reserve resources without explicitly > > saying so, by the brute force mechanism of just saying no. > I'm not following this part. Are you equating packet scheduling and > channel scheduling with "reserving resources"? I don't. I think of > reserving resources as putting them aside ahead of time and denying use > to others on the speculation that traffic will arrive to use those > resources. Clearly some layer 2's need to do this to minimize latency > (e.g. cellular, docsis), but I don't see how this affects the question > of piggybacking versus alternatives. People want to separate out the Binding Update so that it does not flow along a bearer channel that is already used up. Isn't this exactly the same as reserving that bearer channel for the specific kind of data they have in mind? It affects the question, because if this reservation were not viewed as desirable, then there would be no problem with piggybacking (given IPv6 MTU). > > This is on the assumption that they are already claiming IPv6 > > conformance of the underlying link. If the latter is not so, > > then I think the situation is even worse. > > > You've lost me. Sorry. I don't see how any of this has to do with > whether the link is capable of handling arbitrary IPv6 traffic, only > with what the QoS tradeoffs are for various traffic patterns arriving > for that link. If the link can carry IPv6 MTU, then it can carry piggybacking. Don't you agree? If there is some other reason that piggybacking is viewed as undesirable, then I understand that reason to be related to QoS, according to recent discussion. Do you not agree? If you agree on these two points, then please let me know what our next point of disagreement is and I will try to harmonize. > > > > I note > > > > in this connection, that even the most fervent proponents of > > > > eliminating piggybacking have no solution to offer if some other > > > > node sends a packet to the bandwidth-constrained channel which is > > > > currently consumed with the single-sized packet stream. An > > > > appropriate QoS solution would, on the other hand, solve both > > > > problems neatly. > > > > > > > The situation you allude to is one where the bottleneck > > link is *not* > > > the link emanating from the original transmitter, right? > > > > I was thinking about the bottleneck link at the receiver. > > > OK, but is there anything special about the link terminating at the > receiving host compared to intermediate hops? I know the first link > emanating from the transmitter is special (because the packet generator > has access to the link scheduing directly), but why is the receiver link > different from any of the other links? Perhaps if you could explain this > one I could start to see what you're getting at. You are right that there isn't NECESSARILY any difference between the intermediate links and the final link. However, the receiver's link is being viewed as bandwidth constrained and appropriate for transport of only a single size packet. I am opposed to allowing that characterization to control the protocol design, and instead I propose that such restrictions should be enforced as a result of some QoS negotiation for that purpose. > > > Well, in fact a > > > smart flow-based channel scheduler would not run into > > difficulty with > > > cross-traffic as long as bursts from original sources stay together > > > (which they tend to if not explicitly broken up). > > > > This smart flow-based scheduler is then likely to perform > > some sort of implicit QoS by snooping the packets to make > > sure they deserve this preferential treatment. > That's not implicit. That's explicit. The QoS treatment is explicitly > encoded in the packet header by the DSCP marking in the diffserv case, > and by the session flow state instantiated by RSVP in the Intserv case. > Why do I get the feeling we're talking past each other here? Because I thought you were talking about the implicit case. If you meant to have explicit QoS control over this treatment, then I already agree with you, and I suggest that the QoS negotiation should also trigger whatever the desired affects are with respect to piggybacking. > > Otherwise, > > you just cannot be sure that such bursts will stay together, > > unless you somehow manage to avoid sending other kinds of > > data. The latter sounds like putting the whole IPv6 platform > > back on restrictions that make it resemble circuit-switched > > voice. Why do we want to go that direction? > > > Where did you get that from what I said? Current practice in the IP > world is to: (a)differentiate traffic flows either by diffserv marking > or RSVP flow state, (b)schedule the links by mapping either flows or > aggregates to queues, (c)maintain packet ordering within > flows/aggregates. How does that equate to circuit-switching? Please see above for some of my confusion (explicit vs. implicit). For the rest, I claim that piggybacking Binding Update will not be any worse than sending best effort packets along with the specially-sized packets. In other words, eliminating piggybacking is basically barking up the wrong tree. > > Well, the way you say it here, of course I have to agree, > > because marking jitter-sensitive data with EF amounts to > > doing some sort of QoS signaling, and I have been trying to > > suggest that such signaling is exactly what is needed to make > > things work that way. > Ah, a breakthrough! :-) :-) > Gee, we already ship stuff that does this...it's called MLPPP. I think > lots of folks have it. That wasn't exactly what I was referring to, but it's not germane to this discussion so I'll just agree with you :-! > > I'm not at all against such things. I only say that we don't > > need to solve that problem in order to move forward. That > > would be a lot of work. We just have to agree not to break > > basic IPv6 functionality. > > > Why does choosing to not exploit a feature (piggybacked BU's) equate to > "breaking" IPv6? It is not being framed as a matter of choice. No one has intended to MANDATE that EVERYONE has to piggyback Binding Update. I have only been making this discussion so that, in systems where it is important, we COULD use this feature if we find it to be advantageous. We have shown how it might be advantageous. If you want to use Binding Update separated out from payloads, along with IPsec, then please DO that! I'll be delighted to enable that mode of operation. I only wish that others would be as generous, by the simple device of agreeing not to break this basic IPv6 functionality. > > > Good luck! I wish I understood the benefits of piggybacking better, > > > since they're just not obvious to me. > > > > So, to sum up my problems with your list of benefits: > > > The benefits are as previously noted: > > - Reduced jitter > > - Fewer media accesses > Both of these can be achieved in other ways, as I've noted. Blocking at > the L3/L2 boundary is much more general and in fact unless you can > demonstrate that there is benefit to having the BU and the packet it is > piggybacked on getting the same QoS treatment, separating them with > different QoS marking would seem to be a much bigger win. We have some > relevant data for DOCSIS, which isn't Mobile IP packets, but may be > analogous. In the DOCSIS case, media packets go with EF, but the > ssociated control channel (RTCP) goes best effort. This wins big on > slotted channels like DOCSIS. It is these slotted channels that, I assume, motivate the discussion. And, I have no problem with allowing the kind of operation you suggest. However, we do NOT have to restrict Binding Update to get this, and if there is any QoS operation at all, it should be sufficient to enable the separation of Binding Update from payload as you may need. Plus there are other handy ways to achieve the separation. But to legislate it out of existence is heavy-handed and unnecessary, and as you seem to agree, only motivated by the characteristics of particular link layers. > > - Natural processing (using already existing IPv6 code) > I'd view this as neutral, since standalone BU's are equally "natural" I hope my scenario above (with 10 possibly unnecessary Binding Updates) would change your mind. > > - Some reduction in bandwidth utilization > > - Probably better compression, depending on how > > compression/decompression engines handle separate > > microflows. > It would be interesting to acutally compute the numbers here, comparing > piggybacking to IPHC on consecutive packets. Perhaps my discussion about header compression earlier in this note will provide some useful intuition. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 14:05:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17179 for ; Fri, 22 Feb 2002 14:05:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00150; Fri, 22 Feb 2002 12:05:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15647; Fri, 22 Feb 2002 11:05:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MJ4dKL000744 for ; Fri, 22 Feb 2002 11:04:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1MJ4d9k000743 for mobile-ip-dist; Fri, 22 Feb 2002 11:04:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MJ4aKL000736 for ; Fri, 22 Feb 2002 11:04:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15280 for ; Fri, 22 Feb 2002 11:04:38 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27982 for ; Fri, 22 Feb 2002 12:04:37 -0700 (MST) Received: from chardonnay (ipunplugged.com [192.168.4.5]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id UAA01182; Fri, 22 Feb 2002 20:02:22 +0100 From: "Henrik Levkowetz" To: , Subject: [mobile-ip] draft-levkowetz-dhc-mip-fa-00.txt Date: Fri, 22 Feb 2002 20:04:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I've submitted a draft named draft-levkowetz-dhc-mip-fa-00.txt on the subject of announcing Mobile-IP Foreign Agents through a DHCP option. Until it's officially announced, it's available for your peruse at http://www.levkowetz.com/pub/id/draft-levkowetz-dhc-mip-fa-00.txt It is a tiny draft, not too onerous to read. I would appreciate feedback. Best regards, Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ Natural laws have no pity. From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 15:45:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22948 for ; Fri, 22 Feb 2002 15:45:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04153; Fri, 22 Feb 2002 13:45:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19395; Fri, 22 Feb 2002 12:44:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MKdWKL001054 for ; Fri, 22 Feb 2002 12:39:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1MKdV00001053 for mobile-ip-dist; Fri, 22 Feb 2002 12:39:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MKdSKL001046 for ; Fri, 22 Feb 2002 12:39:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16137 for ; Fri, 22 Feb 2002 12:39:31 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25087 for ; Fri, 22 Feb 2002 12:39:31 -0800 (PST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1MKfUQ04936 for ; Fri, 22 Feb 2002 14:41:30 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 22 Feb 2002 14:39:30 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Feb 2002 14:39:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] MIPv6 Issues (Update on issues Closed and Open) Date: Fri, 22 Feb 2002 14:39:30 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A127E0@daebe007.NOE.Nokia.com> Thread-Topic: MIPv6 Issues (Update on issues Closed and Open) Thread-Index: AcG725tmZnkkJiefEdaxoQAAhj/HZA== To: X-OriginalArrivalTime: 22 Feb 2002 20:39:30.0515 (UTC) FILETIME=[07278230:01C1BBE1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1MKdTKL001047 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, Just to provide an update on issues that are closed and the ones that are open at this time w.r.t Mobile IPv6 Closed ====== 1: New RH Type (2) or a new DO to carry the HoA towards the mobile node Consensus: New RH Type 2: Mechanism for securing BUs Consensus: Return Routability based test as the baseline mechanism in the MIPv6 specification for verifying the home address ownership claim. Caveat: However if there are mechanisms more secure than RR are available (e.g. RR+CGA, AAA based, PKI etc.) they could be used to secure the BUs. If mechanisms more secure than RR are available, there needs to be a mechanism that indicates to a CN: a. Do RR b. Do NOT do RR The current proposal is to reserve a bit in the interface part of the IPv6 address which would indicate this preference. However discussion is still in progress and this item needs to be approved by the WG soon. The DT will be sending an analysis of the bit approach shortly. Open ==== 1. Piggybacking The DT will be sending an analysis of the IPsec interaction issues w.r.t piggybacking (as a followup to the earlier note) in addition to making a recommendation. WG consensus on the DT recommendation will be sought in order to reach closure. 2. Home Address destination option processing Discussion in progress. DT evaluating proposals that have come up on the mailing list. 3. The bit mechanism to turn on/off RR See above. -Chairs From owner-mobile-ip@sunroof.eng.sun.com Fri Feb 22 16:18:45 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25754 for ; Fri, 22 Feb 2002 16:18:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28866; Fri, 22 Feb 2002 14:18:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02288; Fri, 22 Feb 2002 13:18:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MLGuKL001171 for ; Fri, 22 Feb 2002 13:16:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1MLGuSD001170 for mobile-ip-dist; Fri, 22 Feb 2002 13:16:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1MLGrKL001163 for ; Fri, 22 Feb 2002 13:16:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27360 for ; Fri, 22 Feb 2002 13:16:56 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28135 for ; Fri, 22 Feb 2002 14:16:55 -0700 (MST) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id <1LTW8S14>; Fri, 22 Feb 2002 16:16:54 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460A3F9B@ftmail> From: "Alan O'Neill" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] draft-oneill-mip-revtun-ho-00 Date: Fri, 22 Feb 2002 16:16:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Just to let you know I have just submitted a draft suggesting some simple mods to HAs and inter-FA BUs to better support the 'lossless' hand-off of reverse tunneled traffic. They are especially useful when the FA-HA RTT is very much greater than the inter-FA RTT, and when the new FA to HA path is much shorter than the old FA to HA path. The changes are to enable the HA to support both the old and new CoA (fan-in binding) during the hand-off, and to optionally enable the reverse tunneling to use the oFA and the oCoA binding in the HA whilst waiting for the MIP Reply confirming the nCoA binding. Comments appreciated...Alan. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 25 12:25:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19730 for ; Mon, 25 Feb 2002 12:25:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29864; Mon, 25 Feb 2002 10:24:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00246; Mon, 25 Feb 2002 09:24:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PHNiKL004754 for ; Mon, 25 Feb 2002 09:23:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PHNifL004753 for mobile-ip-dist; Mon, 25 Feb 2002 09:23:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PHNeKL004746 for ; Mon, 25 Feb 2002 09:23:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15561 for ; Mon, 25 Feb 2002 09:23:43 -0800 (PST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA04595 for ; Mon, 25 Feb 2002 09:23:42 -0800 (PST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Feb 25 12:17:55 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g1PHNTt04099 for ; Mon, 25 Feb 2002 12:23:29 -0500 (EST) Received: from dnrc.bell-labs.com (blhogirishcpc [135.180.240.34]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA14950; Mon, 25 Feb 2002 12:23:26 -0500 (EST) Message-ID: <3C7A731E.8050507@dnrc.bell-labs.com> Date: Mon, 25 Feb 2002 12:23:42 -0500 From: Girish Chandranmenon User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] possible race condition in MIP? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi! Perhaps this situation had been discussed here before, but I couldn't find it in the archives. If it had been discussed before, please direct me to the correct articles(s). It seems possible for a mobile node to get cut off from the network because of the misordering of registration requests at the home agent. Here is the scenario: Consider a mobile node with two interfaces, 1 & 2; and corresponding FAs FA1 and FA2. 1. intf 1 gets connected, and MN sends solicitation on intf 1, receives advt, sends registration request (RQ1) towards FA1. After that intf1 gets disconnected. 2. intf 2 gets connected, and MN sends solicitation on intf 2, receives advt, sends registration request (RQ2) towards FA2. 3. RQ1 is delayed at FA1 or along the path to HA, and RQ2 reaches the HA first. 4. HA registers the MN, and replies with the message RPLY2. 5. MN receives RPLY2 and is happy with that since that is the reply for the latest request it sent out. Now MN believes that it is successfully registered with FA2, on interface 2. 6. RQ1 reaches HA, and HA registers the mobile again; this time with FA1. Since HA cannot determine the order of origination of request messages (unless we use time stamp based replay protection). HA replies with RPLY1, and it never reaches MN. (even if it reaches MN, it will reject that reply, since it was for an earlier request). As a result, the traffic towards MN will be sent towards FA1, which cannot reach MN, since the interface 1 is disconnected. MN thinks it is successfully registered at FA2. The spec talks about this possibility in the timestamp based replay protection. but this is very much possible for the other choices of replay protection as well. Any thoughts on how this can be avoided? [We cannot use a monotonically increasing sequence number in the ID field. If we do that, we need to have additional mechanisms to remember the last used sequence # before a reboot, and we have to worry about wrapping sequence #s. etc..] Thanks, Girish. From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 25 13:28:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23330 for ; Mon, 25 Feb 2002 13:28:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04758; Mon, 25 Feb 2002 11:28:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22460; Mon, 25 Feb 2002 10:27:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PIR1KL004960 for ; Mon, 25 Feb 2002 10:27:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PIR1TJ004959 for mobile-ip-dist; Mon, 25 Feb 2002 10:27:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PIQsKL004943; Mon, 25 Feb 2002 10:26:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22107; Mon, 25 Feb 2002 10:26:55 -0800 (PST) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13227; Mon, 25 Feb 2002 11:26:54 -0700 (MST) Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.51 2002/02/19 21:12:32 root Exp $) with SMTP id SAA18547; Mon, 25 Feb 2002 18:26:53 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002022510260108109 ; Mon, 25 Feb 2002 10:26:01 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id <19D3K8KP>; Mon, 25 Feb 2002 10:26:53 -0800 Message-ID: From: "Liu, Changwen" To: mobile-ip@sunroof.eng.sun.com, "'ngtrans@sunroof.eng.sun.com'" Subject: [mobile-ip] Draft on running MIPv6 over MIPv4 Date: Mon, 25 Feb 2002 10:26:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: To all, I've submitted a draft named "Mobile IPv6 over Mobile IPv4". The draft specifies a mechanism for Mobile IPv6 nodes of a 6to4 site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. The draft is intended for Mobile IP WG initially, and is applicable to issues addressed by NGTrans WG. The draft can be retrieved from http://www.ietf.org/internet-drafts/draft-liu-mobileip-mipv6overmipv4-00.txt I would appreciate your feedbacks and comments on the draft. Thanks in advance. Regards, changwen From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 25 17:45:28 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02713 for ; Mon, 25 Feb 2002 17:45:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00466; Mon, 25 Feb 2002 14:45:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02240; Mon, 25 Feb 2002 14:44:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMiEKL005562 for ; Mon, 25 Feb 2002 14:44:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMiDoi005561 for mobile-ip-dist; Mon, 25 Feb 2002 14:44:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMi9KL005554 for ; Mon, 25 Feb 2002 14:44:10 -0800 (PST) Received: from lillen (vpn-129-159-0-37.EMEA.Sun.COM [129.159.0.37]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1PMi7x05543; Mon, 25 Feb 2002 23:44:07 +0100 (MET) Date: Mon, 25 Feb 2002 23:39:24 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: rajeev@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C73EB3D.B264177E@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev, I'm trying to understand the tag-or-not.txt and I see terms that I don't understand and that I think are important for better understanding. "actively communicating" Is this a statement about - some minimum number of packets send and/or received per time unit? - a statement about there being connections/session at a higher protocol layer? - something else? "creating a fresh destination cache entry" Does this apply independently of the history i.e. what if the destination cache entry was deleted 1 microsecond earlier due to some garbage collection even on the node? "GN _initiates_ packets to CN" I don't know what it means to initiate packets. Did you mean "sends packets" or "initiates connections"? Also, what is the intended behavior when a unverified HAO arrives for a new HoA and there is no room for creating more cache entries that track the tag/no tag bit for a peer? Thanks, Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 25 17:57:17 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03049 for ; Mon, 25 Feb 2002 17:57:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15879; Mon, 25 Feb 2002 15:57:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06796; Mon, 25 Feb 2002 14:56:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMtlKL005650 for ; Mon, 25 Feb 2002 14:55:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMtlA2005649 for mobile-ip-dist; Mon, 25 Feb 2002 14:55:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMtiKL005642 for ; Mon, 25 Feb 2002 14:55:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02901 for ; Mon, 25 Feb 2002 14:55:45 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23008 for ; Mon, 25 Feb 2002 15:55:44 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 48EAF6A905 for ; Tue, 26 Feb 2002 00:55:40 +0200 (EET) Message-ID: <3C7AC137.8020309@piuha.net> Date: Tue, 26 Feb 2002 00:56:55 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Design team note: bidding down attacks Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's a note relating to the RR vs. stronger mechanism selection. On the list we have previously discussed bidding down attacks against this selection, and the purpose of this note is to describe those attacks. This may help the discussion of methods for mechanism selection. A second note relating to bidding down attacks will soon be posted as well. That note deals with the methods of protecting the selection. 1. INTRODUCTION The Mobile IP Working Group has been discussing if it could allow a single, mandatory Binding Update (BU) authorization scheme to be complemented with an optional scheme with a higher strength. If several schemes are allowed in this manner, it becomes necessary to select a scheme in some manner. The question is whether such selection methods are secure, since if the optional scheme can be turned off by attackers the resulting security will be that of the mandatory mechanism. An earlier Design Team note [1] briefly described the above issue but didn't go to the details of the possible attacks. In view of the recent active discussions on possible secure scheme selection protocols this was inadequate. The purpose of this note is to describe the so called Bidding Down problem in the selection method. Our purpose is to show a few concrete examples on how the attacker can downgrade the security to the lowest (mandatory) level even if communicating peers supported a stronger method. 2. BASIC ATTACK Figure 1 shows the network scenario for the most basic form of a bidding down attack. The starting point of any attack must be that RR can be defeated, otherwise there would be no benefit to the attacker. In order to defeat RR, the attacker must find himself on the path between the CN and the HA, or perhaps in one of the LANs where these nodes are located. (MN) <----> HA <----> Attacker <----> CN Figure 1. Network scenario. For the basic attack, it does not matter at all where the MN is. For the attack to be interesting, we have to assume the MN wishes to use something else than RR as its BU authorization method. For the purposes of this example, we can assume this method is a yet to be discovered new signaling scheme. The attack starts in Step 1 by the attacker sending a fake request to the CN, indicating in the desire to use RR in the request. The CN, not having any knowledge of the true desires of the MN accepts this. Step 1. Attacker sends first message(s) of BU authorization to CN, indicating that RR is desired. In the case of currently planned RR protocol [2] this would mean sending the 1a and 1b messages. In this network scenario both messages can be sent from the attacker's location towards the CN. This is because the attacker can choose the CoA so the attacker is on the path between the CN and the CoA. This can be done easily e.g. by selecting an address from the network where the attacker is. Step 2. CN inspects the messages and continues the RR protocol, by responding to the message(s). According to the current understanding these would be 2a and 2b. Step 3. Attacker receives the responses and proceeds to continue with the RR protocol. In the current protocol, this would be message 3, the actual BU. Typically, the attacker is also able to prevent the responses from reaching the MN (see section 3). As a result, the attacker has established a BCE with the CN, using RR and regardless of the desire of the MN to engage in any Route Optimization or RR-based authorization. 3. DISCUSSION Note that the bidding down attack does not have to take place between CNs and MNs that are communicating at that moment. In fact, it's easier for the attacker to just pretend to be the MN that requests Route Optimization, than try to hijack a real request for Route Optimization. Unless CNs store information regarding previous security preferences of MNs, the existence of previous or current BCEs does not matter for the attacker either, as the attack looks like the MN had moved. The described bidding down attack depends heavily on the infrastructureless approach selected for the BU authorization protocols. Because of this approach, there isn't necessarily any knowledge of the peers or their security preferences prior the first BU authorization requests coming in. Section 2 assumed that the attacker has the capability to receive and inject IP packets somewhere on the path. We did not assume the attacker would be able to block the flow of the response packets to the HA/MN. Let's study the effects such packets may have: - If the MN happens to be a stationary and not a mobile node, it may not implement the processing of the MN messages, and hence may not be aware of any messages being sent to it. - If the attacker blocks the CN's packets from reaching the MN, the MN becomes unaware of any attack being in progress. Can the attacker block the packets? It seems possible given that most attacks on the links or on the path would be based on spoofing Neighbour or Router Discovery. It has also been reported that TCP sequence number attacks have succesfully used temporary flooding of the nodes and links in order to hide the hijack attempt. - In any case, given the position of the attacker, it is likely that he will see the responses of the CN sooner, and is also able to respond to the CN earlier. Therefore the CN accepts the attacker's BCE first. - Also, if the MN would respond to a message in the middle of the RR protocol without having initiated the protocol by itself, there may be possibilities for the MN to warn the CN of a possible security breach, or to try re-establish a correct BCE at the CN. However, the DoS aspects of this change to the RR protocols should be analyzed carefully. 4. CONCLUSIONS RR leaves one residual threat open (the future attack [1]) when compared to the baseline case i.e. IPv6 without mobility. Sites that do not host any HAs should be able to protect themslves by disallowing RR on the addresses used by these sites. Therefore, it seems desirable to set up a mechanism that allows the CNs easily check whether a given MN is willing to use RR or not. In infrastructureless BU authorization methods, the CNs and MNs do not have more information available to them about the preferences of their peers than what can be deduced from the BU signaling, i.e. the relevant addresses, the contents of the BUs and the authorization messages, the properties ensured through return routability tests, and possibly previous knowledge of the peers' preferences if they have contacted each other previously. It does not appear that we can trust the real MN to react messages relating to the attack under most circumstances. There are two specific cases where bidding down attacks are troublesome in particular. The first case is that of a stationary node, which may not wish to be involved in mobility at all, and which would benefit from the ability to say 'no thanks' in a secure manner. The second case is that there have recently been discussions on improving IPv6 control signaling security. While any improvements are currently only speculation, it is conceivable that Neighbour Discovery security could be improved. Currently, RR does not make current (quite low) on-link security much worse. However, this could change as a result of improvements in ND security, and as a result RR might be left as the weaker link. In order to be able to handle this in future, there'd have to be a way start moving towards more secure BU authorization mechanisms at the same time as ND is improved. However, this is very hard if attackers can claim that the nodes in question are older and only support RR. It is necessary to study the possible remedies to bidding down attacks further. The discussion subject should include at least: - Allocation of bits in interface identifiers to signify security preferences. - Ability to choose multiple stronger methods, and not have the selection mechanism tied to a particular strong method. - Possibility of making RR nodes 'prove' their right to do RR in some manner, and therefore protecting stationary nodes. - Whether security preferences from previous BCE establishment can be used in guarding against attacks. It is necessary to convince ourselves that there are no additional DoS concerns, however, in these schemes. As an example, an attacker with a DSL connection could fill an embedded device memory of 100KB in 10 s, assuming 1 KB messaging per BU and 16 B per address. A CNN web server with 16 GB disk dedicated for this would fill up in 12 days. There must also be ways to avoid problems when the same address (e.g. in dial-up) is reused for other devices after a particular connection is finished. It should also be studied what the effect of this mechanism is when MNs do not always immediately run RO with their CNs. Thus, there appears to be many concerns around this approach. - Whether we can make use of the ability of MNs to "notice" an attack is going on through a message leaked from the attacker to the HA/MN. (This may not matter, however, as it can be argued that attackers that can spoof RR can also typically prevent leaked packets.) 5. REFERENCES [1] http://www.piuha.net/~jarkko/publications/mipv6/Residual_threats.txt [2] http://www.piuha.net/~jarkko/publications/mipv6/RRCGA_Mail.txt From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 25 17:57:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03067 for ; Mon, 25 Feb 2002 17:57:43 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23773; Mon, 25 Feb 2002 15:57:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06885; Mon, 25 Feb 2002 14:57:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMu6KL005660 for ; Mon, 25 Feb 2002 14:56:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1PMu6UC005659 for mobile-ip-dist; Mon, 25 Feb 2002 14:56:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1PMu2KL005652 for ; Mon, 25 Feb 2002 14:56:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27077 for ; Mon, 25 Feb 2002 14:56:03 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23099 for ; Mon, 25 Feb 2002 15:55:58 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 66FAB6A905 for ; Tue, 26 Feb 2002 00:55:57 +0200 (EET) Message-ID: <3C7AC148.7090806@piuha.net> Date: Tue, 26 Feb 2002 00:57:12 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Design team recommendation: New recommendation on piggybacking Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1. INTRODUCTION This is a new piggybacking note from the design team that takes into account some recent discussion on the mailing list. In the discussion a proposal has been made that piggybacking could be used unless IPsec policies demand processing the Binding Updates and payload packets in a different way. This note specifies the design team's motivation and current position. In order to move forward in an efficient manner it would be beneficial if responses could make it clear they are - a clarification (by putting CLARIFICATION: in the Subject field) - an issue with a particular point (by ISSUE:) - disagreement with the conclusion (by CONCLUSION:) We would also like folks to state for each of our three separate recommendations whether they AGREE, CAN TOLERATE, or DISAGREE with them. In case of DISAGREE, please explain why. 2. DISCUSSION It is perhaps useful to discuss the MIPv6 signaling as a whole and see where piggybacking can and cannot be applied. Table 1 shows the Binding Request (BR), all RR messages (1a, 1b, 2a, 2b) and the subsequent Binding Update to the CN (RR/BU and RR/BA), as well as the BU sent to the HA (HA BU/BA). Message Sndr Rcvr ViaHA AddIPscOK RepIPscOK HAprot Pig BR CN MN No Yes Yes No Yes RR 1a MN CN Yes Yes - No Yes* RR 1b MN CN No Yes - No Yes* RR 2a CN MN Yes Yes - Yes No RR 2b CN MN No Yes - No No RR 3/BU MN CN No Yes Yes No Yes RR 4/BA CN MN No Yes Yes No Yes HA BU MN HA - - - Yes No HA BA HA MN - - - Yes No Table 1: Analysis of MIPv6 control messages The columns in the table have the following meanings: - Sndr is the sender of the message. - Rcvr is the receiver of the message. - ViaHA is Yes if this particular message is routed through the HA. In this case the HA is neither the original sender or final receiver of the message. - AddIpscOk means that additional IPsec on top of the regular RR procedures would be useful but not mandatory for this message. - RepIPscOk means that IPsec would be useful as an alternative to the RR procedures for this message. (Typically, this would mean that some address ownership authorization procedures would have to be employed, such as providing the IPv6 addresses in SubjAltName of X.509 certificates. It is not clear if this can or should be assumed, but the subject is not discussed here and for the purposes of this note we just assume that it would be possible, and can be assured via an API to the MIPv6 stack.) - HAprot means that the HA should encrypt/decrypt at least this message when a message is routed through it, for added RR security. - Pig means that piggybacking is useful and security-wise possible. A '*' after a Yes value indicates that piggybacking would be sometimes possible. Generally speaking, piggybacking isn't possible in the messages with ViaHA=Yes, since the BUs and the payload have different source/destination addresses (the HA and the MN vs. a CN and the MN). RR messages 1a and 1b can be piggybacked only if a BCE entry exists already, if HAO reflection needs to be prevented as suggested in [2]. Another reason for a conditional use of piggybacking in this case is that as we will see later, we do not necessarily know during 1a/1b that piggybacking is allowed by the receiver. RR message 2a can't be used for piggybacking at this stage. Given the ease with which an HA could be supplanted by a rogue HA, the MN's HA is still unverified and we do not wish to allow attackers to be able to steal even a single packet to themselves (in this case a rogue HA). RR message 2b can't be used for piggybacking at this stage as the CoA is still unverified, and we do not wish to allow attackers to be able to steal even a single packet to themselves. Main conclusions from this table are the following: 1) In HAprot, the packets are forwarded by the HA into a tunnel to the MN and the HA needs to be able to determine whether or not to apply IPsec using the IPsec selectors [3]. One HAprot=Yes in the upper four messages means that we must use for RR something that is a protocol or a port number. 2) RepIPsecOK=Yes for all the BU/BA messages means that they too should be protocols or ports. This might go away for RR/BU and BA if we didn't need the replacement ipsec functionality, but not for HA BU/BA. 3) Existence of RepIPsecOk=Yes anywhere means we must know in the implementation of MIPv6 what the IPsec policies are. This means either extensions to IPsec policy mechanisms in typical implementations, or MIPv6 accessing them through an API inside the kernel. No such standardized API exists today, and not all products have this feature. Some do, however. 4) If we want same format for all BUs and BAs to the CNs and HAs, Pig=Yes and Pig=No means that the same format must be capable of both allowing and not allowing piggybacking. This seems to be possible if before considering piggybacking, the sender checks that both the data and the signaling parts are without IPsec policy rules. This check has to be done by the MIPv6 code, as the IPsec layers on both ends can't consider a protocol to be both final and non-final. 5) There seems to be many special conditions regarding piggybacking RR messages. It may make sense to consider piggybacking only BU and BA messages (but on the other hand this reduces the overall benefits of piggybacking). In conclusion, a possible approach to implement MIPv6 in a way that allows both piggybacking and separate packets is as follows: - RR messages 1a/2a have a bit to indicate whether or not the sender of the packet is willing to accept piggybacking BR/BU/BA packets. - RR and BR/BU/BA is implemented using a separate IP protocol type value. - The BR/BU/BA packets can contain an optional payload when the receiver has indicated in 1a/2a that it is willing to receive such packets. Piggybacking can only take place after the 1a/2a messages have been exchanged (at least once). - Piggybacking is not allowed when the BR/BU/BA protocol has a non-cleartext IPsec policy or when the potential payload to piggyback with the signaling has a non-cleartext IPsec policy. - The receiver of a piggybacked packet must verify both the B* part and the payload part against the IPsec policy. If either one of them should not be allowed in the clear then the whole message must be dropped. This scheme, however, adds some requirements to MIPv6 compliant nodes. In particular, in order for the MIPv6 code to know whether it can piggyback a BU, it would have to ask the IPsec code whether there are any rules that would match the BU or the data packet and give some other value that Pass. This adds a requirement for a new API within the IP stack and may not be possible unless the IPsec implementation has this API or can be changed. A crucial observation is, however, that the scheme presented above allows peers to decide whether they want to receive piggybacked traffic or not and this decision does not consume any additional message roundtrips. Hence there does not seem to be any reason to not allow piggybacking for those nodes that are willing to take on the requirements for it. It seems unnecessary though to require this from every node. The ability of the receivers to have a say in whether they want to have piggybacked signaling also satisfies concerns raised by Hesham Soliman and others on piggybacking implications under hard QoS and channel allocations. In particular, since not all QoS allocation schemes work end-to-end, a preference expressed by the peer appears to be the only way to ensure that the QoS requirements from both peers are taken into account in the piggybacking decision. 3. RECOMMENDATIONS The design team recommends the following: R1. A Separate protocol and/or port should be used for the BR message, all RR messages, BU message and BA message. This will allow - but not mandate - the use of current IPsec selectors in protecting BUs to the CN and HA, and RR messages via the HA. The value of next protocol = none must be supported by all MIPv6 compliant nodes in these messages. R2. Reserve some space for preference bits in the RR messages 1a and 1b, to allow the CN and the MN to describe their preferences. Only the space is reserved, but no meaning is assigned to the bits. The potential use of those bits is to allow a CN, for instance, tell the MN that it allows the reception of piggybacked signaling. However, compliant nodes can leave all the bits as zero. This is necessary in order to allow implementations that do not have the API between MIPv6 and IPsec. There is also other potential use of the bits, e.g. selecting some variants of stronger BU authorization methods, but these are not discussed here. R3. The above two recommendations should be placed in the MIPv6 RFC. This would allow us to quickly proceed to RFC status by bypassing controversial content, have as simple RFC and implementations as possible, but still allow functionality like piggybacking to be specified without interoperability concerns, and used by all nodes who support it. R4. Separate RFCs would define the use of these bits. For example, their use in piggybacking would need to define the following: - Allocate a bit in the reserved space in the RR messages 1a/2a, and describe its semantics. - Describe in detail which messages can use piggybacking, if it is allowed, and under which conditions. - Rules for sending the optional payload along. - Rules for receiving the optional payload. - Rules on what to check from the IPsec policy before deciding to use piggybacking. We recommend that such as an RFC for piggybacking be produced immediately. This RFC could be progressed independently from the main MIPv6 RFC, and the completion of the work on the above rules would not be a requirement for the main RFC to be published. Given that the specification of what the rules are and what to expect from the API could take some time if done carefully, this seems to imply that this part is best handled in a separate RFC. (Similarly for other uses of these bits. Any such future specifications would need to also consider any potential interactions between different uses of these bits. For example, conceivably, other faster BU authentication schemes may themselves have implications with respect to piggybacking.) R5. At a future time, IF IPsec selectors can be extended in some manner, the RFC described under R4 could be updated to extend the rules under which piggybacking is possible i.e. no IPsec checks would be necessary any more. 4. REFERENCES [1] http://www.piuha.net/~jarkko/publications/mipv6/Piggybacking.txt [2] http://www.piuha.net/~jarkko/publications/mipv6/HAO_Reflection.txt [3] http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt From owner-mobile-ip@sunroof.eng.sun.com Mon Feb 25 20:41:23 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05760 for ; Mon, 25 Feb 2002 20:41:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20240; Mon, 25 Feb 2002 18:41:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17222; Mon, 25 Feb 2002 17:41:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q1e9KL006019 for ; Mon, 25 Feb 2002 17:40:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1Q1e9Jt006018 for mobile-ip-dist; Mon, 25 Feb 2002 17:40:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q1e6KL006011 for ; Mon, 25 Feb 2002 17:40:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21687; Mon, 25 Feb 2002 17:40:09 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16549; Mon, 25 Feb 2002 17:40:09 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA26371; Mon, 25 Feb 2002 17:40:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1Q1e8M28386; Mon, 25 Feb 2002 17:40:08 -0800 X-mProtect:  Mon, 25 Feb 2002 17:40:08 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdM4Xa8t; Mon, 25 Feb 2002 17:40:04 PST Message-ID: <3C7AE774.AE3412F1@iprg.nokia.com> Date: Mon, 25 Feb 2002 17:40:04 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, thank you for reading the document. Erik Nordmark wrote: > Rajeev, > > I'm trying to understand the tag-or-not.txt and I see terms that I > don't understand and that I think are important for better understanding. > > "actively communicating" > Is this a statement about > - some minimum number of packets send and/or received per time unit? > - a statement about there being connections/session at a higher protocol > layer? > - something else? > I meant packets have been received recently (from the Generic Node without HAO). > > "creating a fresh destination cache entry" > Does this apply independently of the history i.e. what if the > destination cache entry was deleted 1 microsecond earlier due to > some garbage collection even on the node? An implementation must preserve the active working set of entries in its destination cache when doing garbage collection..If the entry was deleted because of lifetime expiration, then the new entry will require tagging. > > "GN _initiates_ packets to CN" > I don't know what it means to initiate packets. > Did you mean "sends packets" or "initiates connections"? > sends packets. > > Also, what is the intended behavior when a unverified HAO arrives for > a new HoA and there is no room for creating more cache entries that > track the tag/no tag bit for a peer? Good point. When an unverified HAO arrives and there is no room in the unverified BC, the CN drops the packet. In addition (to what we described in the document), it should send a Binding Request indicating that the MN should use either RO or BDT (depending on what CN implements). Regards, -Rajeev > > > Thanks, > Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 01:48:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11586 for ; Tue, 26 Feb 2002 01:48:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12934; Mon, 25 Feb 2002 23:47:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA06288; Mon, 25 Feb 2002 22:47:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q6kvKL006296 for ; Mon, 25 Feb 2002 22:46:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1Q6kvCW006295 for mobile-ip-dist; Mon, 25 Feb 2002 22:46:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q6ksKL006288 for ; Mon, 25 Feb 2002 22:46:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA05464 for ; Mon, 25 Feb 2002 22:46:56 -0800 (PST) Received: from lark.cc.ku.edu (lark.cc.ku.edu [129.237.34.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA22229 for ; Mon, 25 Feb 2002 23:46:54 -0700 (MST) Received: from webmail.ku.edu by lark.cc.ku.edu (8.8.8/1.1.8.2/12Jan95-0207PM) id AAA0000020536; Tue, 26 Feb 2002 00:46:53 -0600 (CST) X-WebMail-UserID: pradeep@mail.ukans.edu Date: Tue, 26 Feb 2002 00:46:53 -0600 From: pradeep To: mobile-ip@sunroof.eng.sun.com X-EXP32-SerialNo: 00002424 Subject: [mobile-ip] MIP NAT Traversal (draft-ietf-mobileip-nat-traversal-00.txt) Message-ID: <3C83CF84@webmail.ku.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.62 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I am working on implementation of NAT Traversal for MIP (draft-ietf-mobileip-nat-traversal-00.txt) over Linux. I will be very glad, if you could clarify the following question: In section 4.6 of the above mentioned draft, it's been stated as follows: "The home agent MUST use a mismatch between source IP address and care-of address in the Mobile IP Registration Request message as the indication that a mobile node may reside behind a NAT." What will be the source IP address value in the IP header of the registration request message sent by the mobile node, while it has moved to a foreign network and using a co-located care of address? In RFC 3220, section 3.6.1 it is stated that, IP Source Address: - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. - Otherwise, if the mobile node does not have a home address, the IP source address MUST be 0.0.0.0. - In all other circumstances, the IP source address MUST be the mobile node's home address. This means, when a moible node using co-located care of address wants to directly register with the home agent, the source IP address in the IP header of the registration request will be mobile node's home addres. 1) How exactly the NAT in foreign network will handle this registration request packet as the packet's source addreess is set to mobile node's home address, which is not known to the NAT? (if the source or destination address is not recognized by the NAT, it will not make any changes to the packet's source and destination address in the header). 2)How the mobile node's home agent, will come to know the foreign networks' NAT address? 3)How the mobile node's home agent, will know that the registration request packet has passed through the NAT in foreign network? Thanking You, Pradeep Natarajan. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 02:17:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19791 for ; Tue, 26 Feb 2002 02:16:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21394; Tue, 26 Feb 2002 00:16:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09391; Mon, 25 Feb 2002 23:16:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q7FkKL006359 for ; Mon, 25 Feb 2002 23:15:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1Q7Fklr006358 for mobile-ip-dist; Mon, 25 Feb 2002 23:15:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q7FgKL006351 for ; Mon, 25 Feb 2002 23:15:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09306 for ; Mon, 25 Feb 2002 23:15:44 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19854 for ; Tue, 26 Feb 2002 00:15:43 -0700 (MST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id IAA23897 for ; Tue, 26 Feb 2002 08:13:22 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] MIP NAT Traversal (draft-ietf-mobileip-nat-traversal-00.txt) Date: Tue, 26 Feb 2002 08:15:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C83CF84@webmail.ku.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Pradeep, I just got this exact question from Karthikeyan Nathillvar, and here's my reply: > > Hi, > > I am working on implementation of NAT Traversal for MIP > (draft-ietf-mobileip-nat-traversal-00.txt) over Linux. I will be very > glad, if you could clarify the following question: Oh, cool! > In section 4.6 of the above mentioned draft, it's been stated as follows: > "The home agent MUST use a mismatch between source IP address and > care-of address in the Mobile IP Registration Request message as the > indication that a mobile node may reside behind a NAT." > > What will be the source IP address value in the IP header of the > registration request message sent by the mobile node, while it has moved > to a foreign network and using a co-located care of address? > > In RFC 3220, section 3.6.1 it is stated that, > > IP Source Address: > - When registering on a foreign network with a co-located care-of > address, the IP source address MUST be the care-of address. > - Otherwise, if the mobile node does not have a home address, the > IP source address MUST be 0.0.0.0. > - In all other circumstances, the IP source address MUST be the > mobile node's home address. > > This means, when a moible node using co-located care of address wants > to directly register with the home agent, the source IP address in the IP > header of the registration request will be mobile node's home addres. Mmm, I think that if you read the first bullet in the quote from RFC 3220 again, you'll find that when a when a mobile node using a co-located care of address wants to register with the home agent from a foreign network, the IP source address MUST be the care-of address. However, if the mobile node is not in a foreign network (i.e. is at home) or is not using a co-located care-of address (i.e. is at home or is using an FA care-of address), the next 2 bullets hold. Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 04:31:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21528 for ; Tue, 26 Feb 2002 04:31:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15688; Tue, 26 Feb 2002 02:31:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20075; Tue, 26 Feb 2002 01:31:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q9UbKL006541 for ; Tue, 26 Feb 2002 01:30:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1Q9UbHR006540 for mobile-ip-dist; Tue, 26 Feb 2002 01:30:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1Q9UWKL006533 for ; Tue, 26 Feb 2002 01:30:33 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1Q9UUx12211; Tue, 26 Feb 2002 10:30:30 +0100 (MET) Date: Tue, 26 Feb 2002 10:25:46 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7AE774.AE3412F1@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I meant packets have been received recently (from the Generic Node without > HAO). OK. > > > > "creating a fresh destination cache entry" > > Does this apply independently of the history i.e. what if the > > destination cache entry was deleted 1 microsecond earlier due to > > some garbage collection even on the node? > > An implementation must preserve the active working set of entries in its > destination cache when doing garbage collection..If the entry was deleted > because of lifetime expiration, then the new entry will require tagging. Is this a new requirement in order for the scheme to work? RFC 2461 doesn't require the destination cache to contain the working set since most information in the destination cache can be rebuilt without sending packets. (path MTU is one piece of information that can't be rebuilt.) > Good point. When an unverified HAO arrives and there is no room in the > unverified BC, > the CN drops the packet. In addition (to what we described in the document), > it should send a Binding Request indicating that the MN should use either > RO or BDT (depending on what CN implements). If the CN doesn't allow the RO, then for how long time should the MN switch to BDT before trying to use an unverified HAO again? There seems to be a non-trivial performance tradeoff hiding in here. If the time until it tries again is too long then the communication might not see much of the claimed benefits of triagular, but if it is too short and the lack of space in the cache persists then there will be a packet lost for each time it tries to use an unverified HAO. > IV. Basic CN rules: > a) packets without HAO overide the tagged entry I don't understand this rule. Are you saying that the reception of a packet without HAO should not effect the cache? That would conflict with c). Or are you saying that this should have some effect on something else? Rule c) seems to say that unless the HAOs arrive frequently enough the cache entry will transition to no-tagging state, which will cause some packets to be dropped due to unverified HAO. This doesn't seem to be very robust against packet loss. At a minimum this time after which the state transition happens needs to be known by the MN so that e.g. if the MN knows that it sent the last unvHAO packet 10 seconds ago and the CN goes to no-tagging after 7 seconds, it should not send another unvHAO. But packet loss makes this hard. Continue assuming the CN goes to no-tagging after 7 seconds. If the MN sent the last unvHAO 4 seconds ago it should be ok to send another one, unless the first one was dropped by the network. How about if the MN sent unvHAO 2 seconds, 4 seconds, and 6 seconds ago? Then it is pretty sure that the CN hasn't transitioned to no-tagging state - it would only do so if there all 3 packets were lost. Sounds tricky - in a sense the unvHAO rules on the CN serve as a potential amplificator of packet loss in the network - packet loss in the network can cause additional packet loss/drops at the CN due to no-tagging state. Rule b) and c) seems to imply that if the MN happens to send a single packet without HAO to a CN then some number of packets will be dropped by the CN due to it having transitioned to no-tagging. This is rather constraining. For instance, a MN might wish to reverse-tunnel certain multicast packets with a HoA source thus those might arrive at the CN without a HAO. (This could be "fixed" by having the state on the CN be identified by the source (HoA) as well the destination address.) The 1a packet in the RR exchange (used to create and refresh RO) would also be reverse tunneled through the HA hence arrive without HAO. This would potentially cause a glitch when a MN wants to switch from using tringular to RO: MN sends data to CN using HAO - ok MN initiates RR exchange - sends 1a/1b CN receives 1a - transitions to no-tagging and sends 2a MN continues to send data to CN using HAO - dropped due to unvHAO MN recives 2a and 2b - sends BU to CN CN receives BU - creates BCE MN continues to send data to CN using HAO - accepted due to BCE Thus there is one round-trip during which the CN will drop packets. Of course, this can be "fixed" by adding more complex rules to the MNs use of HAO. But the complexity is already quite high IMHO. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 08:19:57 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27715 for ; Tue, 26 Feb 2002 08:19:56 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29650; Tue, 26 Feb 2002 05:15:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03435; Tue, 26 Feb 2002 05:15:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1QDEbKL006776 for ; Tue, 26 Feb 2002 05:14:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1QDEbPO006775 for mobile-ip-dist; Tue, 26 Feb 2002 05:14:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1QDEYKL006768 for ; Tue, 26 Feb 2002 05:14:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19036 for ; Tue, 26 Feb 2002 05:14:36 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01824 for ; Tue, 26 Feb 2002 06:14:34 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 048CDA for ; Tue, 26 Feb 2002 15:14:39 +0200 (EET) Message-ID: <3C7B8989.2070602@nomadiclab.com> Date: Tue, 26 Feb 2002 15:11:37 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit There has been a lot of confused discussion about the so called "one bit" method at the mobile-ip mailing list. The purpose of this message is to explain why the one bit is needed, and why using just one bit does not lock us into just two options, as some people tend to fear. 1. Why the "one bit" is needed? =============================== There seems to be clear WG consensus that the RR-only method is good enough for the baseline infrastructureless Mobile IPv6 BU authorization method. However, at the same time, there are clearly needs to use better methods to authorize the BUs, including AAA, PKI, and CGA based methods. There are two basic differences between the RR method and the other methods. Firstly, the plain RR method does not create any shared secret between the MN and the CN. The rationale here is that since it is preferable to obtain RR assurances to both the HoA and CoA each time a BU is sent, there is little benefit in creating such a shared secret, and creating such a shared secret would cost in terms of computation. The other methods do create such a shared secret. Secondly, even if the RR method was extended to create a shared secret (e.g. by including a DH exchange), the resulting shared secret would be completely unauthenticated. That is, the shared secret would not carry any information about *who* was involved in creating the secret. In the other methods, the shared secret is authenticated, in this sense. If AAA or PKI is used, the AAA or PKI provides some information about the peer. If CGA is used, the shared secret is associated with the public key of the peer, and the key is *strongly* associated with the Home Address. Thus, the two differences are: a) RR does not create a shared secret while the other methods do b) even if RR was extended to create a shared secret, the shared secret would be unauthenticated while in the other methods it is authenticated. Note that the main difference is *not* the shared secret versus not. The fact that even sharing a secret results in unauthenticated state is the real issue. In other words, the RR method infers via a leap of faith that trust in the routing infrastructure under normal routing conditions (MN at its home link) results on trust in a modified routing condition (MN at its CoA). The other methods include an explicit expression of trust (via certificates, cryptographic bindings between addresses and public keys, etc), and therefore they are inherently much stronger. Now, there are two consequences from these differences: 1. The RR method is strictly weaker than the other proposed methods. 2. It is always possible to fool a peer by bidding it down to accept RR, unless there is provisioning against this. The point 2. above is the so called "bidding down" argument. Let us try to explain this in detail, since there seems to be so much confusion about that. To simplify things, let us consider a situation where we have only two BU authorization methods, for example, "better RR", i.e. RR extended with shared secret creation, and AAA. We also must assume that the CN does not know the MN a priori. Under these circumstances, if an attacker can manouver itself into the path between the HA and the CN, it can run RR with the CN independent on what authorization method the MN would like to use. (We don't want to go to the detailed argument here, see elsewhere.) More importantly, though, the attacker can run RR with the CN even in the case that there is no MN but the claimed HoA is an address of a stationary host. In that case the "MN" (the stationary host) would not like to run any BU authorization at all, i.e. to use the "most secure" BU authorization option: no BUs accepted. This is the essense of the bidding down. Since the CN does not know what BU authorization method the "HoA owner" (the MN) wants to use, it must accept RR if someone uses it. (We know, there are fine points on this, and we can discuss those to death. But let's do it separately, if needed.) The purpose of the "one bit" method is to make a difference between RR only (or RR extended with a shared secret creation) and the other methods. That is, the purpose is to reserve one bit (or bit pattern), in the IP address, that says "RR is OK" or "RR is NOT ok". The selection between the other methods is another issue. It doesn't require any additional bits, as we will show in a moment. What is important to understand here, though, is that it is _necessary_ to reserve the bit in the Home Address, since the Home Address is what identifies the peer. Thus, all bits in the Home Address are implicitly secure; changing any of them does means that the attack is not against the same MN or stationary node any more. All the other bits in a message must be explicitly secured, since an attacker may freely select values for them, and such explicit securing is not possible with RR. 2. Why the "one bit" is sufficient? =================================== Let now assume that we have somehow weeded out the bidding down to RR attack. Consequently, we are in a situation where the CN must select between a number of other methods, including AAA, PKI, and CGA based ones. One possible way of doing this selection would be to use more bits than just one and encode the information again into the Home Address. However, this is unnecessary, since in all these other methods 1. the parties create a shared secret, i.e. a session integrity key, and 2. the shared secret is autheticated, at least in some sense of authentication. Again, the second point is the really important one. A shared secret created along a run of RR would be completely unauthenticated. [With this we mean that in RR there would be no cryptographic, or strong, binding between the Home Address and the shared secret. With RR there is only authorization based on trust on the routing infrastructure, and that is subject to Man-in-the-Middle attacks by on-path attackers. Remember, the purpose of the whole "one bit" method is to make sure that we can use stronger mechanisms than RR.] The exact nature and semantics of authentication, or binding between the Home Address and the shared secret, depends on the method used, and if we want to go into the fine print, we must also analyze that. But that is not the point of this note. What is relevant is that the authentication somehow creates a strong binding between the Home Address and the created shared secret. Thus, the mere fact that authentication succeeds indicates that the mobile node, as identified by the Home Address, is willing to use the suggested method. Consequently, we can simply include unsecured bits in the initial message, telling what authentication method the MN wants to use, and let the success of the authentication method implicitly verify the correctness of these bits. Note that this method does not prevent "bidding aside" attacks, i.e. attacks where an attacker is able to break one method, say AAA, but the MN actually wants to use another method, say PKI. In that case the attacker _is_ able to fool the CN to use AAA instead of PKI. There is a good question, now: does this matter? If (and only if) we can consider the used methods as _roughly_ equivalent, the danger of "bidding aside" is not so big. Summary ======= 1. RR is strictly less secure than the other suggested methods, but still sufficient and meets the baseline security requirements. 2. RR does not authenticate the peer in any sense, while the other proposed methods do, at least in some sense. This means that the other methods create a secure binding between the Home Address and some external information while RR does not. RR simply relies on the trust that the integrity of the routing infrastructure has not been violated. 3. If there is no explicit authentication, and thereby no external information that can be trusted upon, the only information flowing between the MN and the CN that can be trusted is the Home Address. This is actually a tautology, since the Home Address identifies the MN, and changing it changes the attack target. 4. Because of this, we *must* use one or more bits of the Home Address to indicate when RR may be used and when it must not be used. From the security point of view, it does not matter whether the bit or bits is a part of the interface ID or the routing prefix. The information just *must* be encoded into the Home Address, in some way. 5. On the other hand, we do *not* need to reserve any additional bits, since the other methods provide these additional trusted bits through authentication. 6. This still leaves the "bidding aside" problem, but that is much less severe than the "bidding down" attack. Notice that in order to prevent "bidding aside" (between roughly equivalent methods) from degenerating into "bidding down" (from more secure methods towards e.g. poorly configured certificate-based mechanisms), this would mean that some address ownership authorization procedures would have to be employed in all the "more secure" methods. For example, to employ PKI for Mobile IPv6, the PKI certificates must provide IPv6 addresses in SubjAltName of X.509. Similarily, to use AAA, the AAA infrastructure must carry authenticated binding between the Home Address and the MN's key all the way from the Home AAA Agent to the CN. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 19:14:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26066 for ; Tue, 26 Feb 2002 19:14:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20204; Tue, 26 Feb 2002 15:58:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24183; Tue, 26 Feb 2002 14:58:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1QMvSKL007322 for ; Tue, 26 Feb 2002 14:57:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1QMvSgD007321 for mobile-ip-dist; Tue, 26 Feb 2002 14:57:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1QMvPKL007314 for ; Tue, 26 Feb 2002 14:57:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07736 for ; Tue, 26 Feb 2002 14:57:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08410 for ; Tue, 26 Feb 2002 15:57:26 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA19598; Tue, 26 Feb 2002 14:57:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1QMvPw17962; Tue, 26 Feb 2002 14:57:25 -0800 X-mProtect:  Tue, 26 Feb 2002 14:57:25 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdn8VSSY; Tue, 26 Feb 2002 14:57:23 PST Message-ID: <3C7C12D3.13AA3CF7@iprg.nokia.com> Date: Tue, 26 Feb 2002 14:57:23 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, good feedback. I will answer your concerns below. Before that, let me provide some clarification. - our intention (original anyway) was to provide a mechanism that did no harm for Generic Nodes (GN) and worked for Mobile Nodes (ref Pekka Nikander's note to the list). I am glad that we are now discussing performance aspects and complexity of implementation. Good. - we see triangular routing as an option that serves two purposes. First, it is an alternative to BDT when there is no BCE. Second, it can be a stepping stone to RO. If a MN runs into performance issues (which BTW, depends on the implementation as you seem to rightly imply below), it should consider RO! - finally, we can specify exactly how tagging needs to work. One could argue that details amount to complexity; however, latent complexity in the absence of details is far worse (and perhaps dangerous). Now, onto the comments.. Erik Nordmark wrote: > > I meant packets have been received recently (from the Generic Node without > > HAO). > > OK. > > > > > > > "creating a fresh destination cache entry" > > > Does this apply independently of the history i.e. what if the > > > destination cache entry was deleted 1 microsecond earlier due to > > > some garbage collection even on the node? > > > > An implementation must preserve the active working set of entries in its > > destination cache when doing garbage collection..If the entry was deleted > > because of lifetime expiration, then the new entry will require tagging. > > Is this a new requirement in order for the scheme to work? > RFC 2461 doesn't require the destination cache to contain the working set > since most information in the destination cache can be rebuilt > without sending packets. (path MTU is one piece of information that can't > be rebuilt.) > It is a requirement. BTW, could you clarify what you mean wrt to RFC 2461 ? I have the following paragraph from 2461 that seems to indicate that the active working set needs to be preserved when garbage collecting. Also, how do you re-build destination cache entries without running "next-hop determination" ? Perhaps I am missing something.. Section 5.3 in 2461. "To limit the storage needed for the Destination and Neighbor Caches, a node may need to garbage-collect old entries. However, care must be taken to insure that sufficient space is always present to hold the working set of active entries. A small cache may result in an excessive number of Neighbor Discovery messages if entries are discarded and rebuilt in quick succession. Any LRU-based policy that only reclaims entries that have not been used in some time (e.g., ten minutes or more) should be adequate for garbage-collecting unused entries." > > > Good point. When an unverified HAO arrives and there is no room in the > > unverified BC, > > the CN drops the packet. In addition (to what we described in the document), > > it should send a Binding Request indicating that the MN should use either > > RO or BDT (depending on what CN implements). > > If the CN doesn't allow the RO, then for how long time should the MN > switch to BDT before trying to use an unverified HAO again? > There seems to be a non-trivial performance tradeoff hiding in here. > If the time until it tries again is too long then the communication > might not see much of the claimed benefits of triagular, but if it > is too short and the lack of space in the cache persists then there > will be a packet lost for each time it tries to use an unverified HAO. > IF the CN does not allow RO, then the MN should wait for a random period of time before attempting unverified HAO again. Typically, random timeouts (or even exponential backoff) help given the stochastic nature of the issue. Of course, the MN may decide to simply continue with BDT. I think the packet loss issue here is trivial. > > > IV. Basic CN rules: > > > a) packets without HAO overide the tagged entry > I don't understand this rule. Are you saying that the reception of a packet > without HAO should not effect the cache? That would conflict with c). > Or are you saying that this should have some effect on something else? > Sorry, I am saying when a CN receives packet without HAO, it removes the tagged entry (i.e., the CoA). This means if an attacker created a tagged entry using a GN's IP address, then receipt of a packet from the GN would "repair" the entry so that outgoing packets will not be tagged. > > Rule c) seems to say that unless the HAOs arrive frequently enough the > cache entry will transition to no-tagging state, which will cause > some packets to be dropped due to unverified HAO. > This doesn't seem to be very robust against packet loss. > At a minimum this time after which the state transition happens > needs to be known by the MN so that e.g. if the MN knows that it > sent the last unvHAO packet 10 seconds ago and the CN goes to no-tagging > after 7 seconds, it should not send another unvHAO. > But packet loss makes this hard. Continue assuming the CN goes to > no-tagging after 7 seconds. > If the MN sent the last unvHAO 4 seconds ago it should be ok to send > another one, unless the first one was dropped by the network. > How about if the MN sent unvHAO 2 seconds, 4 seconds, and 6 seconds ago? > Then it is pretty sure that the CN hasn't transitioned to no-tagging > state - it would only do so if there all 3 packets were lost. > Sounds tricky - in a sense the unvHAO rules on the CN serve as a potential > amplificator of packet loss in the network - packet loss in the network > can cause additional packet loss/drops at the CN due to no-tagging state. > This really depends on how you set the lifetime of the tagged entry. We thought having it small would work well for an average case when the MN has packets to send. It could be redefined taking expected packet transmission rate into consideration. I would like to note that the MN loses a packet when there is infrequent packet transmission _and_ network congestion; sort of a "bad" case. In any case, a simple extension may allow the CN to use history to not drop the packet. > > Rule b) and c) seems to imply that if the MN happens to send a single packet > without HAO to a CN then some number of packets will be dropped by the CN > due to it having transitioned to no-tagging. > This is rather constraining. For instance, a MN might wish to reverse-tunnel > certain multicast packets with a HoA source thus those might arrive at > the CN without a HAO. (This could be "fixed" by having the state on the CN > be identified by the source (HoA) as well the destination address.) > I didn't quite follow the text in parenthesis. Could you clarify ? > The 1a packet in the RR exchange (used to create and refresh RO) would > also be reverse tunneled through the HA hence arrive without HAO. > This would potentially cause a glitch when a MN wants to switch from > using tringular to RO: > MN sends data to CN using HAO - ok > MN initiates RR exchange - sends 1a/1b > CN receives 1a - transitions to no-tagging and sends 2a > MN continues to send data to CN using HAO - dropped due to unvHAO > MN recives 2a and 2b - sends BU to CN > CN receives BU - creates BCE > MN continues to send data to CN using HAO - accepted due to BCE > Thus there is one round-trip during which the CN will drop packets. Here, you could include a bit in 1a that indicates to the CN that the MN is using unverified HAO. The CN would then not transition to the no-tagging state, and subsequently no packet losses. > > Of course, this can be "fixed" by adding more complex rules to the MNs > use of HAO. > But the complexity is already quite high IMHO. > I see your concerns are regarding performance. I think we can start with an implementation note and then better understand values for configurable parameters, mostly the lifetime of unverified BCE. Thanks, -Rajeev > > Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 19:41:54 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26487 for ; Tue, 26 Feb 2002 19:41:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27023; Tue, 26 Feb 2002 16:41:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18463; Tue, 26 Feb 2002 16:41:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R0eiKL007505 for ; Tue, 26 Feb 2002 16:40:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1R0ehFo007504 for mobile-ip-dist; Tue, 26 Feb 2002 16:40:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R0eeKL007497 for ; Tue, 26 Feb 2002 16:40:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24948 for ; Tue, 26 Feb 2002 16:40:43 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16811 for ; Tue, 26 Feb 2002 17:40:42 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA26298 for ; Tue, 26 Feb 2002 16:40:41 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1R0eeW21903 for ; Tue, 26 Feb 2002 16:40:40 -0800 X-mProtect:  Tue, 26 Feb 2002 16:40:40 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1JdeG9; Tue, 26 Feb 2002 16:40:38 PST Message-ID: <3C7C2B07.3CD16029@iprg.nokia.com> Date: Tue, 26 Feb 2002 16:40:39 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Pekka, thank you for the write-up. It is well-written. I have couple of observations after reading it. 1) You state that creating a shared secret using RR would be completely unauthenticated. While I understand what you mean, here is another point. In today's Internet, you don't know who the peer is. So, using RR to create a shared secret amounts to doing so with someone you don't know. However, if this secret can ensure that you are dealing with the *same* entity that you dealt with earlier, then that can provide pretty good mobility. Sure, having a mechanism that allows a node to determine *who* the peer is desirable. However, that premise alone is not sufficient to rule out the ``middle option'' (i.e., shared secret with RR) when such an option can ensure that you are able to deal with the same peer. So, I see three options i) RR only ii) RR with shared secret, and ii) RR with shared secret established via peer authentication 2) There are options other than the 1-bit method available to allow a CN to determine that it should not RR. For instance, a CN can be statically configured to not accept RR (and only accept AAA-based solution). Where would that fit in your analysis ? Comments? BTW, I have some comments on Jari Arkko's bidding down text, where I will refer to the bit method. Regards, -Rajeev Pekka Nikander wrote: > There has been a lot of confused discussion about the so called > "one bit" method at the mobile-ip mailing list. The purpose of > this message is to explain why the one bit is needed, and why > using just one bit does not lock us into just two options, as > some people tend to fear. > > 1. Why the "one bit" is needed? > =============================== > > There seems to be clear WG consensus that the RR-only method > is good enough for the baseline infrastructureless Mobile IPv6 BU > authorization method. However, at the same time, there are clearly > needs to use better methods to authorize the BUs, including AAA, > PKI, and CGA based methods. > > There are two basic differences between the RR method and > the other methods. Firstly, the plain RR method does not create > any shared secret between the MN and the CN. The rationale > here is that since it is preferable to obtain RR assurances > to both the HoA and CoA each time a BU is sent, there is little > benefit in creating such a shared secret, and creating such a > shared secret would cost in terms of computation. The other methods > do create such a shared secret. Secondly, even if the RR method > was extended to create a shared secret (e.g. by including a > DH exchange), the resulting shared secret would be completely > unauthenticated. That is, the shared secret would not carry > any information about *who* was involved in creating the secret. > In the other methods, the shared secret is authenticated, in this > sense. If AAA or PKI is used, the AAA or PKI provides some > information about the peer. If CGA is used, the shared secret > is associated with the public key of the peer, and the key > is *strongly* associated with the Home Address. > > Thus, the two differences are: > > a) RR does not create a shared secret while the other methods do > > b) even if RR was extended to create a shared secret, the > shared secret would be unauthenticated while in the other > methods it is authenticated. > > Note that the main difference is *not* the shared secret versus not. > The fact that even sharing a secret results in unauthenticated > state is the real issue. In other words, the RR method infers > via a leap of faith that trust in the routing infrastructure under > normal routing conditions (MN at its home link) results on > trust in a modified routing condition (MN at its CoA). The other > methods include an explicit expression of trust (via certificates, > cryptographic bindings between addresses and public keys, etc), > and therefore they are inherently much stronger. > > Now, there are two consequences from these differences: > > 1. The RR method is strictly weaker than the other proposed > methods. > > 2. It is always possible to fool a peer by bidding it down to > accept RR, unless there is provisioning against this. > > The point 2. above is the so called "bidding down" argument. Let > us try to explain this in detail, since there seems to be so much > confusion about that. To simplify things, let us consider a > situation where we have only two BU authorization methods, for > example, "better RR", i.e. RR extended with shared secret creation, > and AAA. We also must assume that the CN does not know the MN > a priori. > > Under these circumstances, if an attacker can manouver itself into the > path between the HA and the CN, it can run RR with the CN independent > on what authorization method the MN would like to use. (We don't > want to go to the detailed argument here, see elsewhere.) More > importantly, though, the attacker can run RR with the CN even in > the case that there is no MN but the claimed HoA is an address of > a stationary host. In that case the "MN" (the stationary host) > would not like to run any BU authorization at all, i.e. to use > the "most secure" BU authorization option: no BUs accepted. > > This is the essense of the bidding down. Since the CN does not > know what BU authorization method the "HoA owner" (the MN) wants > to use, it must accept RR if someone uses it. (We know, there > are fine points on this, and we can discuss those to death. > But let's do it separately, if needed.) > > The purpose of the "one bit" method is to make a difference > between RR only (or RR extended with a shared secret > creation) and the other methods. That is, the purpose > is to reserve one bit (or bit pattern), in the IP address, > that says "RR is OK" or "RR is NOT ok". The selection > between the other methods is another issue. It doesn't require > any additional bits, as we will show in a moment. > > What is important to understand here, though, is that it > is _necessary_ to reserve the bit in the Home Address, since > the Home Address is what identifies the peer. Thus, all bits > in the Home Address are implicitly secure; changing any of > them does means that the attack is not against the same MN > or stationary node any more. All the other bits in a message > must be explicitly secured, since an attacker may freely > select values for them, and such explicit securing is not > possible with RR. > > 2. Why the "one bit" is sufficient? > =================================== > > Let now assume that we have somehow weeded out the bidding > down to RR attack. Consequently, we are in a situation where > the CN must select between a number of other methods, including > AAA, PKI, and CGA based ones. > > One possible way of doing this selection would be to use more > bits than just one and encode the information again into the > Home Address. However, this is unnecessary, since in all > these other methods > > 1. the parties create a shared secret, i.e. a session integrity > key, and > > 2. the shared secret is autheticated, at least in some > sense of authentication. > > Again, the second point is the really important one. A shared secret > created along a run of RR would be completely unauthenticated. [With > this we mean that in RR there would be no cryptographic, or strong, > binding between the Home Address and the shared secret. With RR there > is only authorization based on trust on the routing infrastructure, and > that is subject to Man-in-the-Middle attacks by on-path attackers. > Remember, the purpose of the whole "one bit" method is to make sure that > we can use stronger mechanisms than RR.] > > The exact nature and semantics of authentication, or binding between > the Home Address and the shared secret, depends on the method used, > and if we want to go into the fine print, we must also analyze that. > But that is not the point of this note. What is relevant is that > the authentication somehow creates a strong binding between the Home > Address and the created shared secret. > > Thus, the mere fact that authentication succeeds indicates that > the mobile node, as identified by the Home Address, is willing > to use the suggested method. Consequently, we can simply include > unsecured bits in the initial message, telling what authentication > method the MN wants to use, and let the success of the authentication > method implicitly verify the correctness of these bits. > > Note that this method does not prevent "bidding aside" attacks, > i.e. attacks where an attacker is able to break one method, > say AAA, but the MN actually wants to use another method, say PKI. > In that case the attacker _is_ able to fool the CN to use AAA > instead of PKI. There is a good question, now: does this matter? > If (and only if) we can consider the used methods as _roughly_ > equivalent, the danger of "bidding aside" is not so big. > > Summary > ======= > > 1. RR is strictly less secure than the other suggested methods, > but still sufficient and meets the baseline security requirements. > > 2. RR does not authenticate the peer in any sense, while the > other proposed methods do, at least in some sense. This > means that the other methods create a secure binding between > the Home Address and some external information while RR does not. > RR simply relies on the trust that the integrity of the routing > infrastructure has not been violated. > > 3. If there is no explicit authentication, and thereby no > external information that can be trusted upon, the only information > flowing between the MN and the CN that can be trusted is the > Home Address. This is actually a tautology, since the Home Address > identifies the MN, and changing it changes the attack target. > > 4. Because of this, we *must* use one or more bits of the Home > Address to indicate when RR may be used and when it must not > be used. From the security point of view, it does not matter > whether the bit or bits is a part of the interface ID or the > routing prefix. The information just *must* be encoded into > the Home Address, in some way. > > 5. On the other hand, we do *not* need to reserve any additional > bits, since the other methods provide these additional > trusted bits through authentication. > > 6. This still leaves the "bidding aside" problem, but that is much > less severe than the "bidding down" attack. Notice that in order > to prevent "bidding aside" (between roughly equivalent methods) > from degenerating into "bidding down" (from more secure methods > towards e.g. poorly configured certificate-based mechanisms), > this would mean that some address ownership authorization > procedures would have to be employed in all the "more secure" methods. > For example, to employ PKI for Mobile IPv6, the PKI certificates > must provide IPv6 addresses in SubjAltName of X.509. Similarily, > to use AAA, the AAA infrastructure must carry authenticated > binding between the Home Address and the MN's key all the way from > the Home AAA Agent to the CN. From owner-mobile-ip@sunroof.eng.sun.com Tue Feb 26 20:19:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26994 for ; Tue, 26 Feb 2002 20:19:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15374; Tue, 26 Feb 2002 18:19:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26305; Tue, 26 Feb 2002 17:19:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R1IEKL007659 for ; Tue, 26 Feb 2002 17:18:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1R1IEqT007658 for mobile-ip-dist; Tue, 26 Feb 2002 17:18:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R1IBKL007651 for ; Tue, 26 Feb 2002 17:18:11 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26074 for ; Tue, 26 Feb 2002 17:18:14 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07663 for ; Tue, 26 Feb 2002 17:18:13 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA00048 for ; Tue, 26 Feb 2002 17:18:12 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1R1IBM16356 for ; Tue, 26 Feb 2002 17:18:11 -0800 X-mProtect:  Tue, 26 Feb 2002 17:18:11 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdz8wpsY; Tue, 26 Feb 2002 17:08:24 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA01334 for ; Tue, 26 Feb 2002 17:08:10 -0800 (PST) Message-ID: <3C7C317A.1DA9F6C@iprg.nokia.com> Date: Tue, 26 Feb 2002 17:08:10 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, Thanks for defining the term bidding down. Seems the definition has varied among the discussing people, where at least my definition has refered to the union of bidding down and bidding aside. The classification of BU authorization methods you have provided is important and thoroughly presented. However, for now, let me address just two points. - Is routing identity encoding by 1 bit in host number really the only way to let CN know of MN's minimal BU authorization method? Perhaps to let CN know the policy by local configuration could be alternatives? If a local configuration were considered as an additive alternative, it could straightforwardly also support bidding aside unlike the 1 bit, woulnd't it? - While fully agreeing on the significant conceptual difference between bidding down and aside, I would like to better understand the issue why bidding aside is insignificant. Basically, is there no difference in level of security or desirability of authorization among the higher class methods? One could have - key lengths are significantly different (60 vs 1000 bits) - the authorization is derived from a separate registration identity (associated with the routing identity like in your PKI example) or directly from the routing identity - different non-security related policy reasons to mandate a method (e.g., AAA-based) in a certain network, for example. What about a practical case there is a "lemon" amongst the multiple methods available among the higher class of methods. If this would be the weakest link among the set of methods in this class, wouldn't that make security of the whole class shrink to that level without a bidding aside method to "shut down" such a method? BR, -Jari M > There has been a lot of confused discussion about the so called > "one bit" method at the mobile-ip mailing list. The purpose of > this message is to explain why the one bit is needed, and why > using just one bit does not lock us into just two options, as > some people tend to fear. > > 1. Why the "one bit" is needed? > =============================== > > There seems to be clear WG consensus that the RR-only method > is good enough for the baseline infrastructureless Mobile IPv6 BU > authorization method. However, at the same time, there are clearly > needs to use better methods to authorize the BUs, including AAA, > PKI, and CGA based methods. > > There are two basic differences between the RR method and > the other methods. Firstly, the plain RR method does not create > any shared secret between the MN and the CN. The rationale > here is that since it is preferable to obtain RR assurances > to both the HoA and CoA each time a BU is sent, there is little > benefit in creating such a shared secret, and creating such a > shared secret would cost in terms of computation. The other methods > do create such a shared secret. Secondly, even if the RR method > was extended to create a shared secret (e.g. by including a > DH exchange), the resulting shared secret would be completely > unauthenticated. That is, the shared secret would not carry > any information about *who* was involved in creating the secret. > In the other methods, the shared secret is authenticated, in this > sense. If AAA or PKI is used, the AAA or PKI provides some > information about the peer. If CGA is used, the shared secret > is associated with the public key of the peer, and the key > is *strongly* associated with the Home Address. > > Thus, the two differences are: > > a) RR does not create a shared secret while the other methods do > > b) even if RR was extended to create a shared secret, the > shared secret would be unauthenticated while in the other > methods it is authenticated. > > Note that the main difference is *not* the shared secret versus not. > The fact that even sharing a secret results in unauthenticated > state is the real issue. In other words, the RR method infers > via a leap of faith that trust in the routing infrastructure under > normal routing conditions (MN at its home link) results on > trust in a modified routing condition (MN at its CoA). The other > methods include an explicit expression of trust (via certificates, > cryptographic bindings between addresses and public keys, etc), > and therefore they are inherently much stronger. > > Now, there are two consequences from these differences: > > 1. The RR method is strictly weaker than the other proposed > methods. > > 2. It is always possible to fool a peer by bidding it down to > accept RR, unless there is provisioning against this. > > The point 2. above is the so called "bidding down" argument. Let > us try to explain this in detail, since there seems to be so much > confusion about that. To simplify things, let us consider a > situation where we have only two BU authorization methods, for > example, "better RR", i.e. RR extended with shared secret creation, > and AAA. We also must assume that the CN does not know the MN > a priori. > > Under these circumstances, if an attacker can manouver itself into the > path between the HA and the CN, it can run RR with the CN independent > on what authorization method the MN would like to use. (We don't > want to go to the detailed argument here, see elsewhere.) More > importantly, though, the attacker can run RR with the CN even in > the case that there is no MN but the claimed HoA is an address of > a stationary host. In that case the "MN" (the stationary host) > would not like to run any BU authorization at all, i.e. to use > the "most secure" BU authorization option: no BUs accepted. > > This is the essense of the bidding down. Since the CN does not > know what BU authorization method the "HoA owner" (the MN) wants > to use, it must accept RR if someone uses it. (We know, there > are fine points on this, and we can discuss those to death. > But let's do it separately, if needed.) > > The purpose of the "one bit" method is to make a difference > between RR only (or RR extended with a shared secret > creation) and the other methods. That is, the purpose > is to reserve one bit (or bit pattern), in the IP address, > that says "RR is OK" or "RR is NOT ok". The selection > between the other methods is another issue. It doesn't require > any additional bits, as we will show in a moment. > > What is important to understand here, though, is that it > is _necessary_ to reserve the bit in the Home Address, since > the Home Address is what identifies the peer. Thus, all bits > in the Home Address are implicitly secure; changing any of > them does means that the attack is not against the same MN > or stationary node any more. All the other bits in a message > must be explicitly secured, since an attacker may freely > select values for them, and such explicit securing is not > possible with RR. > > 2. Why the "one bit" is sufficient? > =================================== > > Let now assume that we have somehow weeded out the bidding > down to RR attack. Consequently, we are in a situation where > the CN must select between a number of other methods, including > AAA, PKI, and CGA based ones. > > One possible way of doing this selection would be to use more > bits than just one and encode the information again into the > Home Address. However, this is unnecessary, since in all > these other methods > > 1. the parties create a shared secret, i.e. a session integrity > key, and > > 2. the shared secret is autheticated, at least in some > sense of authentication. > > Again, the second point is the really important one. A shared secret > created along a run of RR would be completely unauthenticated. [With > this we mean that in RR there would be no cryptographic, or strong, > binding between the Home Address and the shared secret. With RR there > is only authorization based on trust on the routing infrastructure, and > that is subject to Man-in-the-Middle attacks by on-path attackers. > Remember, the purpose of the whole "one bit" method is to make sure that > we can use stronger mechanisms than RR.] > > The exact nature and semantics of authentication, or binding between > the Home Address and the shared secret, depends on the method used, > and if we want to go into the fine print, we must also analyze that. > But that is not the point of this note. What is relevant is that > the authentication somehow creates a strong binding between the Home > Address and the created shared secret. > > Thus, the mere fact that authentication succeeds indicates that > the mobile node, as identified by the Home Address, is willing > to use the suggested method. Consequently, we can simply include > unsecured bits in the initial message, telling what authentication > method the MN wants to use, and let the success of the authentication > method implicitly verify the correctness of these bits. > > Note that this method does not prevent "bidding aside" attacks, > i.e. attacks where an attacker is able to break one method, > say AAA, but the MN actually wants to use another method, say PKI. > In that case the attacker _is_ able to fool the CN to use AAA > instead of PKI. There is a good question, now: does this matter? > If (and only if) we can consider the used methods as _roughly_ > equivalent, the danger of "bidding aside" is not so big. > > Summary > ======= > > 1. RR is strictly less secure than the other suggested methods, > but still sufficient and meets the baseline security requirements. > > 2. RR does not authenticate the peer in any sense, while the > other proposed methods do, at least in some sense. This > means that the other methods create a secure binding between > the Home Address and some external information while RR does not. > RR simply relies on the trust that the integrity of the routing > infrastructure has not been violated. > > 3. If there is no explicit authentication, and thereby no > external information that can be trusted upon, the only information > flowing between the MN and the CN that can be trusted is the > Home Address. This is actually a tautology, since the Home Address > identifies the MN, and changing it changes the attack target. > > 4. Because of this, we *must* use one or more bits of the Home > Address to indicate when RR may be used and when it must not > be used. From the security point of view, it does not matter > whether the bit or bits is a part of the interface ID or the > routing prefix. The information just *must* be encoded into > the Home Address, in some way. > > 5. On the other hand, we do *not* need to reserve any additional > bits, since the other methods provide these additional > trusted bits through authentication. > > 6. This still leaves the "bidding aside" problem, but that is much > less severe than the "bidding down" attack. Notice that in order > to prevent "bidding aside" (between roughly equivalent methods) > from degenerating into "bidding down" (from more secure methods > towards e.g. poorly configured certificate-based mechanisms), > this would mean that some address ownership authorization > procedures would have to be employed in all the "more secure" methods. > For example, to employ PKI for Mobile IPv6, the PKI certificates > must provide IPv6 addresses in SubjAltName of X.509. Similarily, > to use AAA, the AAA infrastructure must carry authenticated > binding between the Home Address and the MN's key all the way from > the Home AAA Agent to the CN. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 02:12:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08612 for ; Wed, 27 Feb 2002 02:12:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA12074; Tue, 26 Feb 2002 23:11:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18678; Tue, 26 Feb 2002 23:11:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R7AoKL008282 for ; Tue, 26 Feb 2002 23:10:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1R7Ao2O008281 for mobile-ip-dist; Tue, 26 Feb 2002 23:10:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R7AlKL008274 for ; Tue, 26 Feb 2002 23:10:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18605 for ; Tue, 26 Feb 2002 23:10:49 -0800 (PST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16684 for ; Wed, 27 Feb 2002 00:10:45 -0700 (MST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1R7Aer15827 for ; Wed, 27 Feb 2002 02:10:40 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA28373; Tue, 26 Feb 2002 21:08:15 -0500 (EST) To: mobile-ip@sunroof.eng.sun.com, rajeev@iprg.nokia.com, pekka.nikander@momadiclab.com Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA28365; Tue, 26 Feb 2002 21:07:10 -0500 (EST) Message-ID: <3C7C3F4D.FAFF1195@lucent.com> Date: Tue, 26 Feb 2002 21:07:09 -0500 From: Erik Anderlind X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: mobile-ip@sunroof.eng.sun.com, rajeev@iprg.nokia.com, pekka.nikander@momadiclab.com Subject: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Rajeev and Pekka, To restate Rajeev's comments in slightly different way: A way to use "dynamic RR secrets" If a random identifier is included in a RR "challenge" from the CN, this random value can be used both to verify the immediate "response" and a future BU request from the same MN. (Ps: It is the CN that needs to verify that the new COA can be used.) Example: For the first BU msg a CN receives from a MN, the CN would need to verify both RR to the home address (home address ownership test) and RR to the COA (ensure not a DoS attack). By using different random values in each of these tests, a Man-in-the-middle needs be be on both paths for both tests to pass. Subsequent BUs could use one or the other of these random values to prove beyond reasonable doubt that this is a valid BU (CN could immediately update cache, so that handover is fast, and run the RR scheme in the background to confirm ). Saving these random values obviously increases state in the CN and MN caches. It is however soft state. If state info is lost/overwritten, either revert to sending data through HA, or perform new RR tests. It might even be possible to store only one value in the CN cache and have a smart alg for locally generating the other. To Rajeev's 2nd question: I am a little lost on the 1-bit issue. It seems the preference for accepting RR or not, only needs to be in BU messages, so overhead doesn't seem a large consideration. Why not add a 1 byte BU message option that allows all supported address verification options to be conveyed at once - it seems we will need that type of a message field in the negotiation phase following a 1-bit "not set" anyhow. (Is there a problem creating this type of 1 byte option to the BU option?) ...Erik Rajeev Koodli wrote: > > Hello Pekka, > > thank you for the write-up. It is well-written. > > I have couple of observations after reading it. > > 1) You state that creating a shared secret using RR would be completely > unauthenticated. While I understand what you mean, here is another point. In > today's Internet, you don't know who the peer is. So, using RR to create a shared > secret amounts to doing so with someone you don't know. However, if this secret can > ensure that you are dealing with the *same* entity that you dealt with earlier, > then that can provide pretty good mobility. Sure, having a mechanism that allows a > node to determine *who* the peer is desirable. However, that premise alone is not > sufficient to rule out the ``middle option'' (i.e., shared secret with RR) when > such an option can ensure that you are able to deal with the same peer. So, I see > three options > > i) RR only > ii) RR with shared secret, and > ii) RR with shared secret established via peer authentication > > 2) There are options other than the 1-bit method available to allow a CN to > determine that it should not RR. For instance, a CN can be statically configured to > not accept RR (and only accept AAA-based solution). Where would that fit in your > analysis ? > > Comments? > > BTW, I have some comments on Jari Arkko's bidding down text, where I will refer to > the bit method. > > Regards, > > -Rajeev > > Pekka Nikander wrote: > > > There has been a lot of confused discussion about the so called > > "one bit" method at the mobile-ip mailing list. The purpose of > > this message is to explain why the one bit is needed, and why > > using just one bit does not lock us into just two options, as > > some people tend to fear. > > > > 1. Why the "one bit" is needed? > > =============================== > > > > There seems to be clear WG consensus that the RR-only method > > is good enough for the baseline infrastructureless Mobile IPv6 BU > > authorization method. However, at the same time, there are clearly > > needs to use better methods to authorize the BUs, including AAA, > > PKI, and CGA based methods. > > > > There are two basic differences between the RR method and > > the other methods. Firstly, the plain RR method does not create > > any shared secret between the MN and the CN. The rationale > > here is that since it is preferable to obtain RR assurances > > to both the HoA and CoA each time a BU is sent, there is little > > benefit in creating such a shared secret, and creating such a > > shared secret would cost in terms of computation. The other methods > > do create such a shared secret. Secondly, even if the RR method > > was extended to create a shared secret (e.g. by including a > > DH exchange), the resulting shared secret would be completely > > unauthenticated. That is, the shared secret would not carry > > any information about *who* was involved in creating the secret. > > In the other methods, the shared secret is authenticated, in this > > sense. If AAA or PKI is used, the AAA or PKI provides some > > information about the peer. If CGA is used, the shared secret > > is associated with the public key of the peer, and the key > > is *strongly* associated with the Home Address. > > > > Thus, the two differences are: > > > > a) RR does not create a shared secret while the other methods do > > > > b) even if RR was extended to create a shared secret, the > > shared secret would be unauthenticated while in the other > > methods it is authenticated. > > > > Note that the main difference is *not* the shared secret versus not. > > The fact that even sharing a secret results in unauthenticated > > state is the real issue. In other words, the RR method infers > > via a leap of faith that trust in the routing infrastructure under > > normal routing conditions (MN at its home link) results on > > trust in a modified routing condition (MN at its CoA). The other > > methods include an explicit expression of trust (via certificates, > > cryptographic bindings between addresses and public keys, etc), > > and therefore they are inherently much stronger. > > > > Now, there are two consequences from these differences: > > > > 1. The RR method is strictly weaker than the other proposed > > methods. > > > > 2. It is always possible to fool a peer by bidding it down to > > accept RR, unless there is provisioning against this. > > > > The point 2. above is the so called "bidding down" argument. Let > > us try to explain this in detail, since there seems to be so much > > confusion about that. To simplify things, let us consider a > > situation where we have only two BU authorization methods, for > > example, "better RR", i.e. RR extended with shared secret creation, > > and AAA. We also must assume that the CN does not know the MN > > a priori. > > > > Under these circumstances, if an attacker can manouver itself into the > > path between the HA and the CN, it can run RR with the CN independent > > on what authorization method the MN would like to use. (We don't > > want to go to the detailed argument here, see elsewhere.) More > > importantly, though, the attacker can run RR with the CN even in > > the case that there is no MN but the claimed HoA is an address of > > a stationary host. In that case the "MN" (the stationary host) > > would not like to run any BU authorization at all, i.e. to use > > the "most secure" BU authorization option: no BUs accepted. > > > > This is the essense of the bidding down. Since the CN does not > > know what BU authorization method the "HoA owner" (the MN) wants > > to use, it must accept RR if someone uses it. (We know, there > > are fine points on this, and we can discuss those to death. > > But let's do it separately, if needed.) > > > > The purpose of the "one bit" method is to make a difference > > between RR only (or RR extended with a shared secret > > creation) and the other methods. That is, the purpose > > is to reserve one bit (or bit pattern), in the IP address, > > that says "RR is OK" or "RR is NOT ok". The selection > > between the other methods is another issue. It doesn't require > > any additional bits, as we will show in a moment. > > > > What is important to understand here, though, is that it > > is _necessary_ to reserve the bit in the Home Address, since > > the Home Address is what identifies the peer. Thus, all bits > > in the Home Address are implicitly secure; changing any of > > them does means that the attack is not against the same MN > > or stationary node any more. All the other bits in a message > > must be explicitly secured, since an attacker may freely > > select values for them, and such explicit securing is not > > possible with RR. > > > > 2. Why the "one bit" is sufficient? > > =================================== > > > > Let now assume that we have somehow weeded out the bidding > > down to RR attack. Consequently, we are in a situation where > > the CN must select between a number of other methods, including > > AAA, PKI, and CGA based ones. > > > > One possible way of doing this selection would be to use more > > bits than just one and encode the information again into the > > Home Address. However, this is unnecessary, since in all > > these other methods > > > > 1. the parties create a shared secret, i.e. a session integrity > > key, and > > > > 2. the shared secret is autheticated, at least in some > > sense of authentication. > > > > Again, the second point is the really important one. A shared secret > > created along a run of RR would be completely unauthenticated. [With > > this we mean that in RR there would be no cryptographic, or strong, > > binding between the Home Address and the shared secret. With RR there > > is only authorization based on trust on the routing infrastructure, and > > that is subject to Man-in-the-Middle attacks by on-path attackers. > > Remember, the purpose of the whole "one bit" method is to make sure that > > we can use stronger mechanisms than RR.] > > > > The exact nature and semantics of authentication, or binding between > > the Home Address and the shared secret, depends on the method used, > > and if we want to go into the fine print, we must also analyze that. > > But that is not the point of this note. What is relevant is that > > the authentication somehow creates a strong binding between the Home > > Address and the created shared secret. > > > > Thus, the mere fact that authentication succeeds indicates that > > the mobile node, as identified by the Home Address, is willing > > to use the suggested method. Consequently, we can simply include > > unsecured bits in the initial message, telling what authentication > > method the MN wants to use, and let the success of the authentication > > method implicitly verify the correctness of these bits. > > > > Note that this method does not prevent "bidding aside" attacks, > > i.e. attacks where an attacker is able to break one method, > > say AAA, but the MN actually wants to use another method, say PKI. > > In that case the attacker _is_ able to fool the CN to use AAA > > instead of PKI. There is a good question, now: does this matter? > > If (and only if) we can consider the used methods as _roughly_ > > equivalent, the danger of "bidding aside" is not so big. > > > > Summary > > ======= > > > > 1. RR is strictly less secure than the other suggested methods, > > but still sufficient and meets the baseline security requirements. > > > > 2. RR does not authenticate the peer in any sense, while the > > other proposed methods do, at least in some sense. This > > means that the other methods create a secure binding between > > the Home Address and some external information while RR does not. > > RR simply relies on the trust that the integrity of the routing > > infrastructure has not been violated. > > > > 3. If there is no explicit authentication, and thereby no > > external information that can be trusted upon, the only information > > flowing between the MN and the CN that can be trusted is the > > Home Address. This is actually a tautology, since the Home Address > > identifies the MN, and changing it changes the attack target. > > > > 4. Because of this, we *must* use one or more bits of the Home > > Address to indicate when RR may be used and when it must not > > be used. From the security point of view, it does not matter > > whether the bit or bits is a part of the interface ID or the > > routing prefix. The information just *must* be encoded into > > the Home Address, in some way. > > > > 5. On the other hand, we do *not* need to reserve any additional > > bits, since the other methods provide these additional > > trusted bits through authentication. > > > > 6. This still leaves the "bidding aside" problem, but that is much > > less severe than the "bidding down" attack. Notice that in order > > to prevent "bidding aside" (between roughly equivalent methods) > > from degenerating into "bidding down" (from more secure methods > > towards e.g. poorly configured certificate-based mechanisms), > > this would mean that some address ownership authorization > > procedures would have to be employed in all the "more secure" methods. > > For example, to employ PKI for Mobile IPv6, the PKI certificates > > must provide IPv6 addresses in SubjAltName of X.509. Similarily, > > to use AAA, the AAA infrastructure must carry authenticated > > binding between the Home Address and the MN's key all the way from > > the Home AAA Agent to the CN. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 04:57:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15317 for ; Wed, 27 Feb 2002 04:57:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19892; Wed, 27 Feb 2002 02:57:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06650; Wed, 27 Feb 2002 01:57:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R9uPKL008501 for ; Wed, 27 Feb 2002 01:56:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1R9uPmM008500 for mobile-ip-dist; Wed, 27 Feb 2002 01:56:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1R9uMKL008493 for ; Wed, 27 Feb 2002 01:56:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08767 for ; Wed, 27 Feb 2002 01:56:24 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15518 for ; Wed, 27 Feb 2002 01:56:18 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 6920AA; Wed, 27 Feb 2002 11:58:10 +0200 (EET) Message-ID: <3C7CAD40.9030104@nomadiclab.com> Date: Wed, 27 Feb 2002 11:56:16 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020221 X-Accept-Language: en-us MIME-Version: 1.0 To: rajeev@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, Thanks for your excellent questions and observations. I notice that we have failed to explicitly express some assumptions that we have made. Firstly, througout the document we have made the assumption that if plain RR is used, the MN and CN do not have any a priori information about each other. Secondly, we assume that the CN wants to do RR without *needing* to do any extra checks from some infrastructure. That is, since RR is designed to work when the CN does not have any a priori knowledge about the MN, mandating that the CN consults some external data source to learn more information about the MN would foil the purpose of RR. On the other hand, this does not mean that a _particular_ CN couldn't consult such an external information source, if it is locally desirable. These are fundamental assumptions, based on the desire to produce a Mobile IPv6 security solution that works without requiring a new infrastructure. Remember, the fact that using just IPsec would have required a new global PKI infrastructure was one reason why IESG send Mobile IPv6 back. [I have edited your line lenghts to make reading easier; sorry if I messed up your message by doing so.] > I have couple of observations after reading it. > > 1) You state that creating a shared secret using RR would > be completely unauthenticated. While I understand what you > mean, here is another point. In today's Internet, you don't > know who the peer is. So, using RR to create a shared secret > amounts to doing so with someone you don't know. However, > if this secret can ensure that you are dealing with the > *same* entity that you dealt with earlier, then that can > provide pretty good mobility. Sure, having a mechanism that > allows a node to determine *who* the peer is desirable. I mostly agree with you, but there is a little twist. In today's Internet, you don't know who your peer is. All you know is that your peer is able to receive packets sent to a given IP address. If we enhance RR with some mechanism to create a shared secret (e.g. RR + DH), we certainly get a shared secret with someone who is able to receive packets at the given IP address *at the time* when the share secret is created. But remember that the someone does not need to be a legitimite node at the destination address, it can be any node between the sender and the destination. The difference between today's situation and RR is that in RR we do not know whether this party is able to receive packets sent to the given address (the Home Address) later on, unless we check it again. That's also the reason why we require in RR that also the reachability of the Home Address is checked on every BU, and why we require that the binding lifetime is relatively short. Thus, the difference between today's Internet and RR is in timing; *when* somebody is reachable: as long as you communicate with him/her, or only in the beginning. This difference is also the reason why RR is not quite as secure as the current practice, but only close enough. Let me express the same argument from a different point of view: In today's Internet the hosts are *identified* by the IP address (and I purposefully say identified and not merely named). The reason why this works so well, and why we have fairly few connection hijacking and MitM problems, is the fact that the routing system uses the addresses directly. That is, given a packet sent to a given address, only those nodes that are at the path between the sender and the topological location named by the address are able to see and act on the packet. With mobility we have to somehow break this binding, either by introducing a new naming layer, as HIP does, or by using two different addresses, as Mobile IP does. This is the source of the security problems we have. And since we break this binding, in RR we need to do the Home Address reachability check fairly often. What the other methods do, though, is that replace the implicit binding created by the routing infrastructure by some explicit external binding. In CGA the new binding is based on cryptography and computational infeasibility. In AAA and PKI the new binding is based on trust on some third party. > However, that premise alone is not sufficient to rule out > the ``middle option'' (i.e., shared secret with RR) when > such an option can ensure that you are able to deal with > the same peer. So, I see three options > > i) RR only > ii) RR with shared secret, and > iii) RR with shared secret established via peer authentication I agree with this analysis. And I am not ruling out the RR with share secret option. Sure you can use it if you want to; however, I do not see any *practical* security difference between RR only and RR with shared secret. RR with some sort of authentication is clearly different, since it would require some external property or party to base the authentication on. RR only relies that you check that your peer is reachable at the Home Address each time you do RR. In RR with shared secret you need to do that check anyway, since otherwise you would create a larger-than-acceptable timing difference, compared to the current situation. Thus, the only added assurance you get is that the party remains the same. You do not get any added assurance about the "ownership" of the Home Address; there the both methods are similar. I agree that if we look at the situation from a pure security perspective, there is a difference, clearly, since the set of possible attacks are different. However, if we look at from a practical point of view, considering where in the Internet the attacker must lurk and what it must be able to do, the difference *seems to be* fairly minor or almost nonexistent. On the other hand, there may be new attacks that we do not know of, such attacks that RR only is vulnerable but RR + shared secret is not. > 2) There are options other than the 1-bit method available > to allow a CN to determine that it should not RR. For instance, > a CN can be statically configured to not accept RR (and only > accept AAA-based solution). Where would that fit in your analysis ? A priori configuration is always possible. As I said above, we forgot to emphasise that our analysis is based on the assumption that the MN and the CN do not have any a priori knowledge about each other. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 05:14:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15525 for ; Wed, 27 Feb 2002 05:14:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13625; Wed, 27 Feb 2002 03:13:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08196; Wed, 27 Feb 2002 02:13:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RACiKL008556 for ; Wed, 27 Feb 2002 02:12:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RACib5008555 for mobile-ip-dist; Wed, 27 Feb 2002 02:12:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RACeKL008548 for ; Wed, 27 Feb 2002 02:12:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08057 for ; Wed, 27 Feb 2002 02:12:43 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25056 for ; Wed, 27 Feb 2002 03:12:42 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 3281EA; Wed, 27 Feb 2002 12:14:34 +0200 (EET) Message-ID: <3C7CB118.6040807@nomadiclab.com> Date: Wed, 27 Feb 2002 12:12:40 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020221 X-Accept-Language: en-us MIME-Version: 1.0 To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C317A.1DA9F6C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, Let me briefly answer you excellent questions. > However, for now, let me address just two points. > > - Is routing identity encoding by 1 bit in host number > really the only way to let CN know of MN's minimal BU > authorization method? Perhaps to let CN know the policy by > local configuration could be alternatives? If a local > configuration were considered as an additive alternative, > it could straightforwardly also support bidding aside > unlike the 1 bit, woulnd't it? As I already wrote in length in the answer to Rajeev's message, we were only considering the situation where the MN and the CN do not have any a priori knowledge and do not rely on some external infrastructure. Local configuration is always possible, and could be classified as a priori knowledge. > - While fully agreeing on the significant conceptual > difference between bidding down and aside, I would like > to better understand the issue why bidding aside is > insignificant. Basically, is there no difference > in level of security or desirability of authorization > among the higher class methods? There could be differences between the "higher" level security methods. As we stated in the analysis, we consider "bidding aside" *less significant* (not insignificant) for two reasons: 1. RR is strictly less secure 2. The other suggested methods have some kind of authentication, i.e. they add some external knowledge that we rely on, in order to determine that there is a binding between the MN and its Home Address. But sure "bidding aside" *can* be a problem. Local configuration is a clear answer to that: if a CN does not trust on, e.g. CGA, it can turn it completely off. The only consequence of this is that CGA-only MNs must either note use RO or obtain a new home address that allows RR only. > What about a practical case there is a "lemon" amongst > the multiple methods available among the higher class > of methods. If this would be the weakest link among > the set of methods in this class, wouldn't that make security > of the whole class shrink to that level without a bidding > aside method to "shut down" such a method? You are right in your analysis. However, we must place this question in the right context: the purpose of RR is to place a minimum baseline that ensures us *interoperability*. Other methods can be seen as optional, providing added security. Since RR poses the threat of "bidding down", and since all nodes must support RR for interoperability reasons, we do need a built in mechanism for signalling that RR must not be used. This allows an MN to try to use a more secure mechanism in the first place. If that fails, it can always fall back to RR through using a separate Home Address. (Side note: If there was another infrastructureless way of preventing bidding down, I'd be more than happy to use it. I am not particularly fond of the "one bit" method. It just seems to be the only one that works.) The second section in the analysis tried to point out that it is possible to support multiple, *roughly equivalent* methods, without requiring more bits to be reserved. The crusial point here is that rough equivalence. Our understanding on what methods are roughly equivalent and what are not may change over time, but IMHO that can be handled through local configuration. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 05:25:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15671 for ; Wed, 27 Feb 2002 05:25:05 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29967; Wed, 27 Feb 2002 03:24:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08639; Wed, 27 Feb 2002 02:24:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RANjKL008620 for ; Wed, 27 Feb 2002 02:23:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RANj06008619 for mobile-ip-dist; Wed, 27 Feb 2002 02:23:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RANgKL008612 for ; Wed, 27 Feb 2002 02:23:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09291 for ; Wed, 27 Feb 2002 02:23:44 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29520 for ; Wed, 27 Feb 2002 03:23:43 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id BCD2FA; Wed, 27 Feb 2002 12:25:35 +0200 (EET) Message-ID: <3C7CB3AD.4000206@nomadiclab.com> Date: Wed, 27 Feb 2002 12:23:41 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020221 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: rajeev@iprg.nokia.com, eanderlind@lucent.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, As I tried to say in my reply to Rajeev's message, the point of the analysis was not whether RR-only and RR-with-shared-secret are equivalent or not. I acknowledge that our current understanding is that they are *practically* equivalent, but that understanding may change as we learn more. What comes to your suggestion here ... > If a random identifier is included in a RR "challenge" > from the CN, this random value can be used both to verify > the immediate "response" and a future BU request from the > same MN. (Ps: It is the CN that needs to verify that the new COA > can be used.) > > Example: > For the first BU msg a CN receives from a MN, the CN would need > to verify both RR to the home address (home address ownership test) and > RR to the COA (ensure not a DoS attack). By using different > random values in each of these tests, a Man-in-the-middle needs be > be on both paths for both tests to pass. Subsequent BUs could use one or > the other of these random values to prove beyond reasonable doubt that > this is a valid BU (CN could immediately update cache, so that > handover is fast, and run the RR scheme in the background to confirm ). > > Saving these random values obviously increases state in the CN and > MN caches. It is however soft state. If state info is > lost/overwritten, either revert to sending data through HA, > or perform new RR tests. It might even be possible to store only > one value in the CN cache and have a smart alg for locally > generating the other. ... unfortunately the situation is not so simple. What you describe above is more or less equal with our original BAKE design. Later on Tuomas Aura, Michael Roe and Jari Arkko analyzed the situation more, and found new attacks that the design above does not block adequately. The basic issue is in timing and the ability to use these timing problems to move attacks into the future, and thereby making tracking the attackers considerably harder. I think Jari Arkko documented the analysis in one of his Design Team notes/recommendations, but I don't remember in which one. Jari? > To Rajeev's 2nd question: > I am a little lost on the 1-bit issue. It seems the preference for > accepting RR or not, only needs to be in BU messages, so > overhead doesn't seem a large consideration. Why not > add a 1 byte BU message option that allows all supported address > verification options to be conveyed at once - it seems we will > need that type of a message > field in the negotiation phase following a 1-bit "not set" anyhow. > (Is there a problem creating this type of 1 byte option to the BU > option?) Such an added byte, signaling the options that the sender wants to use, is being added to the forthcoming DT design. Thus, the idea is to use the "one bit" method signal whether RR may be used or not, and an external, explicitly authenticated data field to signal other options, including the set of more secure BU authorization methods that the host would be willing to use. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 07:24:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18177 for ; Wed, 27 Feb 2002 07:24:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24302; Wed, 27 Feb 2002 05:24:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22360; Wed, 27 Feb 2002 04:24:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCNdKL008794 for ; Wed, 27 Feb 2002 04:23:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RCNdmM008793 for mobile-ip-dist; Wed, 27 Feb 2002 04:23:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCNZKL008786 for ; Wed, 27 Feb 2002 04:23:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11581 for ; Wed, 27 Feb 2002 04:23:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24972 for ; Wed, 27 Feb 2002 05:23:36 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17864; Wed, 27 Feb 2002 07:23:33 -0500 (EST) Message-Id: <200202271223.HAA17864@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com, dhcwg@ietf.org From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-levkowetz-dhc-mip-fa-00.txt Date: Wed, 27 Feb 2002 07:23:32 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for Mobile IP Foreign Agents Author(s) : H. Levkowetz Filename : draft-levkowetz-dhc-mip-fa-00.txt Pages : 8 Date : 26-Feb-02 This document defines a new Dynamic Host Configuration Protocol (DHCP) option which is passed from the DHCP Server to the DHCP Client to announce the presence of one or more Mobile IP Foreign Agents. For each announced Foreign Agent, information is provided which is the same as that of the Mobile IP Agent Advertisement extension to ICMP Router Advertisements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levkowetz-dhc-mip-fa-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levkowetz-dhc-mip-fa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levkowetz-dhc-mip-fa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levkowetz-dhc-mip-fa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-levkowetz-dhc-mip-fa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130442.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 07:26:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18476 for ; Wed, 27 Feb 2002 07:26:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24906; Wed, 27 Feb 2002 05:25:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22571; Wed, 27 Feb 2002 04:25:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCOqKL008821 for ; Wed, 27 Feb 2002 04:24:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RCOqEA008820 for mobile-ip-dist; Wed, 27 Feb 2002 04:24:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCOkKL008813 for ; Wed, 27 Feb 2002 04:24:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12310 for ; Wed, 27 Feb 2002 04:24:48 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09383 for ; Wed, 27 Feb 2002 05:24:47 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18164; Wed, 27 Feb 2002 07:24:43 -0500 (EST) Message-Id: <200202271224.HAA18164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-bharatia-mobileip-v6-dns-ext-00.txt Date: Wed, 27 Feb 2002 07:24:43 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv6 Extension: Using DNS Servers Assigned by Home Agent Author(s) : J. Bharatia, K. Chowdhury Filename : draft-bharatia-mobileip-v6-dns-ext-00.txt Pages : 4 Date : 26-Feb-02 This draft provides an extension to Mobile IPv6 protocol where the Mobile Node (MN) obtains an information regarding DNS Servers from a home agent. This is achieved by defining a new extension of a Binding Acknowledgement message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bharatia-mobileip-v6-dns-ext-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bharatia-mobileip-v6-dns-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bharatia-mobileip-v6-dns-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bharatia-mobileip-v6-dns-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bharatia-mobileip-v6-dns-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130728.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 07:26:48 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18660 for ; Wed, 27 Feb 2002 07:26:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27352; Wed, 27 Feb 2002 04:26:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22737; Wed, 27 Feb 2002 04:26:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCPWKL008869 for ; Wed, 27 Feb 2002 04:25:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RCPW8F008868 for mobile-ip-dist; Wed, 27 Feb 2002 04:25:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCPRKL008858 for ; Wed, 27 Feb 2002 04:25:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22520 for ; Wed, 27 Feb 2002 04:25:29 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11068 for ; Wed, 27 Feb 2002 05:25:23 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18288; Wed, 27 Feb 2002 07:25:20 -0500 (EST) Message-Id: <200202271225.HAA18288@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-kempf-mobileip-postmit-handover-00.txt Date: Wed, 27 Feb 2002 07:25:20 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Post-handover Mobile Initiated Tunneling for Fast Mobile IPv4 Handover Author(s) : J. Kempf et al. Filename : draft-kempf-mobileip-postmit-handover-00.txt Pages : 6 Date : 26-Feb-02 The Mobile IP working group has been considering enhancements that significantly reduce the amount of service disruption involved in Mobile IP handover. The proposals considered by the working group so far are based on having Layer 2 information available prior to the handover that allows the Mobile Node and/or the old Foreign Agent to prepare for handover in some fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-mobileip-postmit-handover-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-kempf-mobileip-postmit-handover-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kempf-mobileip-postmit-handover-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-mobileip-postmit-handover-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-mobileip-postmit-handover-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130837.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 07:32:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19185 for ; Wed, 27 Feb 2002 07:32:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24777; Wed, 27 Feb 2002 05:25:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22536; Wed, 27 Feb 2002 04:25:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCOeKL008811 for ; Wed, 27 Feb 2002 04:24:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RCOeCr008810 for mobile-ip-dist; Wed, 27 Feb 2002 04:24:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RCOZKL008803 for ; Wed, 27 Feb 2002 04:24:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20496 for ; Wed, 27 Feb 2002 04:24:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09322 for ; Wed, 27 Feb 2002 05:24:36 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18119; Wed, 27 Feb 2002 07:24:33 -0500 (EST) Message-Id: <200202271224.HAA18119@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-bharatia-mobileip-v4-dns-ext-00.txt Date: Wed, 27 Feb 2002 07:24:33 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile IPv4 Extension: Using DNS Servers Assigned by Home Agent Author(s) : J. Bharatia, K. Chowdhury Filename : draft-bharatia-mobileip-v4-dns-ext-00.txt Pages : 4 Date : 26-Feb-02 This draft provides an extension to Mobile IPv4 protocol where the Mobile Node (MN) obtains an information regarding DNS Servers from a home agent. This is achieved by defining a new extension of a Registration Reply message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bharatia-mobileip-v4-dns-ext-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bharatia-mobileip-v4-dns-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bharatia-mobileip-v4-dns-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bharatia-mobileip-v4-dns-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bharatia-mobileip-v4-dns-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130703.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 09:25:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23873 for ; Wed, 27 Feb 2002 09:25:16 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18168; Wed, 27 Feb 2002 07:06:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00684; Wed, 27 Feb 2002 06:06:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RE5RKL009141 for ; Wed, 27 Feb 2002 06:05:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RE5Qwr009140 for mobile-ip-dist; Wed, 27 Feb 2002 06:05:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RE5MKL009133 for ; Wed, 27 Feb 2002 06:05:23 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1RE5Fx13081; Wed, 27 Feb 2002 15:05:15 +0100 (MET) Date: Wed, 27 Feb 2002 15:00:31 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7C12D3.13AA3CF7@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > - our intention (original anyway) was to provide a mechanism that did no > harm for Generic Nodes (GN) and worked for Mobile Nodes (ref Pekka > Nikander's note to the list). I am glad that we are now discussing > performance aspects and complexity of implementation. Good. Just to clarify where I am at. I'm first trying to understand how and whether it works. Then look at the complexity of the *protocols* and *mechanisms* to see if I personally think the complexity outweights the benefits or not. > - we see triangular routing as an option that serves two purposes. First, it > is an alternative to BDT when there is no BCE. Second, it can be a stepping > stone to RO. If a MN runs into performance issues (which BTW, depends on the > implementation as you seem to rightly imply below), it should consider RO! Yes, you'd like to take multiple steps to get to RO - I might prefer a single step to get to that desired endpoint :-) > - finally, we can specify exactly how tagging needs to work. One could argue > that details amount to complexity; however, latent complexity in the absence > of details is far worse (and perhaps dangerous). Agreed. Understanding all aspects of tagging is important to guage the added complexity. > It is a requirement. BTW, could you clarify what you mean wrt to RFC 2461 ? > I have the following paragraph from 2461 that seems to indicate that the > active working set needs to be preserved when garbage collecting. Also, how > do you re-build destination cache entries without running "next-hop > determination" ? Perhaps I am missing something.. You used the term "must" which is a lot stronger than RFC 2461 which talks about "care". And some of the language in that paragraph is incorrect in that discarding destination cache entries does not cause additional neighbor discovery messages - discarding *neighbor* cache entries too early will cause that. Next-hop determination is a local operation on the node. Thus per RFC 2461 a node can made the tradeoff between the space consumed by neighbor cache entries and the CPU time to recreate them by doing next-hop determination again. When doing so the node should take care to avoid discarding entries that have a path MTU less than the interface MTU, but RFC 2461 doesn't talk about that. > > If the CN doesn't allow the RO, then for how long time should the MN > > switch to BDT before trying to use an unverified HAO again? > > There seems to be a non-trivial performance tradeoff hiding in here. > > If the time until it tries again is too long then the communication > > might not see much of the claimed benefits of triagular, but if it > > is too short and the lack of space in the cache persists then there > > will be a packet lost for each time it tries to use an unverified HAO. > > > > IF the CN does not allow RO, then the MN should wait for a random period of > time before attempting unverified HAO again. Typically, random timeouts (or > even exponential backoff) help given the stochastic nature of the issue. Of > course, the MN may decide to simply continue with BDT. I think the packet > loss issue here is trivial. I think the issue is important. The goal of using triangular is to get some better performance without resorting to RO. If an MN that tries to get this performance benefit in reality sees a performance degradation because it needs to do random tries (causing packet loss) in order to get a cache entry on the CN, then why would an MN try this at all? So responding to comments about performance issues not being important when the whole purpose of the scheme is a performance optimization isn't productive IMHO. > > > a) packets without HAO overide the tagged entry > > I don't understand this rule. Are you saying that the reception of a packet > > without HAO should not effect the cache? That would conflict with c). > > Or are you saying that this should have some effect on something else? > > > > Sorry, I am saying when a CN receives packet without HAO, it removes the > tagged entry (i.e., the CoA). This means if an attacker created a tagged > entry using a GN's IP address, then receipt of a packet from the GN would > "repair" the entry so that outgoing packets will not be tagged. I now understand. > > Rule c) seems to say that unless the HAOs arrive frequently enough the > > cache entry will transition to no-tagging state, which will cause > > some packets to be dropped due to unverified HAO. > > This doesn't seem to be very robust against packet loss. > > At a minimum this time after which the state transition happens > > needs to be known by the MN so that e.g. if the MN knows that it > > sent the last unvHAO packet 10 seconds ago and the CN goes to no-tagging > > after 7 seconds, it should not send another unvHAO. > > But packet loss makes this hard. Continue assuming the CN goes to > > no-tagging after 7 seconds. > > If the MN sent the last unvHAO 4 seconds ago it should be ok to send > > another one, unless the first one was dropped by the network. > > How about if the MN sent unvHAO 2 seconds, 4 seconds, and 6 seconds ago? > > Then it is pretty sure that the CN hasn't transitioned to no-tagging > > state - it would only do so if there all 3 packets were lost. > > Sounds tricky - in a sense the unvHAO rules on the CN serve as a potential > > amplificator of packet loss in the network - packet loss in the network > > can cause additional packet loss/drops at the CN due to no-tagging state. > > > > This really depends on how you set the lifetime of the tagged entry. How so? Replace the "7" above with any other number between zero and infinity and what is different? > We > thought having it small would work well for an average case when the MN has > packets to send. It could be redefined taking expected packet transmission > rate into consideration. I would like to note that the MN loses a packet > when there is infrequent packet transmission _and_ network congestion; sort > of a "bad" case. I'm told wireless links cause packet loss unrelated to network congestion. > In any case, a simple extension may allow the CN to use > history to not drop the packet. More complexity? It seems like at a minimum the MN needs to know for how long it can assume the CN will keep the cache entry. Do you agree? > > Rule b) and c) seems to imply that if the MN happens to send a single packet > > without HAO to a CN then some number of packets will be dropped by the CN > > due to it having transitioned to no-tagging. > > This is rather constraining. For instance, a MN might wish to reverse-tunnel > > certain multicast packets with a HoA source thus those might arrive at > > the CN without a HAO. (This could be "fixed" by having the state on the CN > > be identified by the source (HoA) as well the destination address.) > > > > I didn't quite follow the text in parenthesis. Could you clarify ? The writeup doesn't explain what is the unique key that is used to identify a cache entry. Is it the CoA? The HoA? Any of those combined with the destination (CN) address? > > The 1a packet in the RR exchange (used to create and refresh RO) would > > also be reverse tunneled through the HA hence arrive without HAO. > > This would potentially cause a glitch when a MN wants to switch from > > using tringular to RO: > > MN sends data to CN using HAO - ok > > MN initiates RR exchange - sends 1a/1b > > CN receives 1a - transitions to no-tagging and sends 2a > > MN continues to send data to CN using HAO - dropped due to unvHAO > > MN recives 2a and 2b - sends BU to CN > > CN receives BU - creates BCE > > MN continues to send data to CN using HAO - accepted due to BCE > > Thus there is one round-trip during which the CN will drop packets. > > Here, you could include a bit in 1a that indicates to the CN that the MN is > using unverified HAO. The CN would then not transition to the no-tagging > state, and subsequently no packet losses. Yep - adding that piece of complexity would take care of this special case. > > Of course, this can be "fixed" by adding more complex rules to the MNs > > use of HAO. > > But the complexity is already quite high IMHO. > > > > I see your concerns are regarding performance. I think we can start with an > implementation note and then better understand values for configurable > parameters, mostly the lifetime of unverified BCE. I personally feel I need to get a more complete picture of what the proposal actually is in more detail so that I can personally evaluate whether I think the benefits outweigh the complexity. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 11:58:43 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02916 for ; Wed, 27 Feb 2002 11:58:42 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00373; Wed, 27 Feb 2002 08:58:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00702; Wed, 27 Feb 2002 08:58:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RGvFKL009309 for ; Wed, 27 Feb 2002 08:57:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RGvFwl009308 for mobile-ip-dist; Wed, 27 Feb 2002 08:57:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RGvBKL009301 for ; Wed, 27 Feb 2002 08:57:12 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1RGvBx16427; Wed, 27 Feb 2002 17:57:11 +0100 (MET) Date: Wed, 27 Feb 2002 17:52:25 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient To: Pekka.Nikander@nomadiclab.com Cc: rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7CAD40.9030104@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I agree with this analysis. And I am not ruling out the > RR with share secret option. Sure you can use it if you > want to; however, I do not see any *practical* security > difference between RR only and RR with shared secret. > RR with some sort of authentication is clearly different, > since it would require some external property or party > to base the authentication on. Pekka, I suspect that Rajeev's point is that the performance of RR with shared secret is better than plain RR while keeping the security the same. So let me look at that in more detail. In RR each movement takes 1.5 roundtrips 1a/2a doing RR check on the HoA 1b/2b doing RR check on the CoA and they are done in parallel The BU from MN to CN With RR with shared secret the HoA check (1a/2a) does not need to be done each time a MN moves since the established shared secret indicates to the CN that is it the same MN. But as you point out the the timing aspects of this means that the CN needs to verify that the MN is reachable at the HoA at some minimum frequency of a few minutes. However, it doesn't have to do that HoA RR check at the time of movement. Thus at movement (assuming a HoA RR check has been done in the last few minutes) it simplifies to 1b/2b doing RR check on the CoA The BU from MN to CN This is is less messages but still 1.5 roundtrip. Of course, there are cases when the roundtrip time between CN and CoA are significantly less than the roundtrip time one the CN-HA-MN path used for the HoA RR check. Taking an example out of the air: the roundtrip time on the wireless interface is 60 ms the wired roundtrip time from MN to CN is 10 ms the wired roundtrip time from MN to HA is 200 ms (different continent) and the wired roundtrip time from HA to CN is also 200ms Thus the MN-CN rtt is 70 ms The MN-HA-CN rtt is 460 ms With RR the 1/2 step takes 460 ms followed by the BU one-way delay of 35 ms Sum 595 ms With RR-shared-secret the 1/2 step takes 70 ms followed by the BU one-way delay of 35 ms Sum 105 Thus almost a factor 6 better in this intercontinental case. The question is how much does it cost (CPU time) to create the BSA and for how long time case the BSA be kept. How to compare the security of e.g. a random shared secret sent in the clear in a packet that goes on the CN-HA-MN path (to benefit from the encryption on the HA-MN part of the path), compared to a D-H exchange? Can the BSA have a relatively long lifetime (hours) as long as the HoA RR check is performed every few minutes in order to verify the binding between the BSA and the HoA? If a D-H key exchange needs to be performed every few minutes then it isn't clear to me that the improvements in the BU time are worth while, but if we can do something less CPU intensive every few minutes it might very well be worth-while. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 12:14:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03966 for ; Wed, 27 Feb 2002 12:14:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01069; Wed, 27 Feb 2002 10:13:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04824; Wed, 27 Feb 2002 09:13:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHCtKL009387 for ; Wed, 27 Feb 2002 09:12:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RHCs7X009386 for mobile-ip-dist; Wed, 27 Feb 2002 09:12:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHCpKL009379 for ; Wed, 27 Feb 2002 09:12:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06791 for ; Wed, 27 Feb 2002 09:12:54 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08383 for ; Wed, 27 Feb 2002 10:12:52 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g1RHCIk12578; Wed, 27 Feb 2002 18:12:18 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA11620; Wed, 27 Feb 2002 18:12:18 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g1RHCIg79022; Wed, 27 Feb 2002 18:12:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200202271712.g1RHCIg79022@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] draft-dupont-ipsec-mipv6-00.txt Date: Wed, 27 Feb 2002 18:12:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I wrote a draft explaining "how to make IPsec more mobile IPv6 friendly". Please send comments to me or to the IPsec mailing list, *not* the mobile-ip mailing list *please*. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 12:22:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04437 for ; Wed, 27 Feb 2002 12:21:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05849; Wed, 27 Feb 2002 10:21:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07361; Wed, 27 Feb 2002 09:21:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHKtKL009454 for ; Wed, 27 Feb 2002 09:20:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RHKtCY009453 for mobile-ip-dist; Wed, 27 Feb 2002 09:20:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHKpKL009446 for ; Wed, 27 Feb 2002 09:20:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08472 for ; Wed, 27 Feb 2002 09:20:54 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05192 for ; Wed, 27 Feb 2002 10:20:53 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1RHKqe11542; Wed, 27 Feb 2002 09:20:52 -0800 (PST) Message-ID: <006201c1bfb2$e2543d60$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7CAD40.9030104@nomadiclab.com> Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient Date: Wed, 27 Feb 2002 09:19:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, I mostly agree with you, except for the following. > Let me express the same argument from a different point of > view: In today's Internet the hosts are *identified* > by the IP address (and I purposefully say identified and > not merely named). The reason why this works so well, and > why we have fairly few connection hijacking and MitM problems, > is the fact that the routing system uses the addresses > directly. That is, given a packet sent to a given address, > only those nodes that are at the path between the sender > and the topological location named by the address are able > to see and act on the packet. > I think a more important reason why there aren't any MiTM problems is because it is physically hard to hijack a connection to a router. You have to break into someone's secure installation and put a tap on one of the router's input wires. With 802.11 and other multiaccess wireless systems, it becomes much easier. ARP spoofing is very easy. In fact, if you have ever used MobileStar, the 802.11 public access network, they have an explicit disclaimer on their Web page that you are responsible for security, they aren't. >On the other hand, > there may be new attacks that we do not know of, such > attacks that RR only is vulnerable but RR + shared > secret is not. > See draft-kempf-ipng-netaccess-threats-00.txt. The host on the wireless link can mount a redirect attack away from the default router and act as a MitM, if the link is multiaccess. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 12:24:36 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04521 for ; Wed, 27 Feb 2002 12:24:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07477; Wed, 27 Feb 2002 10:24:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08142; Wed, 27 Feb 2002 09:24:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHNaKL009504 for ; Wed, 27 Feb 2002 09:23:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RHNaJl009503 for mobile-ip-dist; Wed, 27 Feb 2002 09:23:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHNXKL009493 for ; Wed, 27 Feb 2002 09:23:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13992 for ; Wed, 27 Feb 2002 09:23:35 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06861 for ; Wed, 27 Feb 2002 10:23:34 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 209D5A; Wed, 27 Feb 2002 19:25:26 +0200 (EET) Message-ID: <3C7D1614.9040003@nomadiclab.com> Date: Wed, 27 Feb 2002 19:23:32 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020221 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > I suspect that Rajeev's point is that the performance of RR > with shared secret is better than plain RR while keeping the security the same. > So let me look at that in more detail. [analysis proper removed] > Thus almost a factor 6 better in this intercontinental case. Erik and Rejeev, Of course I have to agree with the analysis. If there are indeed cases where one changes bindings at a generic CN more often than the maximum RR binding lifetime, then setting up a BSA even with RR leads to performance benefits. I just wasn't thinking from thas point of view, I just tried to make the "one bit" argument more thorough. The question now rises: does this possible performance difference require any changes to the one bit analysis? That is, if we think that from the _security_ point of view RR-only and RR-with-shared-secret are equivalent, can't we just use one unauthenticated bit, somewhere in the message 1a and not in the address, to indicate whether the MN wants to set up an RR based BSA? I am not quite sure (too tired right now), but I think we could do just that. > The question is how much does it cost (CPU time) to create the BSA > and for how long time case the BSA be kept. > How to compare the security of e.g. a random shared secret sent in the clear > in a packet that goes on the CN-HA-MN path (to benefit from the > encryption on the HA-MN part of the path), compared to a D-H exchange? These are good questions, indeed. I think Jari A. and Tuomas discussed the latter point (D-H vs clear text secret) in depth at some point of time, but I don't remember any more what the outcome was. I remember that at that time I argued that I didn't see any added value from D-H. D-H just requires that the attacker is an active one; sending a clear text secret (in pieces) allows even a passive attacker to learn the secret. > Can the BSA have a relatively long lifetime (hours) as long as the HoA RR > check is performed every few minutes in order to verify the binding > between the BSA and the HoA? I think such a BSA could well live for quite a long time, it renewed often enough. > If a D-H key exchange needs to be performed every few minutes then it isn't > clear to me that the improvements in the BU time are worth while, but > if we can do something less CPU intensive every few minutes it might > very well be worth-while. Agreed. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 12:35:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05110 for ; Wed, 27 Feb 2002 12:35:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27740; Wed, 27 Feb 2002 10:35:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11254; Wed, 27 Feb 2002 09:35:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHYYKL009572 for ; Wed, 27 Feb 2002 09:34:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RHYYM0009571 for mobile-ip-dist; Wed, 27 Feb 2002 09:34:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHYUKL009564 for ; Wed, 27 Feb 2002 09:34:30 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1RHYSx22712; Wed, 27 Feb 2002 18:34:28 +0100 (MET) Date: Wed, 27 Feb 2002 18:29:42 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient To: Pekka Nikander Cc: Erik Nordmark , rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7D1614.9040003@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [My context is now re-established - sorry for the side-track into the cost-benefit tradeoffs for RR-shared-secret] > The question now rises: does this possible performance difference > require any changes to the one bit analysis? That is, if we think > that from the _security_ point of view RR-only and RR-with-shared-secret > are equivalent, can't we just use one unauthenticated bit, somewhere > in the message 1a and not in the address, to indicate whether the MN > wants to set up an RR based BSA? I am not quite sure (too tired > right now), but I think we could do just that. I agree that RR-only and RR-shared-secret should have the same security properties so that the one-bit method doesn't need to change as a result of introducing RR-shared-secret. The request for a BSA for RR could e.g. be done by one unauthenticated bit in 1a as you propose. > I think such a BSA could well live for quite a long time, it renewed > often enough. What does "renewed" mean? A new shared secret? Or a re-verification that an entity reachable at the HoA knows the shared secret? Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 12:54:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06313 for ; Wed, 27 Feb 2002 12:54:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25004; Wed, 27 Feb 2002 10:54:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24808; Wed, 27 Feb 2002 09:54:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHmeKL009672 for ; Wed, 27 Feb 2002 09:48:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RHmeMm009669 for mobile-ip-dist; Wed, 27 Feb 2002 09:48:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RHmYKL009649 for ; Wed, 27 Feb 2002 09:48:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23108 for ; Wed, 27 Feb 2002 09:48:21 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19172 for ; Wed, 27 Feb 2002 09:48:20 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 88639A; Wed, 27 Feb 2002 19:50:12 +0200 (EET) Message-ID: <3C7D1BE3.9090409@nomadiclab.com> Date: Wed, 27 Feb 2002 19:48:19 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020221 X-Accept-Language: en-us MIME-Version: 1.0 To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Difference between RR-only and RR-with-shared-secret (was Re: [mobile-ip] Design team note: ....) References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7CAD40.9030104@nomadiclab.com> <006201c1bfb2$e2543d60$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, [I changed the subject to better reflect what we really are discussing.] I don't see where we disagree: >> Let me express the same argument from a different point of >> view: In today's Internet the hosts are *identified* >> by the IP address (and I purposefully say identified and >> not merely named). The reason why this works so well, and >> why we have fairly few connection hijacking and MitM problems, >> is the fact that the routing system uses the addresses >> directly. That is, given a packet sent to a given address, >> only those nodes that are at the path between the sender >> and the topological location named by the address are able >> to see and act on the packet. > > I think a more important reason why there aren't any MiTM problems > is because it is physically hard to hijack a connection to a router. > You have to break into someone's secure installation and put a > tap on one of the router's input wires. To me that looks like the flip side of the same coin. Since the Internet is based on the addresses-are-identifiers system, only routers (or local hosts doing ARP spoofing etc) are able to mishandle packets flowing between two given addresses. And since breaking into routers is hard, in general, these two properties together give us fairly good security. To me it looks like we agree so far. Or where is the disagreement? My point here is, in large, that with mobility we have to break this addresses-are-identifiers system, in one way or another. [Alternatively we could change the routing system completely.] Breaking the binding between locators (addresses) and connection end-points, as such, necessarily leads to new security vulnerabilities. The exact nature of the vulnerabilities depend on how, exactly, we break the addresses-are-identifiers system. > With 802.11 and other multiaccess wireless systems, it becomes much > easier. ARP spoofing is very easy. I know and I agree. You have changed your physical security enviroment. You get new vulnerabilities. Sure. >> On the other hand, >> there may be new attacks that we do not know of, such >> attacks that RR only is vulnerable but RR + shared >> secret is not. > > See draft-kempf-ipng-netaccess-threats-00.txt. The host > on the wireless link can mount a redirect attack away > from the default router and act as a MitM, if the link > is multiaccess. I have read it. Maybe I should read it again. But right now I don't remember anything there that would make a significant difference between RR-only and RR-with-shared-secret. Oh well, yes, there is one, at least: If an attacker is not on the CN-HA path when the MN and CN start to communicate, but comes there later, there definitely is a difference. For the mobile CN's, Francis Dupond suggested long ago that some of the BU signalling should be carried through the CN's Home Agent, using a secure bi-directional tunnel. That would fix some of the security problems when the CN is at a wireless unsecure link. What comes to the MN link, I don't immediately see how RR-with-shared-secret would protect the MN better than RR-only. But maybe I am just too tired. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 13:05:26 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06902 for ; Wed, 27 Feb 2002 13:05:26 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19011; Wed, 27 Feb 2002 10:05:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29591; Wed, 27 Feb 2002 10:05:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RI3wKL009732 for ; Wed, 27 Feb 2002 10:03:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RI3w9S009731 for mobile-ip-dist; Wed, 27 Feb 2002 10:03:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RI3tKL009724 for ; Wed, 27 Feb 2002 10:03:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07459 for ; Wed, 27 Feb 2002 10:03:58 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00733 for ; Wed, 27 Feb 2002 11:03:56 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 9C104A; Wed, 27 Feb 2002 20:05:47 +0200 (EET) Message-ID: <3C7D1F8A.1080703@nomadiclab.com> Date: Wed, 27 Feb 2002 20:03:54 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.8+) Gecko/20020221 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: rajeev@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed and why it is sufficient References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit >> I think such a BSA [created through RR] could well live for quite >> a long time, it renewed often enough. > > What does "renewed" mean? A new shared secret? Or a re-verification that > an entity reachable at the HoA knows the shared secret? Hmm. I think re-verification that the peer entity is still reachable through HoA and still knows the shared secret is sufficient. Creating a new shared secret would be overkill, IMHO, and require a more complex protocol since the new secret would need to be bound to the previous one. Actually, I don't immediately see how creating a new secret would increase security. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 13:25:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08349 for ; Wed, 27 Feb 2002 13:25:15 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12824; Wed, 27 Feb 2002 11:25:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07277; Wed, 27 Feb 2002 10:25:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RINqKL009820 for ; Wed, 27 Feb 2002 10:23:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RINpUZ009819 for mobile-ip-dist; Wed, 27 Feb 2002 10:23:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RINlKL009812 for ; Wed, 27 Feb 2002 10:23:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27545 for ; Wed, 27 Feb 2002 10:23:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11932 for ; Wed, 27 Feb 2002 11:23:47 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14608; Wed, 27 Feb 2002 10:23:44 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RINiE23592; Wed, 27 Feb 2002 10:23:44 -0800 X-mProtect:  Wed, 27 Feb 2002 10:23:44 -0800 Nokia Silicon Valley Messaging Protection Received: from dhcp-3-111.iprg.nokia.com (205.226.3.111, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8VSx9g; Wed, 27 Feb 2002 08:13:14 PST Message-ID: <3C7D0571.D8104EF6@iprg.nokia.com> Date: Wed, 27 Feb 2002 08:12:33 -0800 From: Charlie P Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com, rajeev@iprg.nokia.com, eanderlind@lucent.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> <3C7CB3AD.4000206@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Pekka, Pekka Nikander wrote: > I acknowledge that our current understanding is that > they are *practically* equivalent, but that understanding > may change as we learn more. RR may be equivalent in security strength to RR+shared_secret, but (as Erik notes) the latter offers better performance because then the mobile node can send a Binding Update with authentication data using the shared secret. This will improve handover performance. If we can get better performance for the same security, then I think we should do so. It is also possible to use RR+shared_secret as an interim Binding Security Association for the several hundred milliseconds until an infrastructure identity authentication can complete. > What you describe above is more or less equal with our original BAKE design. > > Later on Tuomas Aura, Michael Roe and Jari Arkko analyzed the situation > more, and found new attacks that the design above does not block > adequately. The basic issue is in timing and the ability > to use these timing problems to move attacks into the future, > and thereby making tracking the attackers considerably harder. > I think Jari Arkko documented the analysis in one of his Design > Team notes/recommendations, but I don't remember in which one. Jari? I think that the vulnerability can be smaller with the newer design. Moreover, this is something we can finalize later, but for now we should just keep in mind that establishing the shared secret (perhaps using additional protocol to minimize risk) will enable secure operation of future Binding Updates. Or we may decide that the vulnerability with RR+shared_secret is no greater than the vulnerability without, or perhaps no greater than with nonmobile nodes today ("do no harm"). There is work left to do on this. I can mention one final possibility that has merit. We could arrange that the RR+shared_secret gives a "one-time" shared_secret. This would help performance at the next handover, but the mobile node would then have to run RR again for the "next" next handover. But we can do this after March. Comments? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 14:07:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10848 for ; Wed, 27 Feb 2002 14:07:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19228; Wed, 27 Feb 2002 12:07:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09427; Wed, 27 Feb 2002 11:07:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJ68KL009915 for ; Wed, 27 Feb 2002 11:06:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RJ67tZ009914 for mobile-ip-dist; Wed, 27 Feb 2002 11:06:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJ64KL009907 for ; Wed, 27 Feb 2002 11:06:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09059; Wed, 27 Feb 2002 11:06:06 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29868; Wed, 27 Feb 2002 11:06:04 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22182; Wed, 27 Feb 2002 11:06:01 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RJ61222983; Wed, 27 Feb 2002 11:06:01 -0800 X-mProtect:  Wed, 27 Feb 2002 11:06:01 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgqDO5u; Wed, 27 Feb 2002 11:05:59 PST Message-ID: <3C7D2E17.848DE5A9@iprg.nokia.com> Date: Wed, 27 Feb 2002 11:05:59 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Erik, Erik Nordmark wrote: > > > > > IF the CN does not allow RO, then the MN should wait for a random period of > > time before attempting unverified HAO again. Typically, random timeouts (or > > even exponential backoff) help given the stochastic nature of the issue. Of > > course, the MN may decide to simply continue with BDT. I think the packet > > loss issue here is trivial. > > I think the issue is important. The goal of using triangular is to get > some better performance without resorting to RO. If an MN that tries > to get this performance benefit in reality sees a performance degradation > because it needs to do random tries (causing packet loss) in order to > get a cache entry on the CN, then why would an MN try this at all? > > So responding to comments about performance issues not being important > when the whole purpose of the scheme is a performance optimization > isn't productive IMHO. > Oops.. I didn't mean to imply that perfromance is not important. In this particular case (i.e., the CN does not support RO), when the MN receives a BR with request for BDT, I think the MN should continue using BDT for a random period and try again. Just as there might be packet loss again, there might not be any packet loss. In fact, I think using a random timeout helps. Another thought: the CN could actually process this particular packet (i.e., not drop it) _without_ creating an unverified BCE and then generate a BR. > > > > > > > This really depends on how you set the lifetime of the tagged entry. > > How so? Replace the "7" above with any other number between zero and infinity > and what is different? > If you set the entry large enough, inspite of infrequent packet transmission and packet losses, the CN would still be in tagging state. > > > We > > thought having it small would work well for an average case when the MN has > > packets to send. It could be redefined taking expected packet transmission > > rate into consideration. I would like to note that the MN loses a packet > > when there is infrequent packet transmission _and_ network congestion; sort > > of a "bad" case. > > I'm told wireless links cause packet loss unrelated to network congestion. Point taken. Even so, transport level retransmission would get the packet out to CN. Since bit errors are the predominant reason for packet loss in wireless, a scheme such as udp-lite could greatly improve reliability even when there is no transport level retransmission. > > > > In any case, a simple extension may allow the CN to use > > history to not drop the packet. > > More complexity? > It depends on how you see it. Just as you keep the PMTU when you purge, you can keep a flag associated with the tag indicating recent entry expiration. > > It seems like at a minimum the MN needs to know for how long it can assume > the CN will keep the cache entry. Do you agree? It certainly helps if the MN knew about this. I don't know how best to convey this to the MN..If it didn't, the protocol should still work with the caveat that a packet would be lost. But, if we can live with the CN not dropping it (e.g, because it has history), may be that's another option. I need to think this through further. > > > > > Rule b) and c) seems to imply that if the MN happens to send a single packet > > > without HAO to a CN then some number of packets will be dropped by the CN > > > due to it having transitioned to no-tagging. > > > This is rather constraining. For instance, a MN might wish to reverse-tunnel > > > certain multicast packets with a HoA source thus those might arrive at > > > the CN without a HAO. (This could be "fixed" by having the state on the CN > > > be identified by the source (HoA) as well the destination address.) > > > > > > > I didn't quite follow the text in parenthesis. Could you clarify ? > > The writeup doesn't explain what is the unique key that is > used to identify a cache entry. > Is it the CoA? The HoA? Any of those combined with the destination (CN) > address? > HoA is the key. CoA is the tag. > > > > The 1a packet in the RR exchange (used to create and refresh RO) would > > > also be reverse tunneled through the HA hence arrive without HAO. > > > This would potentially cause a glitch when a MN wants to switch from > > > using tringular to RO: > > > MN sends data to CN using HAO - ok > > > MN initiates RR exchange - sends 1a/1b > > > CN receives 1a - transitions to no-tagging and sends 2a > > > MN continues to send data to CN using HAO - dropped due to unvHAO > > > MN recives 2a and 2b - sends BU to CN > > > CN receives BU - creates BCE > > > MN continues to send data to CN using HAO - accepted due to BCE > > > Thus there is one round-trip during which the CN will drop packets. > > > > Here, you could include a bit in 1a that indicates to the CN that the MN is > > using unverified HAO. The CN would then not transition to the no-tagging > > state, and subsequently no packet losses. > > Yep - adding that piece of complexity would take care of this special case. > More generally, if non-HAO packets are due to mobility signaling, then we can handle them in the above fashion. > > > > Of course, this can be "fixed" by adding more complex rules to the MNs > > > use of HAO. > > > But the complexity is already quite high IMHO. > > > > > > > I see your concerns are regarding performance. I think we can start with an > > implementation note and then better understand values for configurable > > parameters, mostly the lifetime of unverified BCE. > > I personally feel I need to get a more complete picture of what the proposal > actually is in more detail so that I can personally evaluate whether I think > the benefits outweigh the complexity. > Ok. I will give the write-up a try. In the meanwhile, Charlie's original text described the tagging proposal. I also have some other text (other than tag-or-not.txt) that I will include in the write-up. Regards, -Rajeev > > Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 14:09:43 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11036 for ; Wed, 27 Feb 2002 14:09:42 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07508; Wed, 27 Feb 2002 11:09:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10070; Wed, 27 Feb 2002 11:09:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJ8hKL009989 for ; Wed, 27 Feb 2002 11:08:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RJ8hJ5009988 for mobile-ip-dist; Wed, 27 Feb 2002 11:08:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJ8eKL009981 for ; Wed, 27 Feb 2002 11:08:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03288 for ; Wed, 27 Feb 2002 11:08:42 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19929 for ; Wed, 27 Feb 2002 12:08:41 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22357 for ; Wed, 27 Feb 2002 11:08:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RJ8em28525 for ; Wed, 27 Feb 2002 11:08:40 -0800 X-mProtect:  Wed, 27 Feb 2002 11:08:40 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdi6O9kE; Wed, 27 Feb 2002 11:08:36 PST Message-ID: <3C7D2EB4.67644EC7@iprg.nokia.com> Date: Wed, 27 Feb 2002 11:08:36 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> <3C7CB3AD.4000206@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > Such an added byte, signaling the options that the sender wants > to use, is being added to the forthcoming DT design. Thus, the > idea is to use the "one bit" method signal whether RR may be > used or not, and an external, explicitly authenticated data field > to signal other options, including the set of more secure BU > authorization methods that the host would be willing to use. this is good Pekka. agree with this. the "one bit" method says RR or non-RR and the actual strong BU authorization mechanism is signaled through a byte in the BU. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 14:21:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11834 for ; Wed, 27 Feb 2002 14:21:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27050; Wed, 27 Feb 2002 12:21:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28651; Wed, 27 Feb 2002 11:21:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJKWKL010159 for ; Wed, 27 Feb 2002 11:20:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RJKWCI010158 for mobile-ip-dist; Wed, 27 Feb 2002 11:20:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJKTKL010151 for ; Wed, 27 Feb 2002 11:20:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08453 for ; Wed, 27 Feb 2002 11:20:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15258 for ; Wed, 27 Feb 2002 12:20:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA23666; Wed, 27 Feb 2002 11:20:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RJKMQ18713; Wed, 27 Feb 2002 11:20:22 -0800 X-mProtect:  Wed, 27 Feb 2002 11:20:22 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdgvw3AZ; Wed, 27 Feb 2002 11:20:19 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id LAA02698; Wed, 27 Feb 2002 11:20:20 -0800 (PST) Message-ID: <3C7D3174.E1CFEA84@iprg.nokia.com> Date: Wed, 27 Feb 2002 11:20:20 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C317A.1DA9F6C@iprg.nokia.com> <3C7CB118.6040807@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, Thanks for your sharp observations. One point was not clear, though. Knowledge or RR and non-RR address refering to the _same_ host is needed to provide the crucial interoperation by RR you refer to. Providing this mapping is hard. Either it is also a priori knowledge needed for every address for the one bit to provide the interoperation. Or, making it implicit cascades lots of change requirements to other places. Comments and examples below. > > - Is routing identity encoding by 1 bit in host number > > really the only way to let CN know of MN's minimal BU > > authorization method? Perhaps to let CN know the policy by > > local configuration could be alternatives? If a local > > configuration were considered as an additive alternative, > > it could straightforwardly also support bidding aside > > unlike the 1 bit, woulnd't it? > > As I already wrote in length in the answer to Rajeev's message, > we were only considering the situation where the MN and the > CN do not have any a priori knowledge and do not rely on some > external infrastructure. Local configuration is always possible, > and could be classified as a priori knowledge. There is one category of a priori knowledge not necessarily stated in the analysis, relevant to both points in this discussion. In order to reach a particular node and provide the interoperation you are discussing below, a direct consequence of identity encoding is that one needs to be aware of two identities and them associating with the same end node. Knowledge of this implicit association is one kind of a priori knowledge, that is, that two addresses mean the particular host must be known, for the interoperation (fallback to RR address) you describe below to work. Making the duality implicit brings new problems. One needs to map this to places with one reference to a host (e.g., address based URLs or DNS gives the IP address). If no non-RR method is available, and an URL or DNS name maps to such an address, what address does the CN then guess to use? E.g., if we mandate that the other address (negating the bit) always maps to the same host, this is a rule for DNS, etc. Thus, either there needs to be a-priori static configuration of the mapping in the CN or the change requirements from making this dual address use implicit cascades to many places, DNS being one example if using a rule speculated above. Looking to all this change requirement now seems a lot of undone work. > > - While fully agreeing on the significant conceptual > > difference between bidding down and aside, I would like > > to better understand the issue why bidding aside is > > insignificant. Basically, is there no difference > > in level of security or desirability of authorization > > among the higher class methods? > > There could be differences between the "higher" level > security methods. As we stated in the analysis, we > consider "bidding aside" *less significant* (not > insignificant) for two reasons: > > 1. RR is strictly less secure > > 2. The other suggested methods have some kind of > authentication, i.e. they add some external > knowledge that we rely on, in order to determine > that there is a binding between the MN and its > Home Address. > > But sure "bidding aside" *can* be a problem. Local > configuration is a clear answer to that: if a CN > does not trust on, e.g. CGA, it can turn it completely > off. The only consequence of this is that CGA-only > MNs must either note use RO or obtain a new home address that > allows RR only. > > > What about a practical case there is a "lemon" amongst > > the multiple methods available among the higher class > > of methods. If this would be the weakest link among > > the set of methods in this class, wouldn't that make security > > of the whole class shrink to that level without a bidding > > aside method to "shut down" such a method? > > You are right in your analysis. However, we must place this > question in the right context: the purpose of RR is to > place a minimum baseline that ensures us *interoperability*. > Other methods can be seen as optional, providing added > security. Since RR poses the threat of "bidding down", and > since all nodes must support RR for interoperability reasons, > we do need a built in mechanism for signalling that RR must > not be used. This allows an MN to try to use a more secure > mechanism in the first place. If that fails, it can always > fall back to RR through using a separate Home Address. Consequences of this discussed in the note above. > (Side note: If there was another infrastructureless > way of preventing bidding down, I'd be more than happy > to use it. I am not particularly fond of the "one bit" > method. It just seems to be the only one that works.) If one agrees the address association (one RR one non RR address refers to the same host) represents one type of a priori knowledge, static configuration should in principle be an alternative. > The second section in the analysis tried to point out that > it is possible to support multiple, *roughly equivalent* > methods, without requiring more bits to be reserved. The > crusial point here is that rough equivalence. Our understanding > on what methods are roughly equivalent and what are not may > change over time, but IMHO that can be handled through > local configuration. Agreed. If differences are later observed, local configuration can be applied. Also, continuing from this, applicability of local configuration to even the RR/non-RR axis later on seems equivalently feasible. > --Pekka BR, -Jari M From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 14:30:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12386 for ; Wed, 27 Feb 2002 14:30:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18245; Wed, 27 Feb 2002 12:30:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01448; Wed, 27 Feb 2002 11:29:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJTHKL010389 for ; Wed, 27 Feb 2002 11:29:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RJTH7F010388 for mobile-ip-dist; Wed, 27 Feb 2002 11:29:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJTEKL010381 for ; Wed, 27 Feb 2002 11:29:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01265 for ; Wed, 27 Feb 2002 11:29:12 -0800 (PST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07084 for ; Wed, 27 Feb 2002 11:29:11 -0800 (PST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1RJTAR14095 for ; Wed, 27 Feb 2002 14:29:10 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA17221; Wed, 27 Feb 2002 14:29:07 -0500 (EST) To: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, pekka.nikander@nomadiclab.com Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA17214; Wed, 27 Feb 2002 14:29:06 -0500 (EST) Message-ID: <3C7D3383.F83FD54B@lucent.com> Date: Wed, 27 Feb 2002 14:29:07 -0500 From: Erik Anderlind X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Original-To: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> <3C7CB3AD.4000206@nomadiclab.com> <3C7D2EB4.67644EC7@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay and Pekka, Vijay Devarapalli wrote: > Pekka Nikander wrote: > > Such an added byte, signaling the options that the sender wants > > to use, is being added to the forthcoming DT design. Thus, the > > idea is to use the "one bit" method signal whether RR may be > > used or not, and an external, explicitly authenticated data field > > to signal other options, including the set of more secure BU > > authorization methods that the host would be willing to use. > > this is good Pekka. agree with this. the "one bit" method says > RR or non-RR and the actual strong BU authorization mechanism > is signaled through a byte in the BU. I fail to see how we would authenticate the "BU security method" negotiation byte. The MN and CN still don't share any common secret. Only through use of one of the proposed binding security methods could one eventually authenticate the byte. A more pragmatic approach would be for one party to propose the BU security binding options it is prepared to accept (but could be modified during transfer by MitM). The other party chooses among these methods according to its policy preferences. The 2nd party then attempts to run the BU security scheme. If a MitM interfered in the negotiation, the scheme will fail and the MN and CN can choose to a) retry (perhaps with fewer options) b) only communicate via HA c) stop communication (hostile situation detected) d) establish encryption etc I don't see any benefit of having a 2 phase process where the first phase is only whether one of the RR alternatives is acceptable or not. Why not propose all the alternatives at once? (We clearly believe many hosts will want more than RR.) ...Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 14:35:24 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12685 for ; Wed, 27 Feb 2002 14:35:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14185; Wed, 27 Feb 2002 11:35:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03303; Wed, 27 Feb 2002 11:35:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJYBKL010472 for ; Wed, 27 Feb 2002 11:34:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RJYB4d010471 for mobile-ip-dist; Wed, 27 Feb 2002 11:34:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RJY8KL010464 for ; Wed, 27 Feb 2002 11:34:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15991 for ; Wed, 27 Feb 2002 11:34:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21645 for ; Wed, 27 Feb 2002 12:34:08 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24580; Wed, 27 Feb 2002 11:34:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RJY4909418; Wed, 27 Feb 2002 11:34:04 -0800 X-mProtect:  Wed, 27 Feb 2002 11:34:04 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHrHr7i; Wed, 27 Feb 2002 11:34:03 PST Message-ID: <3C7D34AC.147EFB20@iprg.nokia.com> Date: Wed, 27 Feb 2002 11:34:04 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Anderlind CC: mobile-ip@sunroof.eng.sun.com, pekka.nikander@nomadiclab.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> <3C7CB3AD.4000206@nomadiclab.com> <3C7D2EB4.67644EC7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Anderlind wrote: > I fail to see how we would authenticate the "BU security method" > negotiation byte. The MN and CN still don't share any common > secret. Only through use of one of the proposed binding > security methods could one eventually authenticate the byte. The section "2. Why the "one bit" is sufficient?" in Pekka's writeup explains this. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 15:53:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17320 for ; Wed, 27 Feb 2002 15:53:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28548; Wed, 27 Feb 2002 13:53:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07384; Wed, 27 Feb 2002 12:53:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RKpXKL010691 for ; Wed, 27 Feb 2002 12:51:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RKpXCV010690 for mobile-ip-dist; Wed, 27 Feb 2002 12:51:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RKpTKL010683 for ; Wed, 27 Feb 2002 12:51:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04481 for ; Wed, 27 Feb 2002 12:51:32 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26673 for ; Wed, 27 Feb 2002 13:51:31 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA00017 for ; Wed, 27 Feb 2002 12:51:30 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RKpTR11574 for ; Wed, 27 Feb 2002 12:51:29 -0800 X-mProtect:  Wed, 27 Feb 2002 12:51:29 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAyPw8l; Wed, 27 Feb 2002 12:51:27 PST Message-ID: <3C7D46CF.FCC048CC@iprg.nokia.com> Date: Wed, 27 Feb 2002 12:51:27 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] Changes to RFC 3012bis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, A new revision has been prepared for this Internet Draft. Below, please find a summary of the changes. Regards, Charlie P. ====================================================================== A. Changes since Last Revision Here is a list of the important changes since the previous revision of this document. - Changes section added. - Clarified ordering rules for adding the Challenge extension in section 3.1. - Definitions for Stale Challenge, etc. in section 1.1 have been clarified to avoid misinterpretations that could cause dropped registrations. - Used "Code value" field name instead of "error code" to be compatible with RFC 3220. - Used Authentication Extension names compatible with RFC 3220. - Updated document citations. - Clarified nature of message to Authorization Infrastructure in appendix C. - Added message flows to Home Agent in appendix C. - Specified that NAI has to remain the same in order for a Registration Request to be considered a retransmission. - Clarified that padding is NOT added if the input data is shorter than 237 bytes. - Replaced IANA Considerations with a statement that the numbers should stay the same. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 16:12:06 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18536 for ; Wed, 27 Feb 2002 16:12:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05724; Wed, 27 Feb 2002 13:11:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15774; Wed, 27 Feb 2002 13:11:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RL9vKL010786 for ; Wed, 27 Feb 2002 13:09:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RL9vp4010785 for mobile-ip-dist; Wed, 27 Feb 2002 13:09:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RL9sKL010778 for ; Wed, 27 Feb 2002 13:09:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05674 for ; Wed, 27 Feb 2002 13:09:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24782 for ; Wed, 27 Feb 2002 13:09:51 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA01294 for ; Wed, 27 Feb 2002 13:09:50 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RL9o808276 for ; Wed, 27 Feb 2002 13:09:50 -0800 X-mProtect:  Wed, 27 Feb 2002 13:09:50 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd60T4LI; Wed, 27 Feb 2002 13:09:48 PST Message-ID: <3C7D4B1D.25A9C449@iprg.nokia.com> Date: Wed, 27 Feb 2002 13:09:49 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] Revised version of AAA keys document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, The AAA keys document has been substantially revised with a number of major changes. Here is the summary of the changes, taken from the new appendix in the AAA keys draft. If there are comments on these changes, I can try to incorporate them before Friday. I will try to put the draft on my web page as soon as it becomes available again (darn power hits...). The URL will be: http://people.nokia.net/txt/mobilekey/mip-key.txt Regards, Charlie P. ========================================================================== A. Changes Since Previous Revision In this revision of the document, there have been several major changes as a result of suggestions received during Last Call. - Generalized Key Extensions previously specified in another document have been instead specified in this document in order that this document can be self-contained and not dependent on the standardization status of the other document. - Additional explanation has been included for the purposes of clarifying the problem space and solution approach. - An appendix has been added to describe the expected AAA infrastructure that will produce the keys that are to be distributed within the extensions specified in this document. - Ladder diagrams have been included to illustrate the expected message flows containing the extensions defined in this document. - HMAC-MD5 has been mandated for implementation by the mobile node, for compatibility with RFC 3220 [12]. The example text has been modified accordingly (see section 5). - A table of Algorithm Identifiers has been identified as the numbering space for algorithm selection when establishing the security association using the keys distributed with the extensions in this document. See section 4. - A terminology section has been added. - This appendix has been added. From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 16:47:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20658 for ; Wed, 27 Feb 2002 16:47:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05509; Wed, 27 Feb 2002 14:47:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27290; Wed, 27 Feb 2002 13:47:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RLkQKL010915 for ; Wed, 27 Feb 2002 13:46:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1RLkPRj010914 for mobile-ip-dist; Wed, 27 Feb 2002 13:46:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1RLkMKL010907 for ; Wed, 27 Feb 2002 13:46:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18119 for ; Wed, 27 Feb 2002 13:46:25 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21012 for ; Wed, 27 Feb 2002 14:46:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA04218; Wed, 27 Feb 2002 13:46:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1RLkNR02477; Wed, 27 Feb 2002 13:46:23 -0800 X-mProtect:  Wed, 27 Feb 2002 13:46:23 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0XpaEh; Wed, 27 Feb 2002 13:46:21 PST Message-ID: <3C7D53AE.3751773F@iprg.nokia.com> Date: Wed, 27 Feb 2002 13:46:22 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7CAD40.9030104@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, > Thank you for the elucidation. It is apparent that RR with shared secret is a good option from a performance point of view. I would only like to add that secret re-verification can be combined (whenever necessary) with HoA RR test. Regards, -Rajeev From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 19:14:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25347 for ; Wed, 27 Feb 2002 19:14:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00720; Wed, 27 Feb 2002 17:13:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02020; Wed, 27 Feb 2002 16:13:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S0CcKL011140 for ; Wed, 27 Feb 2002 16:12:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S0CcQP011139 for mobile-ip-dist; Wed, 27 Feb 2002 16:12:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S0CZKL011132 for ; Wed, 27 Feb 2002 16:12:35 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09714 for ; Wed, 27 Feb 2002 16:12:37 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09639 for ; Wed, 27 Feb 2002 16:12:33 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1S0Ebx18704 for ; Wed, 27 Feb 2002 18:14:37 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 18:12:31 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 18:11:43 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] [ISSUE] Design team recommendation: New recommendation on piggybacking X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 18:11:42 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12879@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Design team recommendation: New recommendation on piggybacking Thread-Index: AcG+T8AmAnytfKVAQtGcDd0NEzxO9ABnIvRQ To: Cc: X-OriginalArrivalTime: 28 Feb 2002 00:11:43.0072 (UTC) FILETIME=[806A4600:01C1BFEC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1S0CZKL011133 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit >3. RECOMMENDATIONS > >The design team recommends the following: > >R1. A Separate protocol and/or port should be used for the BR > message, all RR messages, BU message and BA message. This > will allow - but not mandate - the use of current IPsec > selectors in protecting BUs to the CN and HA, and RR > messages via the HA. The value of next protocol = none > must be supported by all MIPv6 compliant nodes in these > messages. > Agree. >R2. Reserve some space for preference bits in the RR messages > 1a and 1b, to allow the CN and the MN to describe their > preferences. Only the space is reserved, but no meaning > is assigned to the bits. > > The potential use of those bits is to allow a CN, for > instance, tell the MN that it allows the reception of > piggybacked signaling. However, compliant nodes can leave > all the bits as zero. This is necessary in order to allow > implementations that do not have the API between MIPv6 and > IPsec. > Can agree with the following change: Rather than simply reserving space, if the meaning to these bits is assigned. > There is also other potential use of the bits, e.g. > selecting some variants of stronger BU authorization > methods, but these are not discussed here. > >R3. The above two recommendations should be placed in the > MIPv6 RFC. This would allow us to quickly proceed to RFC > status by bypassing controversial content, have as simple > RFC and implementations as possible, but still allow > functionality like piggybacking to be specified without > interoperability concerns, and used by all nodes who > support it. > Agree. >R4. Separate RFCs would define the use of these bits. For > example, their use in piggybacking would need to define > the following: > > - Allocate a bit in the reserved space in the RR messages > 1a/2a, and describe its semantics. > - Describe in detail which messages can use piggybacking, > if it is allowed, and under which conditions. > - Rules for sending the optional payload along. > - Rules for receiving the optional payload. > - Rules on what to check from the IPsec policy > before deciding to use piggybacking. Same comment as for recommendation R2. >R5. At a future time, IF IPsec selectors can be extended in > some manner, the RFC described under R4 could be updated > to extend the rules under which piggybacking is possible > i.e. no IPsec checks would be necessary any more. > Agree. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 19:14:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25376 for ; Wed, 27 Feb 2002 19:14:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02390; Wed, 27 Feb 2002 17:14:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02217; Wed, 27 Feb 2002 16:14:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S0DlKL011162 for ; Wed, 27 Feb 2002 16:13:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S0DlE5011161 for mobile-ip-dist; Wed, 27 Feb 2002 16:13:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S0DiKL011154 for ; Wed, 27 Feb 2002 16:13:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15216 for ; Wed, 27 Feb 2002 16:13:46 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA21701 for ; Wed, 27 Feb 2002 17:13:45 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA15410; Wed, 27 Feb 2002 16:13:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1S0DiS03977; Wed, 27 Feb 2002 16:13:44 -0800 X-mProtect:  Wed, 27 Feb 2002 16:13:44 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdPqk5qb; Wed, 27 Feb 2002 16:13:43 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id QAA02978; Wed, 27 Feb 2002 16:13:42 -0800 (PST) Message-ID: <3C7D7636.C2784F9E@iprg.nokia.com> Date: Wed, 27 Feb 2002 16:13:42 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Pekka Nikander Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C317A.1DA9F6C@iprg.nokia.com> <3C7CB118.6040807@nomadiclab.com> <3C7D3174.E1CFEA84@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, To describe the remaining double identity interoperation concern hopefully more clearly, a concrete example of the downside of the 1-bit (identity) encoding from interoperation viewpoint below. [Pekka wrote] > > Since RR poses the threat of "bidding down", and > > since all nodes must support RR for interoperability reasons, > > we do need a built in mechanism for signalling that RR must > > not be used. This allows an MN to try to use a more secure > > mechanism in the first place. If that fails, it can always > > fall back to RR through using a separate Home Address. Scenario: a legacy CN1 knows only RR, a new CN2 knows RR and a method X. CN1 can't get interoperable address at all from DNS because MN's name maps only to one address allowing X. The compatibility does not work here for RO with the legacy CN1, and MN cannot just start using a separate address for any application. Consider MN runs a web server and its DNS name is encoded, say, into icon URLs on its homepage. If this name maps to the address allowing X, MN would need a separate homepage encoding another DNS name for RR address to serve the legacy node with RO. And so on, for different services mapping or passing single addresses to CNs. Here, since applications 'hard-code' single identity for MN, RO using RR with MN does not work at all with _any_ node after the moment MN changes its identity to the new one requiring X. This even though MN would have another identity for RR, e.g., to be able to do RO with legacy nodes, or by a policy, e.g., use RR with nodes inside its firewall-protected domain. If MN falls back to RR, either the above effect happens with applications, or there needs to be some 'configuration' or implicit rule that maps the new identity to MN's RR-identity for legacy nodes (CN switches the addresses transparently) for these legacy CNs to be able to do RR with the X-address MN when using those applications. I hope the bidding down issue could be closed soon. However, the above concern motivates that at least an alternative (static config) would be there and that possible limitations of the 1-bit are understood and recorded, well enough to explain how it really works for legacy support. > > --Pekka BR, -Jari M From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 19:18:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25565 for ; Wed, 27 Feb 2002 19:18:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04087; Wed, 27 Feb 2002 17:18:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03597; Wed, 27 Feb 2002 16:18:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S0HTKL011442 for ; Wed, 27 Feb 2002 16:17:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S0HTiP011441 for mobile-ip-dist; Wed, 27 Feb 2002 16:17:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S0HPKL011434 for ; Wed, 27 Feb 2002 16:17:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27327 for ; Wed, 27 Feb 2002 16:17:28 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12057 for ; Wed, 27 Feb 2002 17:17:27 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1S0HZZ23130 for ; Thu, 28 Feb 2002 02:17:35 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 02:17:26 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 02:17:25 +0200 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 18:17:22 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] [Consensus] Design team recommendation: New recommendation on piggybacking X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 18:17:22 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1287A@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Design team recommendation: New recommendation on piggybacking Thread-Index: AcG+T8AmAnytfKVAQtGcDd0NEzxO9ABnMlzQ To: X-OriginalArrivalTime: 28 Feb 2002 00:17:22.0870 (UTC) FILETIME=[4AF35560:01C1BFED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g1S0HQKL011435 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, The design team recommendation posted on Feb 25th has not been contested (other than the minor issue I raised w.r.t the bits specifying the piggybacking option), which would imply that we have consensus on the recommendation. We would like to close this issue by 5 PM March 1st. If you have any issues with the DT recommendation, please bring them to the attention of the DT and the WG. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Feb 27 21:18:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28650 for ; Wed, 27 Feb 2002 21:18:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15214; Wed, 27 Feb 2002 19:18:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15997; Wed, 27 Feb 2002 18:18:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S2FIKL011875 for ; Wed, 27 Feb 2002 18:15:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S2FIg2011874 for mobile-ip-dist; Wed, 27 Feb 2002 18:15:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S2FGKL011867 for ; Wed, 27 Feb 2002 18:15:17 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05216 for ; Wed, 27 Feb 2002 21:15:13 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id VAA08430 for mobile-ip@sunroof.eng.sun.com; Wed, 27 Feb 2002 21:16:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S1pIKL011806 for ; Wed, 27 Feb 2002 17:51:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24210 for ; Wed, 27 Feb 2002 17:51:19 -0800 (PST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14585 for ; Wed, 27 Feb 2002 18:51:19 -0700 (MST) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g1S1pIgB019504 for ; Wed, 27 Feb 2002 18:51:18 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.10.2+Sun/8.10.2) id g1S1pH829904 for mobile-ip@sunroof.eng.sun.com; Wed, 27 Feb 2002 18:51:17 -0700 (MST) Date: Wed, 27 Feb 2002 18:51:17 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200202280151.g1S1pH829904@ece2.ece.arizona.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobicom 2002 - Final CFP Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: *************************************************************** [Appologies if you receive duplicates of this message] Please note the following changes in this CFP: - Paper submission details have been revised. - A Student Poster Session has been added. - Student travel grants are now available. See below for details. *************************************************************** F I N A L C A L L F O R P A P E R S *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Paper Submission Deadline (EXTENDED): March 8, 2002 ******** No further extensions will be given ********* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: ------- Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: ------------------ Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. **REVISED SUBMISSION INSTRUCTIONS**: ------------------------------------ All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. No other format will be accepted. Papers must meet the following restrictions: - The paper must be original material that has not been previously published nor is currently under review by another conference or journal. - Full papers should be no longer than *15 pages*, in font no smaller than 10 points. (Note that accepted papers, when formatted for the proceedings, may not exceed 12 pages in font no smaller than 9 points). - Challenges papers should be no longer than 8 pages, in font no smaller than 10 points. - All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names *must not* appear in the paper. - The paper should fit properly on US Letter-sized paper (8.5x11 inches) - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier, Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file - The paper must be formatted for b/w printers and not color printers. Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ TUTORIALS: ---------- Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: ------- Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: --------------- Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). ** STUDENT POSTER SESSION **: --------------------------- The conference solicits student posters that highlight recent and on-going research by students on mobile computing topics. Proposals should be a maximum of two pages in length. While it does not need to describe completed work, the poster paper should report on research that is beyond the initial stages. The first author of a poster submission must be a student. Poster abstracts will not be published in the proceedings but will instead be published on the web before the conference. Poster submissions will be reviewed. Authors of accepted papers must not submit a poster of the work they present in the conference. For more information about student poster applications contact the Student Poster Co-chairs (ebelding@cs.ucsb.edu or sjlee@hpl.hp.com). **STUDENT TRAVEL AWARDS**: -------------------------- MobiCom will offer a limited number of travel grants to support students. Please contact Student Travel Awards Co-Chairs for application details (fang@ece.ufl.edu or syrotiuk@utdallas.edu). BEST STUDENT PAPER AWARD: ------------------------- Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: ---------------- * Paper submissions due: March 8, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 * Tutorial proposals: May 1, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu EXECUTIVE COMMITTEE: -------------------- * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Mercury Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Co-Chairs: - Suresh Singh, Portland State University - Robin Kravets, University of Illinois, Urbana-Champaign * Student Poster Co-Chairs: - Elizabeth M. Belding-Royer, University of California, Santa Barbara - Sung-Ju Lee, HP Laboratories * Student Travel Award Co-Chairs: - Yuguang Fang, University of Florida - Violet R. Syrotiuk, University of Texas at Dallas * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Webmaster: Michael E. Kounavis, Columbia University PROGRAM COMMITTEE: -------------------- Program Co-Chairs: - Vaduvur Bharghavan, Bessemer Venture Partners - Andrew T. Campbell, Columbia University Program Committee: - Arup Acharya, IBM Research - Prathima Agrawal, Telcordia - B. R. Badrinath, Rutgers University - Victor Bahl, Microsoft Research - Stefano Basagni, Northeastern University - Roberto Battiti, University of Trento - Pravin Bhagwat, ReefEdge - Chatschik Bisdikian, IBM Research - Scott Corson, Flarion - Sajal Das, University Texas at Arlington - Nigel Davies, Lancaster University - Dan Duchamp, Stevens Institute of Technology - Maria Ebling, IBM Research - Magda El-Zarki, University of California, Irvine - Anthony Ephremides, University of Maryland - Deborah Estrin, University of California, Los Angeles - J.J. Garcia-Luna-Aceves, University of California at Santa Cruz - Mario Gerla, University of California, Los Angeles - Ramesh Govindan, USC/ISI - Ravi Jain, Telcordia - David B. Johnson, Rice University - Anthony Joseph, University of California, Berkeley - Edward Knightly, Rice University - Tom LaPorta, Lucent Technologies - Songwu Lu, University of California, Los Angeles - Robert Morris, MIT - S. Muthukrishnan, AT&T Research - Brian Noble, University of Michigan - Venkat Padmanabhan, Microsoft Research - Charles Perkins, Nokia - Chiara Petrioli, University "La Sapienza" - George Polyzos, Athens University of Economics and Business - Parmesh Ramanathan, University of Wisconsin - Madison - Ram Ramanathan, BBN Technologies - Ramachandran Ramjee, Lucent Technologies - Daniela Rus, Dartmouth College - Srinivasan Seshan, Carnegie Mellon University - Kang G. Shin, University of Michigan - Suresh Singh, Portland State University - Mani Srivastava, University of California, Los Angeles - Frank Stajano, AT&T Laboratories Cambridge - Martha Steenstrup, Stow Research - Violet R. Syrotiuk, University of Texas at Dallas - Leandros Tassiulas, University of Maryland - Nitin H. Vaidya, University of Illinois at Urbana-Champaign - Andras Valko, Ericsson Research - Adam Wolisz, Technical University of Berlin - Michele Zorzi, Universita di Ferrara From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 02:33:47 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13618 for ; Thu, 28 Feb 2002 02:33:46 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07452; Wed, 27 Feb 2002 23:33:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03741; Wed, 27 Feb 2002 23:33:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7WUKL012415 for ; Wed, 27 Feb 2002 23:32:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S7WUov012414 for mobile-ip-dist; Wed, 27 Feb 2002 23:32:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7WRKL012407 for ; Wed, 27 Feb 2002 23:32:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15156 for ; Wed, 27 Feb 2002 23:32:27 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA28042 for ; Thu, 28 Feb 2002 00:32:26 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id B09F4A; Thu, 28 Feb 2002 09:34:16 +0200 (EET) Message-ID: <3C7DDCD3.8080105@nomadiclab.com> Date: Thu, 28 Feb 2002 09:31:31 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: "Jari T. Malinen" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C317A.1DA9F6C@iprg.nokia.com> <3C7CB118.6040807@nomadiclab.com> <3C7D3174.E1CFEA84@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, This discussion is very interesting, since it leads all the time to new observations. My suggestion of using two home addresses, one allowing RR and the other one not allowing RR, was just a quick idea, without too much backing thinking. Based on your comments I've made a few of observations. Firstly, if a MN uses two such Home Addresses, the two Home Addresses cannot share a common routing prefix. If they did, an attacker on the path between the CN and the HA could easily block the communication using the non-RR HoA, thereby re-creating the bidding down situation. Thus, in order to be effective at all, the Home Agents used for the two-HoA method *must* be at topologically different locations, and *must* have different enough routing prefixes. Secondly, we (or at least I) have concentrated on the case where the MN contacts a CN, and wants to do RO. Furthermore, we have assumed that the CN wants to serve the MN in any case; e.g., the CN could be a public server of some kind. In that case the CN does not have any a priori knowledge about the MN. Furthermore, in that case there is no need for the CN to know that the two addresses refer to the same MN. In general, I don't understand why there should be such a mapping in *any* case where the MN initiates the connection. To the CN it looks like that first one node tries to initiate RO, and that failing, suddenly another node tries to initiate RO. No problem here. Or at least I don't see any problems, maybe you do. Thus, ... ... > though. Knowledge or RR and non-RR address refering to the > _same_ host is needed to provide the crucial interoperation > by RR you refer to. Providing this mapping is hard. Either ... > Knowledge of this implicit association is one kind of a priori > knowledge, that is, that two addresses mean the > particular host must be known, for the interoperation > (fallback to RR address) you describe below to work. ..., I disagree with these statements of yours. To emphasise my point even more: Most hosts in the IPv6 world do have several addresses (a link local address, maybe a site local address, and one or more globally routable addresses). Nowhere in the IPv6 specs, to my knowledge (I may be wrong), is there a requirement that a peer *should* be able to map these different addresses to the same node. It *may*, for sure, but that is not a requirement, AFAIK. Now, in the cases where the CN contants the MN, the CN *does* have some a priori knowledge about the MN. It needs to get MN's address(es) from somewhere; at minimum the address(es) must be entered by a user, but more typically it/they will be learned from the DNS, through SIP, or though some other infrastructural means. If this is the case, the infrastructure could carry information about the possibly multiple addresses the MN has, and about the RO authorization methods it supports. Thus, in that case there is no real need for the one bit method. > .... One needs > to map this to places with one reference to a host (e.g., > address based URLs or DNS gives the IP address). If no non-RR > method is available, and an URL or DNS name maps to such > an address, what address does the CN then guess to use? In this particular case the CN could select the RO authorization method it wants to use, based on the addresses and other information learned from the DNS/whatever. What comes to address based URLs, how likely they will be in the IPv6 world? I don't know, but I doubt that they would be used very often in any other cases but where the server itself hands it over to the client. > E.g., if we mandate that the other address (negating the bit) > always maps to the same host, this is a rule for DNS, etc. As you see above, I am not saying anything like that. You just can't have two addresses otherwise same but that one bit, since it would allow an attacker to block the more secure of the addresses, thereby creating another variant of the bidding down attack. Thus, if a MN uses two different Home Addresses, one for RR and one for non-RR RO, the two addresses necessarily need to be fairly independent of each other. On the other hand, DNS or other such infrastructure can carry the two addresses together, just like the MN were multi-homed at the two Home Addresses. Taking yet another approach, I honestly do not know how useful the two-HoA method would be in the first place. If a MN does not want to use RR for security reasons, it should not fall back to RR in any case, and rely on non-RO if it cannot authenticate its binding updates. On the other hand, if a MN is willing to use RR but also supports other methods, it could use an RR-allowing address *and* indicate in the BU messages that it also supports stronger methods. In that case it exposes itself to the bidding down danger, but that is a reasonable choice. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 02:39:20 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13692 for ; Thu, 28 Feb 2002 02:39:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA08710; Wed, 27 Feb 2002 23:39:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04485; Wed, 27 Feb 2002 23:39:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7ccKL012473 for ; Wed, 27 Feb 2002 23:38:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S7ccTw012472 for mobile-ip-dist; Wed, 27 Feb 2002 23:38:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7cZKL012465 for ; Wed, 27 Feb 2002 23:38:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25523 for ; Wed, 27 Feb 2002 23:38:35 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15238 for ; Thu, 28 Feb 2002 00:38:34 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id DA306A; Thu, 28 Feb 2002 09:40:26 +0200 (EET) Message-ID: <3C7DDE45.8090002@nomadiclab.com> Date: Thu, 28 Feb 2002 09:37:41 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Anderlind Cc: mobile-ip@sunroof.eng.sun.com, vijayd@iprg.nokia.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> <3C7CB3AD.4000206@nomadiclab.com> <3C7D2EB4.67644EC7@iprg.nokia.com> <3C7D3383.F83FD54B@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > I fail to see how we would authenticate the "BU security method" > negotiation byte. The MN and CN still don't share any common > secret. Only through use of one of the proposed binding > security methods could one eventually authenticate the byte. Vijay already answered this. If you have further questions, don't hesitate to ask. > A more pragmatic approach would be for one party to propose > the BU security binding options it is prepared to accept ... > I don't see any benefit of having a 2 phase process where > the first phase is only whether one of the RR alternatives > is acceptable or not. Why not propose all the alternatives at once? > (We clearly believe many hosts will want more than RR.) I didn't consider these kinds of negotiations at all when I wrote our analysis text. Sure you can do more advanced negotiation than just propose one choice, take it or not. There was quite a lot of interesting related discussion at the ipsec list some time ago, when people were discussing various negotiation methods for the forthcoming son-of-IKE. If you want to really understand the security implications of these kinds of propose-first-and-authenticate-later methods, that discussion would probably be a good place to start. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 02:52:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13932 for ; Thu, 28 Feb 2002 02:52:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA10942; Wed, 27 Feb 2002 23:52:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05953; Wed, 27 Feb 2002 23:52:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7pcKL012543 for ; Wed, 27 Feb 2002 23:51:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S7pbW0012542 for mobile-ip-dist; Wed, 27 Feb 2002 23:51:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7pYKL012535 for ; Wed, 27 Feb 2002 23:51:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05237 for ; Wed, 27 Feb 2002 23:51:31 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20647 for ; Thu, 28 Feb 2002 00:51:30 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 7E849A; Thu, 28 Feb 2002 09:53:21 +0200 (EET) Message-ID: <3C7DE14B.2040207@nomadiclab.com> Date: Thu, 28 Feb 2002 09:50:35 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: "Jari T. Malinen" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C317A.1DA9F6C@iprg.nokia.com> <3C7CB118.6040807@nomadiclab.com> <3C7D3174.E1CFEA84@iprg.nokia.com> <3C7D7636.C2784F9E@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari, I think I answered already mostly in my previous message, but let me briefly look at these scenarios, too. Maybe we can learn something new from these. ;-) > Scenario: a legacy CN1 knows only RR, a new CN2 knows RR and a > method X. CN1 can't get interoperable address at all from DNS > because MN's name maps only to one address allowing X. The > compatibility does not work here for RO with the legacy CN1, > and MN cannot just start using a separate address for any > application. IMHO, if the MN's name maps only to one address that doesn't allow RR, then that is a choice made by the MN. It does not want to use RR. No more need to discuss here. :-) > Consider MN runs a web server and its DNS name is encoded, say, > into icon URLs on its homepage. If this name maps to the address > allowing X, MN would need a separate homepage encoding another > DNS name for RR address to serve the legacy node with RO. And so Why the MN's DNS name can't map into multiple addresses, provided that it wants to support both RR-based and non-RR based RO? AFAIK, several addresses is perfectly valid practise already today. If the CN uses DNS to resolve the addresses, it anyway needs to select which address to use. I think Richard Draves is working on the I-Ds discussing address selection, or maybe that is already an RFC, I don't remember. Thus, if the one-bit method is accepted, the address selection I-D/RFC must be updated. Or we need a new one explaining the choices a "new" CN has to make. Good new point. :-) > on, for different services mapping or passing single addresses > to CNs. Here, since applications 'hard-code' single identity > for MN, RO using RR with MN does not work at all with _any_ node > after the moment MN changes its identity to the new one > requiring X. This even though MN would have another identity > for RR, e.g., to be able to do RO with legacy nodes, or by a > policy, e.g., use RR with nodes inside its firewall-protected > domain. I still don't understand this "single address" business at all. To me it has been clear for quite some time that in the IPv6 world the hosts will have multiple addresses, and it is perfectly legal that a host thinks to be communicating with multiple peers even though, in reality, it is talking to a single one. > If MN falls back to RR, either the above effect happens with > applications, or there needs to be some 'configuration' or > implicit rule that maps the new identity to MN's RR-identity for > legacy nodes (CN switches the addresses transparently) for these > legacy CNs to be able to do RR with the X-address MN when using > those applications. I am sorry, but the text above does not make any sense to me. I just don't understand how you are thinking. > I hope the bidding down issue could be closed soon. However, the > above concern motivates that at least an alternative (static > config) would be there and that possible limitations of the > 1-bit are understood and recorded, well enough to explain > how it really works for legacy support. I sure hope that the bidding down issue is closed soon, too. Now, would you Jari, in turn, explain how you think that static configuration could be made to scale to internet wide operations where MNs connect to CNs, and the CNs do not know the MNs a priori? --Pekka From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 02:58:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13978 for ; Thu, 28 Feb 2002 02:58:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23741; Thu, 28 Feb 2002 00:58:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05982; Wed, 27 Feb 2002 23:57:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7vEKL012633 for ; Wed, 27 Feb 2002 23:57:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S7vEi7012632 for mobile-ip-dist; Wed, 27 Feb 2002 23:57:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S7vBKL012625 for ; Wed, 27 Feb 2002 23:57:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05873 for ; Wed, 27 Feb 2002 23:57:11 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20358 for ; Wed, 27 Feb 2002 23:57:11 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id A3957A; Thu, 28 Feb 2002 09:59:02 +0200 (EET) Message-ID: <3C7DE2A0.1050107@nomadiclab.com> Date: Thu, 28 Feb 2002 09:56:16 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: Charlie P Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Why the "one bit" is needed ...-RR secrets References: <697DAA22C5004B4596E033803A7CEF44A1278B@daebe007.NOE.Nokia.com> <3C75E853.20906@piuha.net> <3C7B8989.2070602@nomadiclab.com> <3C7C2B07.3CD16029@iprg.nokia.com> <3C7C3F4D.FAFF1195@lucent.com> <3C7CB3AD.4000206@nomadiclab.com> <3C7D0571.D8104EF6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, ... > It is also possible to use RR+shared_secret as an interim > Binding Security Association for the several hundred milliseconds > until an infrastructure identity authentication can complete. ... > I think that the vulnerability can be smaller with the newer design. > Moreover, this is something we can finalize later, but for now we > should just keep in mind that establishing the shared secret (perhaps > using additional protocol to minimize risk) will enable secure operation > of future Binding Updates. ... > I can mention one final possibility that has merit. We could arrange > that the RR+shared_secret gives a "one-time" shared_secret. This > would help performance at the next handover, but the mobile node > would then have to run RR again for the "next" next handover. ... > Comments? Good points. I don't have any comments. Or maybe one. Whatever we do in order to finalize MIPv6 for RFC status, IMHO we should try to keep the base design as minimal and as simple as possible, but leave doors wide open for various kinds of extensions and options. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 04:29:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15345 for ; Thu, 28 Feb 2002 04:29:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01658; Thu, 28 Feb 2002 02:28:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05679; Thu, 28 Feb 2002 01:28:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S9R9KL012809 for ; Thu, 28 Feb 2002 01:27:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1S9R9IS012808 for mobile-ip-dist; Thu, 28 Feb 2002 01:27:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S9R4KL012801 for ; Thu, 28 Feb 2002 01:27:05 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1S9R1x29166; Thu, 28 Feb 2002 10:27:01 +0100 (MET) Date: Thu, 28 Feb 2002 10:22:12 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7D2E17.848DE5A9@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Oops.. I didn't mean to imply that perfromance is not important. In this > particular case (i.e., the CN does not support RO), when the MN receives a > BR with request for BDT, I think the MN should continue using BDT for a > random period and try again. Just as there might be packet loss again, there > might not be any packet loss. In fact, I think using a random timeout helps. > Another thought: the CN could actually process this particular > packet (i.e., not drop it) _without_ creating an unverified BCE and then > generate a BR. I don't think that addresses the robustness problems I see. Let's draw parallels between the unvHAO cache and the binding cache. Both are going to be of finite size thus there will be cases when a new entry can't be made. In the BC case this will be signalled to the MN - the BU will receive a BAck with a failure code. Thus the MN will actually know whether it has an entry in the BC or not (subject to the CN not crashing or otherwise loosing all state). In the unvHAO case the MN seems to need to operate in pray and hope mode - it sends a packet with a HAO and hopes that there is room for an unvHAO cache entry. I see two ways of making this more robust: 1. An explicit roundtrip between the MN and CN to create the unvHAO cache entry i.e. the MN will get an ack when the entry has been created. This means that no packets will be dropped by the CN (subject to the CN not crashing or otherwise loosing all state). 2. An unvHAO arriving when there isn't room to create a cache entry results in an error going back to the MN. This means that one roundtrip worth of data packets can be dropped by the CN until the MN is notified to stop sending HAO packets. > > How so? Replace the "7" above with any other number between zero and infinity > > and what is different? > > > > If you set the entry large enough, inspite of infrequent packet > transmission and packet losses, the CN would still be in tagging state. That doesn't change any fundamentals - merely what frequence of communication is subject to the loss propagation/expansion. For instance if the unvHAO cache lifetime is one day then applications which look for the news once per day would be subjected to this loss expansion. And you've said the lifetime needs to be fairly short so I don't think one day makes any sense - I believe we are talking about lifetimes that are less than a few minutes, right? > Point taken. Even so, transport level retransmission would get the packet > out to CN. > Since bit errors are the predominant reason for packet loss in wireless, a > scheme such as udp-lite could greatly improve reliability even when there is > no transport level retransmission. I can't tell whether you agree with my point that the unvHAO logic you've expressed is causing loss expansion in some cases where packet loss will cause the unvHAO cache entry to time out causing packets to be dropped by the CN. I also can't tell whether you agree with my point that the MN needs to know how long its unvHAO will we kept by the CN in the absense of the CN receiving any matching packets. > > It seems like at a minimum the MN needs to know for how long it can assume > > the CN will keep the cache entry. Do you agree? > > It certainly helps if the MN knew about this. I don't know how best to > convey this to the MN..If it didn't, the protocol should still work with the > caveat that a packet would > be lost. But, if we can live with the CN not dropping it (e.g, because it has > history), may be that's another option. I need to think this through further. Do you have a staw-man proposal for how the history would work? How much information are we talking about? How is it maintained by the CN? > > The writeup doesn't explain what is the unique key that is > > used to identify a cache entry. > > Is it the CoA? The HoA? Any of those combined with the destination (CN) > > address? > > > > HoA is the key. CoA is the tag. In that case my point applies. > More generally, if non-HAO packets are due to mobility signaling, then we can > handle them in the above fashion. Yes, this could all be special cased. But it doesn't address other cases of non-HAO packets. My other example was a multicast packet sent by the MN that, for whatever reasons, is reverse tunneled. The MN doesn't even know that this particular CN is a member of the multicast group. Yet the reception of that non-HAO packet causes the erasure of the unvHAO cache which will cause packets with HAO to be dropped. Special cases isn't necessarily the best path forward IMHO. > Ok. I will give the write-up a try. In the meanwhile, Charlie's original text > described the tagging proposal. I also have some other text (other than > tag-or-not.txt) that I will include in the write-up. Great. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 09:19:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24241 for ; Thu, 28 Feb 2002 09:19:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14066; Thu, 28 Feb 2002 06:19:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16909; Thu, 28 Feb 2002 06:18:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SEI2KL013335 for ; Thu, 28 Feb 2002 06:18:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SEI2Op013334 for mobile-ip-dist; Thu, 28 Feb 2002 06:18:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SEHvKL013327 for ; Thu, 28 Feb 2002 06:17:58 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1SEHux25714; Thu, 28 Feb 2002 15:17:56 +0100 (MET) Date: Thu, 28 Feb 2002 15:13:09 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, Pekka Nikander In-Reply-To: "Your message with ID" <3C7D7636.C2784F9E@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Scenario: a legacy CN1 knows only RR, a new CN2 knows RR and a > method X. CN1 can't get interoperable address at all from DNS > because MN's name maps only to one address allowing X. The > compatibility does not work here for RO with the legacy CN1, > and MN cannot just start using a separate address for any > application. Jari, Correct. The simple case is that the MN as a unit decides to use either a RR or a non-RR address. In the case where more flexibility is needed the MN can maintain both types of addresses. For communication initiated by the MN the applications and/or protocol stack on the MN can choose between the two source addresses based on local policy on the MN. For communication not initiated by the MN other mechanisms can be used. But I think there are plenty of such mechanisms that at least allow different choice of addresses (and implied security level for BUs) based on the "service". For example, the MN could decide which of the addresses to register with SIP servers. The MN could have two DNS names (insecure.mylaptop.example vs. mylaptop.example) that map to the two different addresses. SRV records could be used so that e.g. _sip._tcp.mylaptop.example gives the non-RR address while _http._tcp.mylaptop.example gives the RR address So I think common cases when MNs want different tradeoffs between who they can use RO with (old vs. new CNs) and the security level of the BUs can be handled. Sure, this requires additional configuration as well as additional code in the MNs to choose and verify the addresses used (the latter in order to prevent a SIP connection to the RR address in the above example). But this is a case where the MN that wants such multiple IP address identities have to pay with some additional complexity it its implementation, which I think is a reasoanble tradeoff. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 09:24:09 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24508 for ; Thu, 28 Feb 2002 09:24:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15080; Thu, 28 Feb 2002 06:24:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18061; Thu, 28 Feb 2002 06:24:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SENQKL013407 for ; Thu, 28 Feb 2002 06:23:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SENQA8013406 for mobile-ip-dist; Thu, 28 Feb 2002 06:23:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SENLKL013399 for ; Thu, 28 Feb 2002 06:23:22 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1SENLx26019; Thu, 28 Feb 2002 15:23:21 +0100 (MET) Date: Thu, 28 Feb 2002 15:18:34 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient To: Pekka.Nikander@nomadiclab.com Cc: "Jari T. Malinen" , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7DE14B.2040207@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Why the MN's DNS name can't map into multiple addresses, provided > that it wants to support both RR-based and non-RR based RO? Pekka, I don't understand how that can be used to prevent bidding down. If the MN e.g. runs a web server on http://laptop.example and laptop.example has both a RR and a non-RR IP address record in the DNS, then it seems like the MN, for that service, is willing to live with the threats of allowing RR BUs. Thus it is sufficient to have just the RR address in the DNS as far as I can tell. But having multiple different identifiers of the service (different URLs => hostnames, or different SRV records) point to different IP addresses *plus* the MN verifying that a connection to a service uses the right IP address for that service seems reasonable. > AFAIK, several addresses is perfectly valid practise already today. > If the CN uses DNS to resolve the addresses, it anyway needs > to select which address to use. I think Richard Draves is > working on the I-Ds discussing address selection, or maybe that > is already an RFC, I don't remember. > > Thus, if the one-bit method is accepted, the address selection > I-D/RFC must be updated. Or we need a new one explaining > the choices a "new" CN has to make. Good new point. :-) If you believe my argument above then the CN never needs to choose. Instead the MN chooses by what IP address it registers (in DNS or elsewhere) for each service. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 09:48:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25897 for ; Thu, 28 Feb 2002 09:48:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17224; Thu, 28 Feb 2002 07:48:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21056; Thu, 28 Feb 2002 06:48:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SElaKL013477 for ; Thu, 28 Feb 2002 06:47:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SElaAo013476 for mobile-ip-dist; Thu, 28 Feb 2002 06:47:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SElXKL013469 for ; Thu, 28 Feb 2002 06:47:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23475 for ; Thu, 28 Feb 2002 06:47:33 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20866 for ; Thu, 28 Feb 2002 07:47:32 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 98699A; Thu, 28 Feb 2002 16:49:23 +0200 (EET) Message-ID: <3C7E42CD.1090201@nomadiclab.com> Date: Thu, 28 Feb 2002 16:46:37 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020220 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: "Jari T. Malinen" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, >>Why the MN's DNS name can't map into multiple addresses, provided >>that it wants to support both RR-based and non-RR based RO? > > I don't understand how that can be used to prevent bidding down. Forgetting that DNS itself may be insecure and attacked, IMHO that is simple. Basically, the CN must be able to make a distinction between RR-allowing and RR-disallowing addresses. Otherwise it couldn't make the right decision when it gets an initial BU authorization message from a previously unknown node. Now, since the CN must be able to make the distinction, it can inspect the addresses it receives from DNS. If any of them forbids RR, the CN can decide to use it, and fall back only if it learns that it doesn't speak the MN's stronger protocol(s). > If the MN e.g. runs a web server on http://laptop.example > and laptop.example has both a RR and a non-RR IP address record in the DNS, > then it seems like the MN, for that service, is willing to live with the > threats of allowing RR BUs. Thus it is sufficient to have just the RR > address in the DNS as far as I can tell. That's a viable policy, too. > But having multiple different identifiers of the service (different URLs => hostnames, or different SRV records) point to different IP addresses > *plus* the MN verifying that a connection to a service uses the right > IP address for that service seems reasonable. That's a viable policy, as well. > If you believe my argument above then the CN never needs to choose. > Instead the MN chooses by what IP address it registers (in DNS or elsewhere) > for each service. Sure it is easier if the MN makes its choice a priori, maybe based on the service as you propose. However, since all nodes supporting RR must be able to make the distinction between the two types of addresses, the third policy, suggested above, is also viable. Or at least I think so, maybe I am missing something. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 10:27:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28272 for ; Thu, 28 Feb 2002 10:27:37 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23705; Thu, 28 Feb 2002 08:27:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26761; Thu, 28 Feb 2002 07:27:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SFQKKL013574 for ; Thu, 28 Feb 2002 07:26:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SFQJ5b013573 for mobile-ip-dist; Thu, 28 Feb 2002 07:26:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SFQFKL013566 for ; Thu, 28 Feb 2002 07:26:16 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g1SFQ9x03159; Thu, 28 Feb 2002 16:26:09 +0100 (MET) Date: Thu, 28 Feb 2002 16:21:20 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient To: Pekka Nikander Cc: Erik Nordmark , "Jari T. Malinen" , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7E42CD.1090201@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Forgetting that DNS itself may be insecure and attacked, IMHO > that is simple. Basically, the CN must be able to make a distinction > between RR-allowing and RR-disallowing addresses. Otherwise it > couldn't make the right decision when it gets an initial BU > authorization message from a previously unknown node. > > Now, since the CN must be able to make the distinction, it can > inspect the addresses it receives from DNS. If any of them > forbids RR, the CN can decide to use it, and fall back only > if it learns that it doesn't speak the MN's stronger > protocol(s). So in this case the MN is open to any policy (it will accept RR as well as non-RR) and it lets the CN choose. I guess this is really orthogonal to the possible policies I listed since this could be per service hosted on the MN as well. > Sure it is easier if the MN makes its choice a priori, maybe > based on the service as you propose. However, since all nodes > supporting RR must be able to make the distinction between the > two types of addresses, the third policy, suggested above, > is also viable. Or at least I think so, maybe I am missing > something. It was I that was missing that it might make sense to give the CN the choice in some cases. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 11:50:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03489 for ; Thu, 28 Feb 2002 11:50:17 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09299; Thu, 28 Feb 2002 09:50:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12063; Thu, 28 Feb 2002 08:50:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SGn7KL013722 for ; Thu, 28 Feb 2002 08:49:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SGn7ko013721 for mobile-ip-dist; Thu, 28 Feb 2002 08:49:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SGn3KL013714 for ; Thu, 28 Feb 2002 08:49:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02007 for ; Thu, 28 Feb 2002 08:49:04 -0800 (PST) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08730 for ; Thu, 28 Feb 2002 09:49:04 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 0D72FA81 for ; Thu, 28 Feb 2002 08:55:34 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 4D50D1954 for ; Thu, 28 Feb 2002 08:49:03 -0800 (PST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1SGn2R17905; Thu, 28 Feb 2002 11:49:02 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA16955; Thu, 28 Feb 2002 11:49:01 -0500 Message-Id: <200202281649.AA16955@dogbert.zk3.dec.com> From: Brian.Haley@compaq.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] ISSUE: Design team recommendation: New recommendation on piggybacking Date: Thu, 28 Feb 2002 11:49:01 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 3. RECOMMENDATIONS > > The design team recommends the following: > > R1. A Separate protocol and/or port should be used for the BR > message, all RR messages, BU message and BA message. This > will allow - but not mandate - the use of current IPsec > selectors in protecting BUs to the CN and HA, and RR > messages via the HA. The value of next protocol = none > must be supported by all MIPv6 compliant nodes in these > messages. I must have been asleep when somone proposed creating an IPPROTO_MIPV6 (or whatever) type, and removing them from a Destination Options header. Is this really what the DT meant? BTW, I *strongly* object to using a port - all of the mipv6 implementations to date are in kernel space, not daemons. > R2. Reserve some space for preference bits in the RR messages > 1a and 1b, to allow the CN and the MN to describe their > preferences. Only the space is reserved, but no meaning > is assigned to the bits. Can live with. > R3. The above two recommendations should be placed in the > MIPv6 RFC. This would allow us to quickly proceed to RFC > status by bypassing controversial content, have as simple > RFC and implementations as possible, but still allow > functionality like piggybacking to be specified without > interoperability concerns, and used by all nodes who > support it. Agree. > R4. Separate RFCs would define the use of these bits. For > example, their use in piggybacking would need to define > the following: Agree. > R5. At a future time, IF IPsec selectors can be extended in > some manner, the RFC described under R4 could be updated > to extend the rules under which piggybacking is possible > i.e. no IPsec checks would be necessary any more. Agree. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 11:57:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03958 for ; Thu, 28 Feb 2002 11:57:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01535; Thu, 28 Feb 2002 09:57:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25668; Thu, 28 Feb 2002 08:57:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SGucKL013825 for ; Thu, 28 Feb 2002 08:56:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SGuc1O013824 for mobile-ip-dist; Thu, 28 Feb 2002 08:56:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SGuZKL013817 for ; Thu, 28 Feb 2002 08:56:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13697 for ; Thu, 28 Feb 2002 08:56:36 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12080 for ; Thu, 28 Feb 2002 09:56:34 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D8E7D6A907 for ; Thu, 28 Feb 2002 18:56:24 +0200 (EET) Message-ID: <3C7E6183.4080907@piuha.net> Date: Thu, 28 Feb 2002 18:57:39 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] ISSUE: Design team recommendation: New recommendation on piggybacking References: <200202281649.AA16955@dogbert.zk3.dec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian.Haley@compaq.com wrote: > I must have been asleep when somone proposed creating an IPPROTO_MIPV6 > (or whatever) type, and removing them from a Destination Options header. > Is this really what the DT meant? Yes. > BTW, I *strongly* object to using a > port - all of the mipv6 implementations to date are in kernel space, > not daemons. I agree. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 13:01:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09029 for ; Thu, 28 Feb 2002 13:01:37 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07768; Thu, 28 Feb 2002 11:01:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00717; Thu, 28 Feb 2002 10:01:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SI0MKL014005 for ; Thu, 28 Feb 2002 10:00:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SI0MPg014004 for mobile-ip-dist; Thu, 28 Feb 2002 10:00:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SI0IKL013997 for ; Thu, 28 Feb 2002 10:00:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29493 for ; Thu, 28 Feb 2002 10:00:18 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06859 for ; Thu, 28 Feb 2002 11:00:17 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1SI0Ee25883; Thu, 28 Feb 2002 10:00:14 -0800 (PST) Message-ID: <00cd01c1c081$8cbee740$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: , "Pekka Nikander" References: Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient Date: Thu, 28 Feb 2002 09:58:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > Correct. > The simple case is that the MN as a unit decides to use either a RR or > a non-RR address. > I think allowing the network administrator of the network where the HA is located to control whether MNs that use that HA have an RR or non-RR address would be the more common case. The MN will get its HoA from that network anyway. Also, a network administrator would be in a better position to trace any attacks should they be attempted via the HA. The MN may not be in a position to even know if the HA is getting probed. Also, if a PKI or AAA-based solution is in use, the home network must co-operate to provide the appropriate cryptographic assurances. In cases where the MN is "home-agentless", I think the model of letting the MN choose is probably OK, but then I would assume some of those cases will be handled by having the MN associate with a HA in the foreign network and thus get its HoA assigned by the foreign network. If the HA is not in the foreign network, or otherwise dynamically negotiated, I'm not sure how the MN will get its HoA. Perhaps by acting as its own HA? So there is an issue here of exactly how a RR v.s. nonRR address does get assigned. And what happens if the home network is renumbered, or the network administrator decides to change RR v.s. nonRR policy while the MN is away. Presumably, that could be handled by the network renumbering support already in MIPv6. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 13:45:43 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11874 for ; Thu, 28 Feb 2002 13:45:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29776; Thu, 28 Feb 2002 11:45:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14387; Thu, 28 Feb 2002 10:45:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIiUKL014221 for ; Thu, 28 Feb 2002 10:44:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SIiTXf014220 for mobile-ip-dist; Thu, 28 Feb 2002 10:44:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SIiPKL014213 for ; Thu, 28 Feb 2002 10:44:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10603 for ; Thu, 28 Feb 2002 10:44:25 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00711 for ; Thu, 28 Feb 2002 11:44:24 -0700 (MST) Received: from jariws1 ([62.248.152.76]) by fep02-app.kolumbus.fi with SMTP id <20020228184423.PVAW27811.fep02-app.kolumbus.fi@jariws1>; Thu, 28 Feb 2002 20:44:23 +0200 Message-ID: <006701c1c087$f1b0d360$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "James Kempf" , Cc: , "Pekka Nikander" References: <00cd01c1c081$8cbee740$7e6015ac@T23KEMPF> Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient Date: Thu, 28 Feb 2002 20:44:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I think allowing the network administrator of the network where the HA > is located to control whether > MNs that use that HA have an RR or non-RR address would be the more > common case. The MN > will get its HoA from that network anyway. > So there is an issue here of exactly how a RR v.s. nonRR address does > get assigned. Case 1: The addresses come from the network manager and they are then entered to the hosts. No problem here, the manager knows what's best for you ;-) Case 2: The addresses are autoconfigured. You would then have to know what to autoconfigure, RR or non-RR. There may be something that the node knows itself about its mobility. A stationary machine might configure itself a non-RR address, and refuse any attempts at mobility. Nodes that don't know would supposedly have a default, e.g. RR. A network manager who wishes to control the policies in a large network would have to do so in some manner. I suppose there'd also be other security sensitive configurations, such as which services to open in the host, whether to require IPsec for communications, and so on. I don't think we have a standard way of configuring these things. Sending a flag in the Router Advertisement would not work in a secure way before we fix IPv6 control signaling security ;-) > And what happens if the home network is renumbered, Nothing, if the host IDs stay the same? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 14:29:41 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14783 for ; Thu, 28 Feb 2002 14:29:41 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25482; Thu, 28 Feb 2002 12:29:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28902; Thu, 28 Feb 2002 11:29:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SJSTKL014431 for ; Thu, 28 Feb 2002 11:28:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SJSTjO014430 for mobile-ip-dist; Thu, 28 Feb 2002 11:28:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SJSPKL014423 for ; Thu, 28 Feb 2002 11:28:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25279 for ; Thu, 28 Feb 2002 11:28:26 -0800 (PST) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24848 for ; Thu, 28 Feb 2002 12:28:25 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id D726B4F96 for ; Thu, 28 Feb 2002 11:34:55 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id DBC50182B for ; Thu, 28 Feb 2002 14:28:24 -0500 (EST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g1SJSOR17068; Thu, 28 Feb 2002 14:28:24 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA08196; Thu, 28 Feb 2002 14:28:24 -0500 Message-Id: <200202281928.AA08196@dogbert.zk3.dec.com> From: Brian.Haley@compaq.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] ISSUE: Design team recommendation: New recommendation on piggybacking Date: Thu, 28 Feb 2002 14:28:23 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I must have been asleep when somone proposed creating an IPPROTO_MIPV6 > > (or whatever) type, and removing them from a Destination Options header. > > Is this really what the DT meant? > > Yes. It's all coming back to me... you're talking about a new destination option header that would be placed either in front or in back of the existing DO header. So should the HAO also be placed in this new header since it is for mobility as well? -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 14:43:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15479 for ; Thu, 28 Feb 2002 14:43:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03813; Thu, 28 Feb 2002 12:43:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05688; Thu, 28 Feb 2002 11:43:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SJg9KL014573 for ; Thu, 28 Feb 2002 11:42:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SJg9I7014572 for mobile-ip-dist; Thu, 28 Feb 2002 11:42:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SJfnKL014544 for ; Thu, 28 Feb 2002 11:41:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05189 for ; Thu, 28 Feb 2002 11:41:50 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26067 for ; Thu, 28 Feb 2002 11:41:48 -0800 (PST) Received: from jariws1 ([62.248.152.76]) by fep02-app.kolumbus.fi with SMTP id <20020228194147.QCFW27811.fep02-app.kolumbus.fi@jariws1>; Thu, 28 Feb 2002 21:41:47 +0200 Message-ID: <00d001c1c08f$f69068c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <200202281928.AA08196@dogbert.zk3.dec.com> Subject: Re: [mobile-ip] ISSUE: Design team recommendation: New recommendation on piggybacking Date: Thu, 28 Feb 2002 21:41:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > It's all coming back to me... you're talking about a new destination > option header that would be placed either in front or in back of the > existing DO header. So should the HAO also be placed in this new > header since it is for mobility as well? No, HAO needs to be a DO since it goes with the data packets. HAO is piggybacked ;-) The new protocol would only be for MIPv6 control messages, such as RR messages or the BU contained within them. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 15:22:49 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17680 for ; Thu, 28 Feb 2002 15:22:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02219; Thu, 28 Feb 2002 13:22:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19452; Thu, 28 Feb 2002 12:22:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SKLYKL014701 for ; Thu, 28 Feb 2002 12:21:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SKLYNb014700 for mobile-ip-dist; Thu, 28 Feb 2002 12:21:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SKLVKL014693 for ; Thu, 28 Feb 2002 12:21:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19007 for ; Thu, 28 Feb 2002 12:21:32 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22102 for ; Thu, 28 Feb 2002 13:21:31 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g1SKLIe02521; Thu, 28 Feb 2002 12:21:18 -0800 (PST) Message-ID: <016f01c1c095$40fdf5d0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , Cc: , "Pekka Nikander" References: <00cd01c1c081$8cbee740$7e6015ac@T23KEMPF> <006701c1c087$f1b0d360$8a1b6e0a@arenanet.fi> Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient Date: Thu, 28 Feb 2002 12:19:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Case 2: The addresses are autoconfigured. You would then have to > know what to autoconfigure, RR or non-RR. There may be something > that the node knows itself about its mobility. A stationary machine > might configure itself a non-RR address, and refuse any attempts at > mobility. Nodes that don't know would supposedly have > a default, e.g. RR. A network manager who wishes to control the > policies in a large network would have to do so in some manner. I > suppose there'd also be other security sensitive configurations, such > as which services to open in the host, whether to require IPsec for > communications, and so on. I don't think we have a standard way of > configuring these things. Sending a flag in the Router Advertisement > would not work in a secure way before we fix IPv6 control signaling > security ;-) > Even if the addresses are autoconfigured, the host IDs need to be assigned to avoid collision on the home network. The MN can run DAD before it leaves home, of course, but if we are taking about a "special" host ID bit, the MN can't simply use its interface identifier, can it? > ... > > Nothing, if the host IDs stay the same? > OK, so there is only the case where the network administrator decides to change from RR to nonRR (can't see anyone going in the other direction) or use a different nonRR, like using CGA then starting to use PKI or AAA key distribution because they decide to subscribe to it. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 16:26:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20497 for ; Thu, 28 Feb 2002 16:26:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23004; Thu, 28 Feb 2002 14:26:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26126; Thu, 28 Feb 2002 13:25:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SLNcKL014836 for ; Thu, 28 Feb 2002 13:23:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SLNc8U014835 for mobile-ip-dist; Thu, 28 Feb 2002 13:23:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SLNZKL014828 for ; Thu, 28 Feb 2002 13:23:35 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25427 for ; Thu, 28 Feb 2002 13:23:37 -0800 (PST) Received: from caip.rutgers.edu (caip.rutgers.edu [128.6.236.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10562 for ; Thu, 28 Feb 2002 13:23:29 -0800 (PST) Received: (from wanchoo@localhost) by caip.rutgers.edu (8.9.3/8.9.3) id QAA02576; Thu, 28 Feb 2002 16:22:58 -0500 (EST) Date: Thu, 28 Feb 2002 16:22:57 -0500 (EST) From: Ajay Wanchoo To: Subject: [mobile-ip] Agent Detection & IP Address In-Reply-To: <016f01c1c095$40fdf5d0$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I'm trying to identify convergence, if any between MobileIP and GPRS for the sake of mobility support in VPNs. Some specific questions: 1. Is there any reccomendation as far as reusing VLR/HLR information in lieu of or in tandem with the registration info maintained with the HA/FA (assuming that the PDP Contexts could be used for customized spport for varied MNs) 2. In case of a movement between two networks (across FA/PDSN), since there is an explicit detection of mobility by all, except the MN, FAs and the HA, till an advertisement is acquired by the MN, is it at all recommended to ignore the detection noticed by the local environment and MN (below the Mobile IP layer and except the HA and FA), or is there a reccomended manner of propagating the info up to the MIP participants ? 3. I understand (correct me if I'm wrong) that limited forwarding may take place from the old FA to a new FA in case of movement of an MN across two FAs during the re-registration process(either in pure Mobile IP or some variation, to maintain connectedness for TCP like use). Now if I'm not mistaken some kind of forwarding also may also take place at lower levels (in the GPRS stack at, probably the GGSN stage). Which one is the preferred manner. 4. Each device is expected to have a globally unique ID and each GPRS network is associated with a DNS and a DHCP server to manage its addresses. Since a lot of issues are associated with addressing, especially when the Mobile device is a part of a VPN and/or wishes to be a part of a VPN which has the rest of its devices behind a NAT etc. I will greatly appreciate pointers to where all these issues are dealt with formally (recommendations/standards) Thanks Ajay From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 17:26:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23269 for ; Thu, 28 Feb 2002 17:26:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01503; Thu, 28 Feb 2002 15:26:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06165; Thu, 28 Feb 2002 14:26:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SMPJKL014963 for ; Thu, 28 Feb 2002 14:25:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1SMPJgO014962 for mobile-ip-dist; Thu, 28 Feb 2002 14:25:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1SMPGKL014955 for ; Thu, 28 Feb 2002 14:25:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29871 for ; Thu, 28 Feb 2002 14:25:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27491 for ; Thu, 28 Feb 2002 15:25:16 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA18774; Thu, 28 Feb 2002 14:25:15 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g1SMPEE16081; Thu, 28 Feb 2002 14:25:14 -0800 X-mProtect:  Thu, 28 Feb 2002 14:25:14 -0800 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoGSvMk; Thu, 28 Feb 2002 14:25:12 PST Message-ID: <3C7EAE48.DC2ED610@iprg.nokia.com> Date: Thu, 28 Feb 2002 14:25:12 -0800 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > I don't think that addresses the robustness problems I see. > Let's draw parallels between the unvHAO cache and the binding cache. > Both are going to be of finite size thus there will be cases when a new > entry can't be made. > In the BC case this will be signalled to the MN - the BU will receive a BAck > with a failure code. Thus the MN will actually know whether it has an entry > in the BC or not (subject to the CN not crashing or otherwise loosing all > state). > I mentioned that the CN sends a BR indicating to the MN to use RO or BDT. May be it was not clear.. > > In the unvHAO case the MN seems to need to operate in pray and hope mode - > it sends a packet with a HAO and hopes that there is room for an unvHAO cache > entry. > > I see two ways of making this more robust: > 1. An explicit roundtrip between the MN and CN to create the unvHAO cache entry > i.e. the MN will get an ack when the entry has been created. This > means that no packets will be dropped by the CN (subject to the CN not > crashing or otherwise loosing all state). > 2. An unvHAO arriving when there isn't room to create a cache entry results > in an error going back to the MN. > This means that one roundtrip worth of data packets can be dropped by the CN > until the MN is notified to stop sending HAO packets. > This error message is what I meant by sending a BR. May be the same BR can also be sent when the entry is created (1 above); on the other hand, that may not be necessary. > > > > How so? Replace the "7" above with any other number between zero and > infinity > > and what is different? > > > > > > > If you set the entry large enough, inspite of infrequent packet > > transmission and packet losses, the CN would still be in tagging state. > > That doesn't change any fundamentals - merely what frequence of communication > is subject to the loss propagation/expansion. > For instance if the unvHAO cache lifetime is one day then applications which > look for the news once per day would be subjected to this loss expansion. > And you've said the lifetime needs to be fairly short so I don't think > one day makes any sense - I believe we are talking about lifetimes that are > less than a few minutes, right? > Yes. It appears that we are looking at the issue from slightly different angles. Since packet loss when the MN sends HAO when there is no entry in the CN is the issue, let me propose the following: the CN does not drop those packets. Instead, it does not tag the first few packets until it moves to tagging state. So, the downside is the receiver does not know the source for say 3 packets. What do you think ? > > > Point taken. Even so, transport level retransmission would get the packet > > out to CN. > > Since bit errors are the predominant reason for packet loss in wireless, a > > scheme such as udp-lite could greatly improve reliability even when there is > > no transport level retransmission. > > I can't tell whether you agree with my point that the unvHAO logic > you've expressed is causing loss expansion in some cases where > packet loss will cause the unvHAO cache entry to time out causing packets > to be dropped by the CN. > I agree. I might not agree with the rate of such occurrence. Also, if we can allow the CN to not drop those packets (say the CN is in a standby state before it moves to no-tagging state) then that might be a good compromise. > > I also can't tell whether you agree with my point that the MN needs to know > how long its unvHAO will we kept by the CN in the absense of the CN > receiving any matching packets. > I mentioned this is useful (see below).. What if the BR is sent when the entry is created and it includes a lifetime field ? > > > > It seems like at a minimum the MN needs to know for how long it can assume > > > the CN will keep the cache entry. Do you agree? > > > > It certainly helps if the MN knew about this. I don't know how best to > > convey this to the MN..If it didn't, the protocol should still work with the > > caveat that a packet would > > be lost. But, if we can live with the CN not dropping it (e.g, because it has > > history), may be that's another option. I need to think this through further. > > > More generally, if non-HAO packets are due to mobility signaling, then we can > > handle them in the above fashion. > > Yes, this could all be special cased. > But it doesn't address other cases of non-HAO packets. > My other example was a multicast packet sent by the MN that, for whatever > reasons, is reverse tunneled. > The MN doesn't even know that this particular CN is a member of the multicast > group. Yet the reception of that non-HAO packet causes the erasure of the > unvHAO cache which will cause packets with HAO to be dropped. > Actually, in the multicast case, the destination address is not the CN's address. So the following rules will do when removing the unverified BC. if (srcIPaddr == HoA) if ((not a MIP packet) && (dstIPaddr=self)) remove tag > Regards, -Rajeev > > Special cases isn't necessarily the best path forward IMHO. > > > Ok. I will give the write-up a try. In the meanwhile, Charlie's original text > > described the tagging proposal. I also have some other text (other than > > tag-or-not.txt) that I will include in the write-up. > > Great. > Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 19:07:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27126 for ; Thu, 28 Feb 2002 19:07:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14960; Thu, 28 Feb 2002 17:07:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05680; Thu, 28 Feb 2002 16:06:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2105aKL015141 for ; Thu, 28 Feb 2002 16:05:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2105aad015140 for mobile-ip-dist; Thu, 28 Feb 2002 16:05:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2105XKL015133 for ; Thu, 28 Feb 2002 16:05:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03634 for ; Thu, 28 Feb 2002 16:05:35 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28462 for ; Thu, 28 Feb 2002 16:05:35 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA24308; Thu, 28 Feb 2002 16:05:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2105VS09666; Thu, 28 Feb 2002 16:05:31 -0800 X-mProtect:  Thu, 28 Feb 2002 16:05:31 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfQwDO4; Thu, 28 Feb 2002 16:05:25 PST Message-ID: <3C7EC5C6.E85CA3BA@iprg.nokia.com> Date: Thu, 28 Feb 2002 16:05:26 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Brian.Haley@compaq.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200202281928.AA08196@dogbert.zk3.dec.com> <00d001c1c08f$f69068c0$8a1b6e0a@arenanet.fi> Content-Type: multipart/mixed; boundary="------------F289C5BBF17D95854FD2C446" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------F289C5BBF17D95854FD2C446 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all, Jari Arkko wrote: > > > It's all coming back to me... you're talking about a new destination > > option header that would be placed either in front or in back of the > > existing DO header. So should the HAO also be placed in this new > > header since it is for mobility as well? > > No, HAO needs to be a DO since it goes with the data packets. > HAO is piggybacked ;-) > > The new protocol would only be for MIPv6 control messages, such as > RR messages or the BU contained within them. > I just tried putting together the format of the new extension header. looks very much like the destination options header. called it the mobility options header :) the format of the options is different from the IPv6 destination options. the difference is in the length field. instead of octets, it is in terms of 4 octets. Vijay --------------F289C5BBF17D95854FD2C446 Content-Type: text/plain; charset=us-ascii; name="new_exthdr.txt" Content-Disposition: inline; filename="new_exthdr.txt" Content-Transfer-Encoding: 7bit 1. New Extension Header Order IPv6 header Hop-by-Hop Options header Destination Options header (1) Routing header Destination Options header (2) Fragment header Authentication header Encapsulating Security Payload header Mobility Options header Destination Options header (3) upper-layer header (1) for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the Routing header. (2) contains only Mobile IPv6 Home Address Option (HAO) (3) for options to be processed only by the final destination of the packet. 2. Mobility options header The Mobility Options header is identified by a Next Header value of 62 (??) in the immediately preceding header, and has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the Mobile IPv6 options header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.]. Hdr Ext Len 8-bit unsigned integer. Length of the Mobility Options header in 8-octet units, not including the first 8 octets. Options Variable-length field, of length such that the complete Mobility Options header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options, as described in section 3. 3. Mobility Options +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Option Type 8-bit identifier of the type of option. Opt Data Len 8-bit unsigned integer. Length of the Option Data field of this option, in 4 octets, not including the first 4 octets. Option Data Variable-length field. Option-Type-specific data. 4. Possible Mobility Options Binding Update - remains the same, except for the length field Binding Acknowledgement - remains the same, except for the length field Binding Request - remains the same, except for the length field Return Routability (possibly multiple options) PAD1 PADn (note: The length field in the Mobililty Options is in terms of 4 octets thereby allowing upto 1028 bytes in each option. This should be more than enough to carry any CGA information. There has been atleast one complaint that the limit of 256 bytes in Destination Options is not good for CGA) --------------F289C5BBF17D95854FD2C446-- From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 20:14:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28246 for ; Thu, 28 Feb 2002 20:14:03 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29438; Thu, 28 Feb 2002 18:13:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16510; Thu, 28 Feb 2002 17:13:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g211CUKL015302 for ; Thu, 28 Feb 2002 17:12:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g211CUwA015301 for mobile-ip-dist; Thu, 28 Feb 2002 17:12:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g211CQKL015294 for ; Thu, 28 Feb 2002 17:12:26 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16327 for ; Thu, 28 Feb 2002 17:12:28 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19002 for ; Thu, 28 Feb 2002 17:12:27 -0800 (PST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 802463A7A; Thu, 28 Feb 2002 19:12:20 -0600 (CST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 114BBFDF; Thu, 28 Feb 2002 19:12:20 -0600 (CST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g211CGR12805; Thu, 28 Feb 2002 20:12:16 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA17638; Thu, 28 Feb 2002 20:11:47 -0500 Message-Id: <200203010111.AA17638@dogbert.zk3.dec.com> From: Brian.Haley@compaq.com To: mobile-ip@sunroof.eng.sun.com Cc: vijayd@iprg.nokia.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team Recommendation: New recommendation on piggybacking) Date: Thu, 28 Feb 2002 20:11:46 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay Devarapalli wrote: > 1. New Extension Header Order > > IPv6 header > Hop-by-Hop Options header > Destination Options header (1) > Routing header > Destination Options header (2) > Fragment header > Authentication header > Encapsulating Security Payload header > Mobility Options header > Destination Options header (3) > upper-layer header > > (1) for options to be processed by the first destination > that appears in the IPv6 Destination Address field > plus subsequent destinations listed in the Routing > header. > > (2) contains only Mobile IPv6 Home Address Option (HAO) > > (3) for options to be processed only by the final > destination of the packet. So do we dare ask what the IPv6 WG has to say about this proposal? Obviously we have spent a lot of time looking into the best way to do this, which can't be ignored... > 2. Mobility options header > 3. Mobility Options Looks good. > 4. Possible Mobility Options > > Binding Update - remains the same, except for the length field > Binding Acknowledgement - remains the same, except for the length field > Binding Request - remains the same, except for the length field > Return Routability (possibly multiple options) > PAD1 > PADn And I'm assuming these sub-options too: Unique identifier Alternate Care-of address Auth data??? Thanks for writing this up, -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Feb 28 20:39:20 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28722 for ; Thu, 28 Feb 2002 20:39:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA12489; Thu, 28 Feb 2002 17:39:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21207; Thu, 28 Feb 2002 17:39:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g211btKL015405 for ; Thu, 28 Feb 2002 17:37:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g211btKA015404 for mobile-ip-dist; Thu, 28 Feb 2002 17:37:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g211bpKL015397 for ; Thu, 28 Feb 2002 17:37:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02671 for ; Thu, 28 Feb 2002 17:37:54 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24543 for ; Thu, 28 Feb 2002 18:37:53 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA00664; Thu, 28 Feb 2002 17:37:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g211bqX12268; Thu, 28 Feb 2002 17:37:52 -0800 X-mProtect:  Thu, 28 Feb 2002 17:37:52 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiBsGpg; Thu, 28 Feb 2002 17:37:50 PST Message-ID: <3C7EDB6E.9122958C@iprg.nokia.com> Date: Thu, 28 Feb 2002 17:37:50 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian.Haley@compaq.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team References: <200203010111.AA17638@dogbert.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian.Haley@compaq.com wrote: > > So do we dare ask what the IPv6 WG has to say about this proposal? > Obviously we have spent a lot of time looking into the best way to > do this, which can't be ignored... I guess the new extension header is the way to go.... > And I'm assuming these sub-options too: > > Unique identifier > Alternate Care-of address > Auth data??? The sub-options remain the same. Vijay