From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 04:35: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 EAA02213 for ; Fri, 1 Mar 2002 04:35: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 CAA08863; Fri, 1 Mar 2002 02:35: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 BAA14107; Fri, 1 Mar 2002 01:35: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 g219YtKL015928 for ; Fri, 1 Mar 2002 01:34:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g219Yt9v015927 for mobile-ip-dist; Fri, 1 Mar 2002 01:34: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 g219YpKL015920 for ; Fri, 1 Mar 2002 01: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 BAA21569 for ; Fri, 1 Mar 2002 01:34:51 -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 CAA08489 for ; Fri, 1 Mar 2002 02:34:50 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 66120A; Fri, 1 Mar 2002 11:36:41 +0200 (EET) Message-ID: <3C7F4B03.1030006@nomadiclab.com> Date: Fri, 01 Mar 2002 11:33:55 +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: rajeev@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options References: <3C7EAE48.DC2ED610@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 Koodli wrote: > 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 ? Looks quite bad from the DDoS reflection point of view. If I am an attacker, able to spoof addresses, and therefore subject to i-trace etc. (which is the reason for the tagging), I can launch an easy but not very good attack: 1. I send one packet to the CN, with no HAO and src=HaO -> CN goes to no-tagging state. This packet may trigger i-trace, but maybe I can get somebody else to send the packet. 2. I send a few packets, with HAO=HaO, to the CN. The CN replies to these, with dst=HaO. The replies are not tagged, since the CN is in no-tagging state, and therefore the replies do not reveal me through i-trace etc. 3. Repeat the cycle. The practical effect of this attack is that I can make the probablity of i-trace etc revealing smaller than it otherwise could be. But this is just one way of defeating the purpose of tagging, there are probably more effective ones. Again: From the security point of view, it is important that *no* packets that are replies to any packet containing HAO leave the CN towards the HoA, unless they contain the tag. If we make an intentional hole into tagging, somebody will find a way to (mis)use it, sooner or later. I do not like approaches that compromize existing security for the sake of an optimization that may or may not be videly used and that does not necessarily bring that much benefit. Considering the complexity of processing unvHAOs, how likely is that somebody implements unvHAO processing but not RR? RR requires no hard crypto, no complicated states, and only 1.5 RTT. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 04:53: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 EAA02780 for ; Fri, 1 Mar 2002 04:53:10 -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 CAA16366; Fri, 1 Mar 2002 02:53: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 BAA09154; Fri, 1 Mar 2002 01:53: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 g219qHKL016007 for ; Fri, 1 Mar 2002 01:52:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g219qH6q016006 for mobile-ip-dist; Fri, 1 Mar 2002 01:52: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 g219qEKL015999 for ; Fri, 1 Mar 2002 01:52:14 -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 BAA19302 for ; Fri, 1 Mar 2002 01:52:14 -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 BAA03747 for ; Fri, 1 Mar 2002 01:52:14 -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 BAA18889; Fri, 1 Mar 2002 01:52:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g219q7j32594; Fri, 1 Mar 2002 01:52:07 -0800 X-mProtect:  Fri, 1 Mar 2002 01:52:07 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdnpOKYg; Fri, 01 Mar 2002 01:52: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 BAA06200; Fri, 1 Mar 2002 01:52:05 -0800 (PST) Message-ID: <3C7F4F45.142CAB4@iprg.nokia.com> Date: Fri, 01 Mar 2002 01:52: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: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed & sufficient (but has consequences) 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.C2784 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, I believe my point did not come clear from earlier mails. I changed the topic to match the discussion. The host identity duality with legacy is more involved than meets the eye. At end of your first mail you seem to indicate it would not be needed and multi-homing would solve the other cases (MN risks it offering RR). These are valid scenarios _when_ one can do that but in some cases one cannot avoid needing to deal with knowing the duality. My main point was that if this is the case, there is more need for change than just the bit encoding itself. Blind multihoming is not enough. DNS is a case. Legacy services resolving to one address are in many places; mere multihoming for the webserver case may call for either duplicating the service or changing DNS to be bit-aware. In DNS you recognized the issue, but I am afraid this is not the only place the issue causes changes. URLs may have addresses, some other protocols map identities to addresses besides DNS or transfer these identities so that some content becomes non-interoperable with legacy nodes. > 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. :-) This note seems to indicate I did not manage to describe the core issue. If the legacy support is a non-goal then what you say here is fine. But it's not always just for the MN to decide. Identity encoding itself, such as the bit method, causes its own legacy worries that one may not just ignore. Any time identity encoding or management provides one address only or blindly, it is a problem (more later). > > 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. :-) Here it seems some of my point was understood, but the problem is a bit deeper than DNS, which was only an example. Any protocol which maps to some identity to one IP address or one address at a time, or blindly hands out IP address for home address use may need an update. These include stateful autoconfiguration and other managed address allocations where managing entity needs to know if MN supports a non-RR method if it hands out addresses for new and old MNs. E.g., assume a legacy MN gets its HoA from a home link DHCP, or some managed link or layer, the address given to MN may be useless unless it supports the new method. A temporary HA should in a scalable way ask if MN only knows RR before handing out a potentially useless HoA. > > 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. Multihoming is not the issue. It is more of an application behavior consequence that multiple identities are not necessarily independent especially when we talk about legacy interoperation of existing and new applications. > > 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. The above was an attempt to speculate how a legacy scheme in CN might work "transparently" (no change to applications) when using the bit method. By the ability of doing a transparent mapping of X HoA to RR HoA in the same node by some implicit rule, whereby a legacy node could try another address if the primary is a forbidden one. But it is clumsy, and that was a point here.. > > 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? Good that you brought this up. Scaling to the global network in a general case by static configurations obviously is not doable so that CNs know all different HoAs. Static configuration can be an interface to future methods. Also, switching RR off statically scales better if it means e.g. that no HoAs are served with RR, or HoAs with CoA prefix only in certain networks (e.g., in local protected domain) are served in some cases. Note the difference to the address encoding case: there MN lets CN know what it wants; in a static configuration MN or CN can locally decide they don't trust RR, with no identity duality problem. But configuration choices are more limited. But, that would amount to less attempt to support legacy (avoiding new legacy problems in the process). So it is a tradeoff. Static configuration could be seen as a backup choice should the bit method cause to be too problematic. > --Pekka BR, -Jari M From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 05:08: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 FAA03879 for ; Fri, 1 Mar 2002 05:08:56 -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 DAA22569; Fri, 1 Mar 2002 03:08: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 CAA11936; Fri, 1 Mar 2002 02:08: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 g21A81KL016114 for ; Fri, 1 Mar 2002 02:08:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21A80Ol016113 for mobile-ip-dist; Fri, 1 Mar 2002 02:08: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 g21A7vKL016106 for ; Fri, 1 Mar 2002 02:07:57 -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 CAA20962 for ; Fri, 1 Mar 2002 02:07:58 -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 CAA08893 for ; Fri, 1 Mar 2002 02:07:53 -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 g21A7pk30165 for ; Fri, 1 Mar 2002 11:07:51 +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 LAA26048 for ; Fri, 1 Mar 2002 11:07:51 +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 g21A7og89925 for ; Fri, 1 Mar 2002 11:07:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203011007.g21A7og89925@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] (CONCLUSION/DISAGREE) Design team recommendation: New recommendation on piggybacking In-reply-to: Your message of Tue, 26 Feb 2002 00:57:12 +0200. <3C7AC148.7090806@piuha.net> Date: Fri, 01 Mar 2002 11:07:50 +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: 2. DISCUSSION Message Sndr Rcvr ViaHA AddIPscOK RepIPscOK HAprot Pig RR 3/BU MN CN No Yes Yes No Yes RR 4/BA CN MN No Yes Yes No Yes => can one interpret this as a possibility to protect by IPsec (with all the RepIPscOk considerations about authorization, ...) a BU/BA exchange between a MN and a CN without RR? 2) RepIPsecOK=Yes for all the BU/BA messages means that they too should be protocols or ports. => CLARIFICATION: protocols == final next headers? 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. => I don't understand what can be a non-final protocol (or does protocol stand for next header value)? BTW to be final or non-final is an essential property, i.e. a "protocol" can not be both. - RR and BR/BU/BA is implemented using a separate IP protocol type value. => ISSUE: is this protocol final or non-final. I DISAGREE if this protocol is non-final (this doesn't work for IPsec selectors). 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. => CONCLUSION/DISAGREE: this recommendation is too ambiguous about the nature of the "protocol": final or non-final. 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. => ISSUE: where/when variants of stronger BU authorization methods will be allowed (note that all the examples I know don't need the bits) 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. => ISSUE: what will be the level of "requirement" for piggy-backing? (AGREE with a MAY (and any NOT :-), DISAGREE with SHOULD/MUST) We recommend that such as an RFC for piggybacking be produced immediately. => I can propose the IPv6 payload header document (:-). ^^^^ R5. At a future time, IF IPsec selectors can be extended in some manner => I've noted the IF is BIG. Don't expect to see multi-protocol IPsec (and what ever) selectors soon. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 05:44: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 FAA06505 for ; Fri, 1 Mar 2002 05:44: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 DAA05812; Fri, 1 Mar 2002 03:44: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 CAA01317; Fri, 1 Mar 2002 02:44: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 g21AhwKL016193 for ; Fri, 1 Mar 2002 02:43:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21AhwuZ016192 for mobile-ip-dist; Fri, 1 Mar 2002 02:43: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 g21AhtKL016185 for ; Fri, 1 Mar 2002 02:43:55 -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 CAA28421 for ; Fri, 1 Mar 2002 02:43:55 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11088 for ; Fri, 1 Mar 2002 02:43:51 -0800 (PST) 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 g21AhnZc001819 for ; Fri, 1 Mar 2002 11:43: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 g21AhnmK014681 for ; Fri, 1 Mar 2002 12:43:49 +0200 (EET) Message-ID: <3C7F5B65.A5072C63@lmf.ericsson.se> Date: Fri, 01 Mar 2002 12:43:49 +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 Subject: Re: [mobile-ip] (CONCLUSION/DISAGREE) Design team recommendation: New recommendation on piggybacking References: <200203011007.g21A7og89925@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 Dupont wrote: > > 2. DISCUSSION > > Message Sndr Rcvr ViaHA AddIPscOK RepIPscOK HAprot Pig > > RR 3/BU MN CN No Yes Yes No Yes > RR 4/BA CN MN No Yes Yes No Yes > > => can one interpret this as a possibility to protect by IPsec > (with all the RepIPscOk considerations about authorization, ...) > a BU/BA exchange between a MN and a CN without RR? Indeed, RepIPsecOK=Yes means that in theory you could use only Ipsec for that purpose without RR. We actually didn't take much stand on whether we should allow that or, just analyzed the requirements for BU/BA formats based on the possibility of doing so. Actually, I think we should make the RR mandatory in the base RFC and postpone the IPsec-only discussion to another RFC just to save time. > 2) RepIPsecOK=Yes for all the BU/BA messages means that they > too should be protocols or ports. > > => CLARIFICATION: protocols == final next headers? Well... I was thinking that the regular (base RFC) case would be that they'd have a next hdr field but that would be set to NO_NXTHDR. In my understanding of RFC 2401 this would classify it as a final for purposes of IPsec processing. > => ISSUE: what will be the level of "requirement" for piggy-backing? > (AGREE with a MAY (and any NOT :-), DISAGREE with SHOULD/MUST) MAY. > R5. At a future time, IF IPsec selectors can be extended in > some manner > > => I've noted the IF is BIG. Don't expect to see multi-protocol > IPsec (and what ever) selectors soon. I agree. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 05:57: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 FAA07594 for ; Fri, 1 Mar 2002 05:57:05 -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 DAA23527; Fri, 1 Mar 2002 03:56: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 CAA03434; Fri, 1 Mar 2002 02:56: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 g21AtxKL016277 for ; Fri, 1 Mar 2002 02:55:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21AtxwW016276 for mobile-ip-dist; Fri, 1 Mar 2002 02:55: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 g21AtuKL016269 for ; Fri, 1 Mar 2002 02:55: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 CAA19964 for ; Fri, 1 Mar 2002 02:55:57 -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 DAA23084 for ; Fri, 1 Mar 2002 03:55:56 -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 g21Atsk04299 for ; Fri, 1 Mar 2002 11:55: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 LAA27481 for ; Fri, 1 Mar 2002 11:55: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 g21Atsg90085 for ; Fri, 1 Mar 2002 11:55:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203011055.g21Atsg90085@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] ISSUE: Design team recommendation: New recommendation on piggybacking In-reply-to: Your message of Thu, 28 Feb 2002 11:49:01 EST. <200202281649.AA16955@dogbert.zk3.dec.com> Date: Fri, 01 Mar 2002 11:55: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: 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? => perhaps, the DT recommendation is so ambiguous... BTW, I *strongly* object to using a port - all of the mipv6 implementations to date are in kernel space, not daemons. => I object to your objection: - your assumption that all MIPv6 implementations are in kernel space is wrong - it is easy to use a port in kernel space (examples: NFS, Mobile IPv4, etc). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 06:02: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 GAA08222 for ; Fri, 1 Mar 2002 06:01: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 EAA25363; Fri, 1 Mar 2002 04:01: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 DAA04514; Fri, 1 Mar 2002 03:01: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 g21B1JKL016365 for ; Fri, 1 Mar 2002 03:01:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21B1I63016364 for mobile-ip-dist; Fri, 1 Mar 2002 03:01: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21B1FKL016357 for ; Fri, 1 Mar 2002 03:01:15 -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 DAA25969 for ; Fri, 1 Mar 2002 03:01: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 EAA27402 for ; Fri, 1 Mar 2002 04:01:14 -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 g21B1Bk04970; Fri, 1 Mar 2002 12:01:11 +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 MAA27625; Fri, 1 Mar 2002 12:01:11 +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 g21B1Bg90134; Fri, 1 Mar 2002 12:01:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> From: Francis Dupont 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) In-reply-to: Your message of Thu, 28 Feb 2002 16:05:26 PST. <3C7EC5C6.E85CA3BA@iprg.nokia.com> Date: Fri, 01 Mar 2002 12:01:11 +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 just tried putting together the format of the new extension header. => we have to agree FIRST if this is a final or a non-final header. BTW "a new extension header" is ambiguous but more for non-final, and IPsec selectors don't work with non-final. 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. => should make clearer than (1) implies there is a routing header. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 07:35: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 HAA17648 for ; Fri, 1 Mar 2002 07:35: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 FAA25375; Fri, 1 Mar 2002 05:35:16 -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 EAA09316; Fri, 1 Mar 2002 04: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 g21CY7KL016624 for ; Fri, 1 Mar 2002 04:34:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21CY7eu016623 for mobile-ip-dist; Fri, 1 Mar 2002 04:34: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 g21CY4KL016616 for ; Fri, 1 Mar 2002 04:34:04 -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 EAA19314 for ; Fri, 1 Mar 2002 04:34:04 -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 EAA19505 for ; Fri, 1 Mar 2002 04:34:01 -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 g21CXsk15619 for ; Fri, 1 Mar 2002 13:33: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 NAA00478 for ; Fri, 1 Mar 2002 13:33: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 g21CXsg90470 for ; Fri, 1 Mar 2002 13:33:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203011233.g21CXsg90470@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] (CONCLUSION/DISAGREE) Design team recommendation: New recommendation on piggybacking In-reply-to: Your message of Fri, 01 Mar 2002 12:43:49 +0200. <3C7F5B65.A5072C63@lmf.ericsson.se> Date: Fri, 01 Mar 2002 13:33: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: Francis Dupont wrote: > > 2. DISCUSSION > > Message Sndr Rcvr ViaHA AddIPscOK RepIPscOK HAprot Pig > > RR 3/BU MN CN No Yes Yes No Yes > RR 4/BA CN MN No Yes Yes No Yes > > => can one interpret this as a possibility to protect by IPsec > (with all the RepIPscOk considerations about authorization, ...) > a BU/BA exchange between a MN and a CN without RR? Indeed, RepIPsecOK=Yes means that in theory you could use only Ipsec for that purpose without RR. => this is why I've cited this part of the table and used the term "interpret". We actually didn't take much stand on whether we should allow that or, just analyzed the requirements for BU/BA formats based on the possibility of doing so. => so you have no official answer to my question nor to a similar issue about BU/BA with the HA (aka Home Registration). Actually, I think we should make the RR mandatory in the base RFC => you shan't save time this way because you shall get strong objections... and postpone the IPsec-only discussion to another RFC just to save time. => to save time you need something with the good level of specifications (too much (i.e. make RR mandatory) shall waste time, not enough (i.e. ambiguous RR recommendations which are not interoperable) shan't help). > 2) RepIPsecOK=Yes for all the BU/BA messages means that they > too should be protocols or ports. > > => CLARIFICATION: protocols == final next headers? Well... I was thinking that the regular (base RFC) case would be that they'd have a next hdr field but that would be set to NO_NXTHDR. In my understanding of RFC 2401 this would classify it as a final for purposes of IPsec processing. => For IPsec selector stuffs only the final "protocol" matters and in this case it is "NO_NXTHDR". This was discussed in many mails in the last two years... > R5. At a future time, IF IPsec selectors can be extended in > some manner > > => I've noted the IF is BIG. Don't expect to see multi-protocol > IPsec (and what ever) selectors soon. I agree. => so you should understand that you can't get both IPsec and piggy-backing! Thanks Francis.Dupont@enst-bretagne.fr PS: to leave the door open for alternative (to RR) highly secured modes for BU/BA exchanges solves both the issue for anybody who wants to use IPsec/AAA/... and the issue of the protection of HRs (they will be magically (i.e. by an unspecified way) protected, of course this works only if the magic is allowed). And this is easy to do: specify the security requirements and make RR mandatory when nothing else provides the required security. You only need a statement beginning with an uppercase IF... From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 10:32: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 KAA00158 for ; Fri, 1 Mar 2002 10:32: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 HAA17357; Fri, 1 Mar 2002 07:32:32 -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 HAA28528; Fri, 1 Mar 2002 07:32: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 g21FVSKL016840 for ; Fri, 1 Mar 2002 07:31:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21FVSri016839 for mobile-ip-dist; Fri, 1 Mar 2002 07:31: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 g21FVOKL016832 for ; Fri, 1 Mar 2002 07:31:25 -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 HAA28387 for ; Fri, 1 Mar 2002 07:31:24 -0800 (PST) Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07481 for ; Fri, 1 Mar 2002 08:31:23 -0700 (MST) Received: from ee.ryerson.ca ([24.112.177.95]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.06 201-253-122-122-106-20020109) with ESMTP id <20020301153123.HSHD5488.fep01-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 1 Mar 2002 10:31:23 -0500 Message-ID: <3C7F9EC8.3060604@ee.ryerson.ca> Date: Fri, 01 Mar 2002 10:31:20 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 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: [mobile-ip] CFP: IFIP/IEEE International Conference on Management of Multimedia Networks and Services Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.177.95] using ID at Fri, 1 Mar 2002 10:31:23 -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: Content-Transfer-Encoding: 7bit IFIP/IEEE International Conference on Management of Multimedia Networks and Services MMNS 2002 Managing IP Multimedia End-To-End October 6-9, 2002 Santa Barbara, CA USA http://www.cs.ucsb.edu/conferences/MMNS02 CALL FOR PAPERS With the popularity of the IP-based Internet, there has been a major shift towards building a worldwide, all-service and all-media network based on the next-generation of IP technology. Rich multimedia is increasingly being incorporated into Internet applications (like Voice-over-IP, streaming video, etc.). However, more work is needed to evolve the Internet and the underlying networking technologies into an infrastructure capable of supporting all- service and all-media traffic. Significant management functionality is required to ensure that these applications have a network that is both capable and available. Management requirements may ensue from the fact that multimedia traffic may traverse networks using a wide variety of technology and each network may be owned, operated, and controlled by a different organization. In order to provide end-to-end, high quality multimedia services, the network must provide robust management functionality. The IFIP/IEEE International Conference on Management of Multimedia Networks and Services will hold its fifth annual meeting Oct. 6 through Oct. 9, 2002 in Santa Barbara, CA. The IFIP/IEEE MMNS is a single-track conference and provides an intimate setting for discussion and debate. The program committee is soliciting original papers describing research in the area of management of multimedia networks and services. Topics of interest include, but are not limited to, the following: o End-to-end IP multimedia network and service management o VoIP service management o IP Video, streaming, interactive video service management o Provisioning of multimedia networks and services o Wireless and mobile multimedia network management o Optical multimedia network management o Cable multimedia network management o Multimedia network traffic engineering and optimization o Distributed multimedia service management o Network management models and architectures o Billing and security for multi-media services o Content distribution internetworking o Resource, performance and fault management o Multi-point, multicast services management o Network programmability for multimedia services o Policy-based management for multimedia services o QoS management o Multimedia traffic management o Multimedia content protection o Deployment of multimedia services o Active multimedia network management o Multimedia session management o Middleware support for management PAPER SUBMISSION Papers must be submitted electronically in postscript or PDF format. Detailed instructions are provided on the conference web site, http://www.cs.ucsb.edu/conferences/MMNS02. Paper length is limited to 20 double-spaced pages. The paper's cover page must include: title of paper, authors' names and affiliations, contact author's name and address (both postal and electronic), a short abstract, keywords, and submission area (from the list of relevant topics of interest). For any further information, please refer to the conference home page or direct your questions to almeroth@cs.ucsb.edu. IMPORTANT DATES Submission deadline: April 7, 2002 Notification of acceptance: June 30, 2002 Final version: July 28, 2002 Conference: October 6-9, 2002 -- ================================================== Muhammad Jaseemuddin Associate Professor Departement of Electrical and Computer Engineering Ryerson University 350 Victoria Street Toronto, ON M5B 2K3 Tel: +1 416 979-5000x6073 Fax: +1 416 979-5280 Email: jaseem@ee.ryerson.ca Web: http://www.ee.ryerson.ca/~jaseem ================================================== From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 12:11: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 MAA07039 for ; Fri, 1 Mar 2002 12:11:19 -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 JAA16588; Fri, 1 Mar 2002 09:09: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 JAA23265; Fri, 1 Mar 2002 09:07: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 g21H6iKL016954 for ; Fri, 1 Mar 2002 09:06:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21H6i8I016953 for mobile-ip-dist; Fri, 1 Mar 2002 09:06: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 g21H6eKL016946 for ; Fri, 1 Mar 2002 09:06: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 JAA22873 for ; Fri, 1 Mar 2002 09:06:41 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21630 for ; Fri, 1 Mar 2002 10:06:40 -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 772A62776 for ; Fri, 1 Mar 2002 11:06:39 -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 2554AE67 for ; Fri, 1 Mar 2002 11:06:39 -0600 (CST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g21H6cR31605; Fri, 1 Mar 2002 12:06:38 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA19893; Fri, 1 Mar 2002 12:06:38 -0500 Message-Id: <200203011706.AA19893@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: Fri, 01 Mar 2002 12:06: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: > BTW, I *strongly* object to using a port - all of the mipv6 > implementations to date are in kernel space, not daemons. > > => I object to your objection: > - your assumption that all MIPv6 implementations are in kernel space > is wrong Changing from essentially one type of DO to another does not impact the existing implementations that much, changing to a port would be a big mess since we must move from the IP layer to the socket layer. And you could still implement it as a daemon if Mipv6 is given a new "protocol" type since it's very easy to deliver all those packets to user-space. > - it is easy to use a port in kernel space (examples: NFS, Mobile IPv4, > etc). I've only seen Mobile IPv4 implementations in user-space, but I'll admit I haven't seen them all. NFS was moved into the kernel for performance reasons, and I wouldn't say it's easy to implement, there are a lot of tricks going on behind the scenes. -Brian From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 12:13:11 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 MAA07157 for ; Fri, 1 Mar 2002 12:13:11 -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 JAA17542; Fri, 1 Mar 2002 09:12: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 JAA24569; Fri, 1 Mar 2002 09:11: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 g21HAMKL017034 for ; Fri, 1 Mar 2002 09:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21HAMmZ017033 for mobile-ip-dist; Fri, 1 Mar 2002 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21HAIKL017023 for ; Fri, 1 Mar 2002 09:10: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 JAA18632; Fri, 1 Mar 2002 09:10:08 -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 JAA05019; Fri, 1 Mar 2002 09:07: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 JAA05348; Fri, 1 Mar 2002 09:06:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g21H6Zu28226; Fri, 1 Mar 2002 09:06:35 -0800 X-mProtect:  Fri, 1 Mar 2002 09:06:35 -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 smtpdFkU4Ch; Fri, 01 Mar 2002 09:06:33 PST Message-ID: <3C7FB51A.B4ED91E2@iprg.nokia.com> Date: Fri, 01 Mar 2002 09:06:34 -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: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destinationoptions References: <3C7EAE48.DC2ED610@iprg.nokia.com> <3C7F4B03.1030006@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, I understand and I go back to the original proposal that all responses to unverified HAO be tagged. Here is a way to tackle the packet loss issue. The CN would move to tagging state when it receives a packet with HAO (and hence start tagging right away). However, if it receives a packet without HAO but with HoA as source IP address, it goes back to no-tagging state and resides in that state until a timer (randomized) expires. This way, the MN's packets with HAO will not be dropped regardless of the state in which the CN is. Regards, -Rajeev Pekka Nikander wrote: > Rajeev Koodli wrote: > > 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 ? > > Looks quite bad from the DDoS reflection point of view. > If I am an attacker, able to spoof addresses, and > therefore subject to i-trace etc. (which is the > reason for the tagging), I can launch an easy but not > very good attack: > > 1. I send one packet to the CN, with no > HAO and src=HaO -> CN goes to no-tagging state. > This packet may trigger i-trace, but maybe I > can get somebody else to send the packet. > > 2. I send a few packets, with HAO=HaO, to the CN. > The CN replies to these, with dst=HaO. > The replies are not tagged, since the CN is > in no-tagging state, and therefore the > replies do not reveal me through i-trace etc. > > 3. Repeat the cycle. > > The practical effect of this attack is that I > can make the probablity of i-trace etc revealing > smaller than it otherwise could be. But this is > just one way of defeating the purpose of tagging, > there are probably more effective ones. > > Again: From the security point of view, it is > important that *no* packets that are replies to > any packet containing HAO leave the CN towards > the HoA, unless they contain the tag. If we > make an intentional hole into tagging, somebody > will find a way to (mis)use it, sooner or later. > > I do not like approaches that compromize existing > security for the sake of an optimization that may > or may not be videly used and that does not > necessarily bring that much benefit. Considering > the complexity of processing unvHAOs, how likely > is that somebody implements unvHAO processing > but not RR? RR requires no hard crypto, no > complicated states, and only 1.5 RTT. > > --Pekka From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 12:50: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 MAA09983 for ; Fri, 1 Mar 2002 12:50:46 -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 KAA15765; Fri, 1 Mar 2002 10:50: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 JAA10755; Fri, 1 Mar 2002 09:50: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 g21HneKL017140 for ; Fri, 1 Mar 2002 09:49:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21HndlD017139 for mobile-ip-dist; Fri, 1 Mar 2002 09:49: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 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 g21HnZKL017132 for ; Fri, 1 Mar 2002 09:49:36 -0800 (PST) Received: from lillen (vpn-129-156-96-41.EMEA.Sun.COM [129.156.96.41]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g21HnVx10561; Fri, 1 Mar 2002 18:49:31 +0100 (MET) Date: Fri, 1 Mar 2002 18:44:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: rajeev@iprg.nokia.com Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C7EAE48.DC2ED610@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. 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 ? For security reasons I think the CN needs to tag conservatively i.e. it is fine if it tags when it isn't needed. Getting this behavior as well as making the tagging logic be robust against packet loss and other ways the MN and CN can get out of synch is the hard part. I know one way to make it robust, but that ends up looking where much like a BU exchange: 1b MN(CoA) -> CN 2b CN -< HN(Coa) 3 MN(CoA) -> CN create unvHAO state please 4 CN -< HN(Coa) state created with lifetime X The 1b/2b exchange is there to prevent an attacker spoofing the source address from filling the unvHAO cache. The 3/4 exchange allows the MN to know that an entry was created and when it will be expired (so that the MN can renew it explicitly). The above is both secure and robust against packet loss as far as I understand. But I don't see any benefit of doing it since it looks almost like doing RO. > > 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 don't see how you can do that and still not have holes. > I mentioned this is useful (see below).. What if the BR is sent when the > entry is created and it includes a lifetime field ? That would help a bit (but it doesn't look like a BR any more but that is a detail). What if that BR is lost? Should the CN send one for every unvHAO it receives? Should the CN indicate that it wants to receive such a BR? Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 13:35: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 NAA13100 for ; Fri, 1 Mar 2002 13:35: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 LAA28023; Fri, 1 Mar 2002 11:35: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 KAA11064; Fri, 1 Mar 2002 10: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 g21IY5KL017261 for ; Fri, 1 Mar 2002 10:34:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21IY55i017260 for mobile-ip-dist; Fri, 1 Mar 2002 10:34: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 g21IXwKL017253 for ; Fri, 1 Mar 2002 10:33:58 -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 KAA25758 for ; Fri, 1 Mar 2002 10:33: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 LAA09327 for ; Fri, 1 Mar 2002 11:33:57 -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 TAA19414; Fri, 1 Mar 2002 19:31:35 +0100 From: "Henrik Levkowetz" To: , Subject: [mobile-ip] Revised NAT traversal draft Date: Fri, 1 Mar 2002 19:33:56 +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: <20010903.104642.884096194.takamiya@po.ntts.co.jp> Importance: Normal 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, I've submitted a new version of the MIPv4 NAT traversal draft. Until officially announced, it is available at http://www.levkowetz.com/pub/id/draft-ietf-mobileip-nat-traversal-01.txt . There is also an unpaginated version marked with changebars from the -00 draft to the -01 draft available as http://www.levkowetz.com/pub/id/changes-draft-ietf-mobileip-nat-traversal-00..1.txt The changes are: - Updated references, mostly due to the 2002bis draft becoming RFC - Explicit indication of the no-NAT case, through a reply code in the UDP Tunnelling Reply Exteion. Formerly, this was indicated through the absense of that extension in the reply. - Support for co-located registration through a foreign agent due to the 'R' bit being set in the advertisement. This was not covered in the -00 draft, and has necessitated new flag bits in the UDP Tunnelling extensions and Agent advertisements, and some new requirements. Comments are appreciated. Best regards, Henrik -- Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ You live and learn. Or you don't live long. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 14:26: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 OAA17695 for ; Fri, 1 Mar 2002 14:26: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 MAA23601; Fri, 1 Mar 2002 12:26: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 LAA26619; Fri, 1 Mar 2002 11:26: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 g21JPWKL017418 for ; Fri, 1 Mar 2002 11:25:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21JPVMm017417 for mobile-ip-dist; Fri, 1 Mar 2002 11:25: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 g21JPSKL017410 for ; Fri, 1 Mar 2002 11:25:28 -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 LAA29724 for ; Fri, 1 Mar 2002 11:25:28 -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 MAA05990 for ; Fri, 1 Mar 2002 12:25:28 -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 LAA16138; Fri, 1 Mar 2002 11:25:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g21JPIi06275; Fri, 1 Mar 2002 11:25:18 -0800 X-mProtect:  Fri, 1 Mar 2002 11:25:18 -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 smtpdp4afHd; Fri, 01 Mar 2002 11:25:16 PST Message-ID: <3C7FD59D.1BD7916B@iprg.nokia.com> Date: Fri, 01 Mar 2002 11:25:17 -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, Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@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 Hi Francis Francis Dupont wrote: > > I just tried putting together the format of the new extension > header. > > => we have to agree FIRST if this is a final or a non-final header. > BTW "a new extension header" is ambiguous but more for non-final, > and IPsec selectors don't work with non-final. This is a very crucial question. This needs to be resolved before we can proceed with piggybacking. If transport protocol is strictly speaking the only thing one interprets as possible for selector protocol number, this enforces non-piggybacking. But, if we can use mobility protocol besides transport protocol, this would require an implementation clarification on how you locate this protocol number by 2401. If you look at 2401, it says how to locate a transport number and describes a loop from which you bail out when you found a transport number. It is not talking about what it returns otherwise. Specifying we return it by position or by role gives two ways of returning it affecting the fundamentals of piggybacking rules. By position one could use current spec this way. Now it says 'scan to the end or until you hit unknown or ESP'. This would need clarification for mobility header: If one reaches no next header when locating transport protocol, use previous protocol if mobility protocol. That would use the same byte you normally read for transport. Returning a value by role changes some assumptions and may not work so well. Mobility header can't be always transport because you would not reach the actual transport in case you piggyback. Defining it as unknown does kind of work but would have the same problem from the exact transport search: you bail out with the unknown value too early and do not see the actual transport when you do piggyback. So to have no change requirement to IPsec standards and minimal implementation interpretation requirement would call returning it by position. We could mandate this interpretation for this header and it would have minimal or no effect to current implementations. The interpretation should be placed in MIPv6 spec as one sentence giving the extra exit condition for 2461 transport protocol search loop. We could call it is a transport protocol by position, that is, when it is the last header in the packet. In other words, when using mobility, IPsec implementations should allow for the use of last non-no-next-header value in this case. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 15:01: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 PAA21644 for ; Fri, 1 Mar 2002 15:01: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 NAA21576; Fri, 1 Mar 2002 13:01: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 MAA11427; Fri, 1 Mar 2002 12:01: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 g21K0KKL017523 for ; Fri, 1 Mar 2002 12:00:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21K0JcG017522 for mobile-ip-dist; Fri, 1 Mar 2002 12: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21K0GKL017515 for ; Fri, 1 Mar 2002 12:00: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 MAA25026 for ; Fri, 1 Mar 2002 12:00:17 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20379 for ; Fri, 1 Mar 2002 12:00:16 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id WAA01350; Fri, 1 Mar 2002 22:00:09 +0200 Date: Fri, 1 Mar 2002 22:00:09 +0200 Message-Id: <200203012000.WAA01350@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: <3C7FD59D.1BD7916B@iprg.nokia.com> (message from Vijay Devarapalli on Fri, 01 Mar 2002 11:25:17 -0800) Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> <3C7FD59D.1BD7916B@iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: Existing IPSEC combined with piggybagging will never work. Forget it! It can be made to work only with big addition into policy selector logic. Consider a policy remote_port=25, protocol=TCP -> "use protection 1" If you add piggybacking mobile IP to this, you have to define additional selector (2) remote_port=25, protocol=TCP, "piggypack-selector" -> "use protection 2" And to cater for traffic, that happens to go clear normally, you also need (3) "piggypack-selector" -> "use protection 3" In above, it doesn't matter whether we are using (a) new extension header or (b) the original idea of destination option. In both cases something new has to be added to the IPSEC selectors. [There is no way any automatic algorithm can derive "protection 2" and "protection 1" from the "protection 1". They must be explicitly told in policy!]. In (a), we need a selector mechanism that allows us to list a sequence of headers or prototocols, which if present, match the selector (e.g. instead of allowing just "transport protocol", we need a list of protocols which may be transport or not). (2) MIP6-protocol-number TCP remote_port=25 -> ... (3) MIP6-protocol-number -> ... In (b) we need a selector which has a protocol number with subparameters (2) DOP(BU-option) TCP remote_port=25 -> ... (3) DOP(BU-option) -> .. (Actually, if we go with this "subparameter-idea", the ports are just parameters to the TCP protocol matcher. For ICMP, subparameters would the type and code). I was always uncomfortable with the selector talking about "transport protocol". Just matching the given list of protocols (if any) with the packet is much cleaner. Selector matches, if all listed protocols are found matching while chasing the extension headers, before end of chain is reached. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 1 17:58: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 RAA04913 for ; Fri, 1 Mar 2002 17:58:12 -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 OAA07590; Fri, 1 Mar 2002 14:58:09 -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 OAA05762; Fri, 1 Mar 2002 14:58: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 g21Mv2KL017715 for ; Fri, 1 Mar 2002 14:57:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21Mv2lG017714 for mobile-ip-dist; Fri, 1 Mar 2002 14:57: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 g21MuxKL017707 for ; Fri, 1 Mar 2002 14:56:59 -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 OAA05430 for ; Fri, 1 Mar 2002 14:56:59 -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 PAA02086 for ; Fri, 1 Mar 2002 15:56: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 g21MuuX00770; Fri, 1 Mar 2002 16:56:57 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 16:56:57 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCA5E@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" , "'charliep@iprg.nokia.com'" Subject: [mobile-ip] posted RFC 3220 is missing part of section 3.6.1.2 & 3.6.1.3 Date: Fri, 1 Mar 2002 16:56:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C174.62B76DC0" Sender: owner-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_01C1C174.62B76DC0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; I was browsing RFC3220 which is posted on the web, until I reached section 3.6 "Mobile Node Consideration" It reference section 3.6.1.2. for the Mobile Node way to discover the Home Agent. Well, I think there is a part of that section missing. The following is what on the web: 3.6.1.2. Registration Request Fields This section provides specific rules by which mobile nodes pick values for the fields within the fixed portion of a Registration Request. A mobile node MAY set the 'S' bit in order to request that the home agent maintain prior mobility binding(s). Otherwise, the home agent deletes any previous binding(s) and replaces them with the new binding specified in the Registration Request. Multiple simultaneous mobility bindings are likely to be useful when a mobile node using at least one wireless network interface moves within wireless transmission range of more than one foreign agent. IP explicitly allows duplication of datagrams. When the home agent allows simultaneous bindings, it will tunnel a separate copy of each arriving datagram to each care-of address, and the mobile node will receive multiple copies of datagrams destined to it. The mobile node SHOULD set the 'D' bit if it is registering with a co-located care-of address. Otherwise, the 'D' bit MUST NOT be set. Perkins Standards Track [Page 41] RFC 3220 IP Mobility Support for IPv4 January 2002 A mobile node MAY set the 'B' bit to request its home agent to forward to it, a copy of broadcast datagrams received by its home agent from the home network. The method used by the home agent to forward broadcast datagrams depends on the type of care-of address registered by the mobile node, as determined by the 'D' bit in the mobile node's Registration Request: - If the 'D' bit is set, then the mobile node has indicated that it will decapsulate any datagrams tunneled to this care-of address itself (the mobile node is using a co-located care-of address). In this case, to forward such a received broadcast datagram to the mobile node, the home agent MUST tunnel it to this care-of address. The mobile node de-tunnels the received datagram in the same way as any other datagram tunneled directly to it. - If the 'D' bit is NOT set, then the mobile node has indicated that it is using a foreign agent care-of address, and that the foreign agent will thus decapsulate arriving datagrams before forwarding them to the mobile node. In this case, to forward such a received broadcast datagram to the mobile node, the home agent MUST first encapsulate the broadcast datagram in a unicast datagram addressed to the mobile node's home address, and then MUST tunnel this resulting datagram to the mobile node's care-of address. When decapsulated by the foreign agent, the inner datagram will thus be a unicast IP datagram addressed to the mobile node, identifying to the foreign agent the intended destination of the encapsulated broadcast datagram, and will be delivered to the mobile node in the same way as any tunneled datagram arriving for the mobile node. The foreign agent MUST NOT decapsulate the encapsulated broadcast datagram and MUST NOT use a local network broadcast to transmit it to the mobile node. The mobile node thus MUST decapsulate the encapsulated broadcast datagram itself, and thus MUST NOT set the 'B' bit in its Registration Request in this case unless it is capable of decapsulating datagrams. The mobile node MAY request alternative forms of encapsulation by setting the 'M' bit and/or the 'G' bit, but only if the mobile node is decapsulating its own datagrams (the mobile node is using a co- located care-of address) or if its foreign agent has indicated support for these forms of encapsulation by setting the corresponding bits in the Mobility Agent Advertisement Extension of an Agent Advertisement received by the mobile node. Otherwise, the mobile node MUST NOT set these bits. ********* HERE::: There is part of this section is missing and part of section 3.6.1.3 with its header is missing too ********* Perkins Standards Track [Page 42] RFC 3220 IP Mobility Support for IPv4 January 2002 a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be useful to the foreign agent), followed by c) An authorization-enabling extension, followed by d) If present, any non-authentication Extensions used only by the foreign agent, followed by e) The Mobile-Foreign Authentication Extension, if present. Note that items (a) and (c) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (e) are optional. However, item (e) MUST be included when the mobile node and the foreign agent share a mobility security association. I am not sure If I am missing something or not, BUT It even does not read right. Please take a look and verify this. Thanks a lot. Ahmad Muhanna ------_=_NextPart_001_01C1C174.62B76DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable posted RFC 3220 is missing part of section 3.6.1.2 & = 3.6.1.3

Hello Charlie;

I was browsing RFC3220 which is posted = on the web, until I reached section 3.6 "Mobile Node = Consideration"
It reference section 3.6.1.2. for the = Mobile Node way to discover the Home Agent.

Well, I think there is a part of = that section missing.
The following is what on the = web:

3.6.1.2. Registration Request = Fields

   This section provides = specific rules by which mobile nodes pick
   values for the fields = within the fixed portion of a Registration
   Request.

   A mobile node MAY set the = 'S' bit in order to request that the home
   agent maintain prior = mobility binding(s).  Otherwise, the home agent
   deletes any previous = binding(s) and replaces them with the new
   binding specified in the = Registration Request.  Multiple simultaneous
   mobility bindings are = likely to be useful when a mobile node using at
   least one wireless = network interface moves within wireless
   transmission range of = more than one foreign agent.  IP explicitly
   allows duplication of = datagrams.  When the home agent allows
   simultaneous bindings, = it will tunnel a separate copy of each
   arriving datagram to = each care-of address, and the mobile node will
   receive multiple copies = of datagrams destined to it.

   The mobile node SHOULD = set the 'D' bit if it is registering with a
   co-located care-of = address.  Otherwise, the 'D' bit MUST NOT be set.




Perkins        &n= bsp;            = Standards = Track           &= nbsp;        [Page 41]


RFC = 3220           &n= bsp;  IP Mobility Support for = IPv4          January = 2002


   A mobile node MAY set the = 'B' bit to request its home agent to
   forward to it, a copy of = broadcast datagrams received by its home
   agent from the home = network.  The method used by the home agent to
   forward broadcast = datagrams depends on the type of care-of address
   registered by the mobile = node, as determined by the 'D' bit in the
   mobile node's = Registration Request:

      -  = If the 'D' bit is set, then the mobile node has indicated that
         it will = decapsulate any datagrams tunneled to this care-of
         address = itself (the mobile node is using a co-located care-of
         = address).  In this case, to forward such a received = broadcast
         = datagram to the mobile node, the home agent MUST tunnel it to
         this = care-of address.  The mobile node de-tunnels the received
         = datagram in the same way as any other datagram tunneled
         = directly to it.

      -  = If the 'D' bit is NOT set, then the mobile node has indicated
         that it = is using a foreign agent care-of address, and that the
         foreign = agent will thus decapsulate arriving datagrams before
         = forwarding them to the mobile node.  In this case, to = forward
         such a = received broadcast datagram to the mobile node, the home
         agent = MUST first encapsulate the broadcast datagram in a
         unicast = datagram addressed to the mobile node's home address,
         and = then MUST tunnel this resulting datagram to the mobile
         node's = care-of address.

         When = decapsulated by the foreign agent, the inner datagram will
         thus be = a unicast IP datagram addressed to the mobile node,
         = identifying to the foreign agent the intended destination of
         the = encapsulated broadcast datagram, and will be delivered to
         the = mobile node in the same way as any tunneled datagram
         = arriving for the mobile node.  The foreign agent MUST NOT
         = decapsulate the encapsulated broadcast datagram and MUST NOT
         use a = local network broadcast to transmit it to the mobile
         = node.  The mobile node thus MUST decapsulate the = encapsulated
      &n= bsp;  broadcast datagram itself, and thus MUST NOT set the 'B' bit = in
         its = Registration Request in this case unless it is capable of
         = decapsulating datagrams.

   The mobile node MAY = request alternative forms of encapsulation by
   setting the 'M' bit = and/or the 'G' bit, but only if the mobile node
   is decapsulating its own = datagrams (the mobile node is using a co-
   located care-of address) = or if its foreign agent has indicated
   support for these forms = of encapsulation by setting the corresponding
   bits in the Mobility = Agent Advertisement Extension of an Agent
   Advertisement received = by the mobile node.  Otherwise, the mobile
   node MUST NOT set these = bits.


********* HERE::: There is = part of this section is missing and part of section 3.6.1.3 with its = header is missing too *********

Perkins        &n= bsp;            = Standards = Track           &= nbsp;        [Page 42]


RFC = 3220           &n= bsp;  IP Mobility Support for = IPv4          January = 2002


      a) The = IP header, followed by the UDP header, followed by the
         = fixed-length portion of the Registration Request, followed by

      b) If = present, any non-authentication Extensions expected to be
         used by = the home agent (which may or may not also be useful to
         the = foreign agent), followed by

      c) An = authorization-enabling extension, followed by

      d) If = present, any non-authentication Extensions used only by the
         foreign = agent, followed by

      e) The = Mobile-Foreign Authentication Extension, if present.

   Note that items (a) and = (c) MUST appear in every Registration Request
   sent by the mobile = node.  Items (b), (d), and (e) are optional.
   However, item (e) MUST = be included when the mobile node and the
   foreign agent share a = mobility security association.


I am not sure If I am missing = something or not, BUT It even does = not read right.
Please take a look and verify = this.

Thanks a lot.

Ahmad Muhanna


------_=_NextPart_001_01C1C174.62B76DC0-- From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 2 07:44: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 HAA29622 for ; Sat, 2 Mar 2002 07:44: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 EAA16605; Sat, 2 Mar 2002 04:44: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 EAA16051; Sat, 2 Mar 2002 04:44: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 g22ChjKL018295 for ; Sat, 2 Mar 2002 04:43:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g22ChjIs018294 for mobile-ip-dist; Sat, 2 Mar 2002 04:43: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 g22ChgKL018287 for ; Sat, 2 Mar 2002 04:43:42 -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 EAA20788 for ; Sat, 2 Mar 2002 04:43:42 -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 FAA11116 for ; Sat, 2 Mar 2002 05:43: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 g22ChMk19229; Sat, 2 Mar 2002 13:43:22 +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 NAA20727; Sat, 2 Mar 2002 13:43: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 g22ChMg97093; Sat, 2 Mar 2002 13:43:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203021243.g22ChMg97093@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) In-reply-to: Your message of Fri, 01 Mar 2002 11:25:17 PST. <3C7FD59D.1BD7916B@iprg.nokia.com> Date: Sat, 02 Mar 2002 13:43:22 +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 just tried putting together the format of the new extension > header. > > => we have to agree FIRST if this is a final or a non-final header. > BTW "a new extension header" is ambiguous but more for non-final, > and IPsec selectors don't work with non-final. This is a very crucial question. This needs to be resolved before we can proceed with piggybacking. If transport protocol is strictly speaking the only thing one interprets as possible for selector protocol number, this enforces non-piggybacking. => it is, RFC 2401 is not ambiguous this time: - Transport Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields. This may be an individual protocol number. These packet fields may not contain the Transport Protocol due to the presence of IP extension headers, e.g., a Routing Header, AH, ESP, Fragmentation Header, Destination Options, Hop-by-hop options, etc. Note that the Transport Protocol may not be available in the case of receipt of a packet with an ESP header, thus a value of "OPAQUE" SHOULD be supported. [REQUIRED for all implementations] NOTE: To locate the transport protocol, a system has to chain through the packet headers checking the "Protocol" or "Next Header" field until it encounters either one it recognizes as a transport protocol, or until it reaches one that isn't on its list of extension headers, or until it encounters an ESP header that renders the transport protocol opaque. So piggy-backing and IPsec are essentially not compatible... (the only hack which could work is to define a new no-next-header dedicated to mobility). But, if we can use mobility protocol besides transport protocol, this would require an implementation clarification on how you locate this protocol number by 2401. => and modify all the existing IPsec implementations? NO! If you look at 2401, it says how to locate a transport number and describes a loop from which you bail out when you found a transport number. It is not talking about what it returns otherwise. => your English and mine are not the same (:-). This would need clarification for mobility header: => no, you can not make the mobility header both final and non-final! Mobility header can't be always transport because you would not reach the actual transport in case you piggyback. => this is the problem: - for IPsec they MUST be final (aka transport) - for piggy-backing they MUST be non-final So to have no change requirement to IPsec standards and minimal implementation interpretation requirement would call returning it by position. => NO! In other words, when using mobility, IPsec implementations should allow for the use of last non-no-next-header value in this case. => I *strongly* object and if your "solution" is accepted by the mobile-ip WG I'll ask the IESG to consult ipv6 and ipsec WGs. Regards Francis.Dupont@enst-bretagne.fr PS: this problem was discussed many times in the last two years. From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 2 07:59: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 HAA29796 for ; Sat, 2 Mar 2002 07:59:07 -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 FAA22383; Sat, 2 Mar 2002 05: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 EAA17787; Sat, 2 Mar 2002 04:58: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 g22Cw0KL018386 for ; Sat, 2 Mar 2002 04:58:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g22Cw00l018385 for mobile-ip-dist; Sat, 2 Mar 2002 04:58: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 g22CvvKL018378 for ; Sat, 2 Mar 2002 04:57: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 EAA17653 for ; Sat, 2 Mar 2002 04:57:58 -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 FAA00248 for ; Sat, 2 Mar 2002 05:57:57 -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 g22Cvtk19723 for ; Sat, 2 Mar 2002 13:57: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 NAA20888 for ; Sat, 2 Mar 2002 13:57:55 +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 g22Cvtg97142 for ; Sat, 2 Mar 2002 13:57:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203021257.g22Cvtg97142@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) In-reply-to: Your message of Fri, 01 Mar 2002 22:00:09 +0200. <200203012000.WAA01350@burp.tkv.asdf.org> Date: Sat, 02 Mar 2002 13:57: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: Existing IPSEC combined with piggybagging will never work. Forget it! => I agree but some of us seem to be ready to twist IPsec and IPv6... It can be made to work only with big addition into policy selector logic. => basically what is needed is multi-protocol policy selector, something which is hard to specified, hard to implement, likely very inefficient and a nightmare to configure... (PS: (a) is the real multi-protocol, (b) is even worse, this is sub-parameter selector). (Actually, if we go with this "subparameter-idea", the ports are just parameters to the TCP protocol matcher. For ICMP, subparameters would the type and code). => the ICMP example shows the subparameter-idea is very limited because if it is easy to associate a service to port selectors, this is not the case for ICMP type&code: for instance to give a different protection to Neighbor Discovery you need 4 or 5 rules (multiplied by source/destinations). Profiles should be better but they need to be specified far before to be usable in the real world between different implementations... I was always uncomfortable with the selector talking about "transport protocol". Just matching the given list of protocols (if any) with the packet is much cleaner. Selector matches, if all listed protocols are found matching while chasing the extension headers, before end of chain is reached. => this is more powerful but too complex to handle and to use. I am very uncomfortable with anything which can increase the IPsec complexity, and this feeling seems to be shared by many people. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 2 18:43: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 SAA06494 for ; Sat, 2 Mar 2002 18:43:05 -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 PAA17913; Sat, 2 Mar 2002 15:42:56 -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 PAA13804; Sat, 2 Mar 2002 15:42: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 g22Ng1KL018921 for ; Sat, 2 Mar 2002 15:42:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g22Ng16r018920 for mobile-ip-dist; Sat, 2 Mar 2002 15:42: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 g22NfwKL018913 for ; Sat, 2 Mar 2002 15:41:58 -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 PAA06404 for ; Sat, 2 Mar 2002 15:41:59 -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 QAA27020 for ; Sat, 2 Mar 2002 16:41:58 -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 PAA14317 for ; Sat, 2 Mar 2002 15:41:53 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g22Nfri24036 for ; Sat, 2 Mar 2002 15:41:53 -0800 X-mProtect:  Sat, 2 Mar 2002 15:41:53 -0800 Nokia Silicon Valley Messaging Protection Received: from davpndhcp1741.americas.nokia.com (172.18.174.1, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDXWd63; Sat, 02 Mar 2002 15:41:51 PST Message-ID: <3C816324.6070605@iprg.nokia.com> Date: Sat, 02 Mar 2002 15:41:24 -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] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> <3C7FD59D.1BD7916B@iprg.nokia.com> <200203012000.WAA01350@burp.tkv.asdf.org> 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 Markku and Francis, Jari Malinen and I had sent a writeup to the design team describing when you can piggyback and when you cant, when you have IPSec turned on. We concluded that piggybacking is possible only in two cases out of four. Heres a table from the writeup Table 1. Piggybacking with IPsec IPSec policy for IPSec policy Mobility header for Payload Can piggyback 1. no no yes 2. no yes yes 3. yes no no 4. yes yes no From the table, the sender does not piggyback at all whenever the mobility extension header has an IPSec policy. For handling the first two cases, there is no need for any change to RFC 2401 or the existing IPSec implementations. Please let me know if I am wrong. One more thing, Markku, we are NOT asking for any changes to RFC 2401. If anything that we propose requires changes to IPSec, we will immediately drop the idea. Do not worry :) I will address protecting Mobility extension header (in a non-piggybacked packet) with IPSec in a separate mail. Looks like we are interpreting RFC 2401 protocol selector scan differently. Vijay Markku Savela wrote: > Existing IPSEC combined with piggybagging will never work. Forget it! > > It can be made to work only with big addition into policy selector > logic. > > Consider a policy > > remote_port=25, protocol=TCP > -> "use protection 1" > > If you add piggybacking mobile IP to this, you have to define > additional selector > > (2) remote_port=25, protocol=TCP, "piggypack-selector" > -> "use protection 2" > > And to cater for traffic, that happens to go clear normally, you also > need > > (3) "piggypack-selector" -> "use protection 3" > > In above, it doesn't matter whether we are using (a) new extension > header or (b) the original idea of destination option. In both cases > something new has to be added to the IPSEC selectors. [There is no way > any automatic algorithm can derive "protection 2" and "protection 1" > from the "protection 1". They must be explicitly told in policy!]. > > In (a), we need a selector mechanism that allows us to list a sequence > of headers or prototocols, which if present, match the selector > (e.g. instead of allowing just "transport protocol", we need a list of > protocols which may be transport or not). > > (2) MIP6-protocol-number TCP remote_port=25 -> ... > (3) MIP6-protocol-number -> ... > > In (b) we need a selector which has a protocol number with > subparameters > > (2) DOP(BU-option) TCP remote_port=25 -> ... > (3) DOP(BU-option) -> .. > > (Actually, if we go with this "subparameter-idea", the ports are just > parameters to the TCP protocol matcher. For ICMP, subparameters would > the type and code). > > I was always uncomfortable with the selector talking about "transport > protocol". Just matching the given list of protocols (if any) with the > packet is much cleaner. Selector matches, if all listed protocols are > found matching while chasing the extension headers, before end of > chain is reached. > From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 03:01: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 DAA20180 for ; Sun, 3 Mar 2002 03:01: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 XAA09743; Sat, 2 Mar 2002 23:59:56 -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 XAA17507; Sat, 2 Mar 2002 23:58: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 g237w2KL019209 for ; Sat, 2 Mar 2002 23:58:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g237w2ok019208 for mobile-ip-dist; Sat, 2 Mar 2002 23:58: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 g237vwKL019201 for ; Sat, 2 Mar 2002 23:57:58 -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 XAA07890 for ; Sat, 2 Mar 2002 23:57:58 -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 XAA27957 for ; Sat, 2 Mar 2002 23:57:57 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id E87BFA; Sun, 3 Mar 2002 09:59:47 +0200 (EET) Message-ID: <3C81D784.6020106@nomadiclab.com> Date: Sun, 03 Mar 2002 09:57:56 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020226 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, rajeev@iprg.nokia.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options 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: > For security reasons I think the CN needs to tag conservatively i.e. it > is fine if it tags when it isn't needed. Not so simple. As I argued in another message, *if* firewalls drop tagged packets, tagging when not needed leads to nasty denial-of-service attacks against stationary hosts. Which brings forth an idea: would it be possible to use some variant of the "one bit" method to signal that a host using a given address *is* a stationary host, and unvHAOs should not be accepted for that address at all? In any case, the bidding down attack is most vicious against stationary hosts that do not understand MIPv6 signalling at all. I know this idea has lots of problems, but maybe somebody could use the idea to develop something really useful. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 08:26: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 IAA23117 for ; Sun, 3 Mar 2002 08:26: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 GAA17415; Sun, 3 Mar 2002 06:26:00 -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 FAA24371; Sun, 3 Mar 2002 05:25: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 g23DOoKL019448 for ; Sun, 3 Mar 2002 05:24:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23DOnek019447 for mobile-ip-dist; Sun, 3 Mar 2002 05:24: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 g23DOkKL019440 for ; Sun, 3 Mar 2002 05:24:46 -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 FAA26493 for ; Sun, 3 Mar 2002 05:24:47 -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 FAA04987 for ; Sun, 3 Mar 2002 05:24:42 -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 g23DOZk13476 for ; Sun, 3 Mar 2002 14:24:36 +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 OAA03491 for ; Sun, 3 Mar 2002 14:24:36 +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 g23DOZg00160 for ; Sun, 3 Mar 2002 14:24:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031324.g23DOZg00160@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) In-reply-to: Your message of Sat, 02 Mar 2002 15:41:24 PST. <3C816324.6070605@iprg.nokia.com> Date: Sun, 03 Mar 2002 14:24:35 +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: Jari Malinen and I had sent a writeup to the design team describing when you can piggyback and when you cant, when you have IPSec turned on. We concluded that piggybacking is possible only in two cases out of four. Heres a table from the writeup Table 1. Piggybacking with IPsec IPSec policy for IPSec policy Mobility header for Payload Can piggyback 1. no no yes 2. no yes yes 3. yes no no 4. yes yes no From the table, the sender does not piggyback at all whenever the mobility extension header has an IPSec policy. => the mobility extension header can have an IPsec policy only if it is final, i.e. not an "extension" header. Sorry but this was discussed along the last two years: you are only losing your time. For handling the first two cases, there is no need for any change to RFC 2401 or the existing IPSec implementations. Please let me know if I am wrong. => the cases 1 and 2 have no "IPsec policy for Mobility header" so they could work with current IPsec. One more thing, Markku, we are NOT asking for any changes to RFC 2401. If anything that we propose requires changes to IPSec, we will immediately drop the idea. Do not worry :) => so drop the idea of an IPsec policy for a non-final header. I will address protecting Mobility extension header (in a non-piggybacked packet) with IPSec in a separate mail. Looks like we are interpreting RFC 2401 protocol selector scan differently. => please don't twist IPsec in order to fill your needs. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 09:38: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 JAA23933 for ; Sun, 3 Mar 2002 09:38:43 -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 GAA26429; Sun, 3 Mar 2002 06:38: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 GAA27844; Sun, 3 Mar 2002 06:38: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 g23EbRKL019551 for ; Sun, 3 Mar 2002 06:37:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23EbRKU019550 for mobile-ip-dist; Sun, 3 Mar 2002 06:37: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 g23EbOKL019543 for ; Sun, 3 Mar 2002 06:37: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 GAA04676 for ; Sun, 3 Mar 2002 06:37: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 GAA06417 for ; Sun, 3 Mar 2002 06:37: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 g23EbHk16186 for ; Sun, 3 Mar 2002 15:37: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 PAA04260 for ; Sun, 3 Mar 2002 15:37: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 g23EbHg01085 for ; Sun, 3 Mar 2002 15:37:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031437.g23EbHg01085@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 Thu, 14 Feb 2002 18:56:20 +0100. <4DA6EA82906FD511BE2F00508BCF053803258898@Esealnt861.al.sw.ericsson.se> Date: Sun, 03 Mar 2002 15:37: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: 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. => I would not like to go backward in the Mobile IPv6 security issue, so do you accept an IPsec SA with the proper authorization is enough to protect the BU, yes or no? (i.e. do you agree with I-D 00-15 or not about the security constraints?) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 09:53: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 JAA24145 for ; Sun, 3 Mar 2002 09:53: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 HAA03402; Sun, 3 Mar 2002 07:53:30 -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 GAA28569; Sun, 3 Mar 2002 06:53: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 g23EqSKL019627 for ; Sun, 3 Mar 2002 06:52:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23EqS1r019626 for mobile-ip-dist; Sun, 3 Mar 2002 06:52: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 g23EqPKL019619 for ; Sun, 3 Mar 2002 06:52:25 -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 GAA27794 for ; Sun, 3 Mar 2002 06:52:25 -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 GAA14772 for ; Sun, 3 Mar 2002 06:52: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 g23EqLk17135; Sun, 3 Mar 2002 15: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 PAA04453; Sun, 3 Mar 2002 15:52: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 g23EqLg01132; Sun, 3 Mar 2002 15:52:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031452.g23EqLg01132@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: vijayd@iprg.nokia.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation In-reply-to: Your message of Thu, 14 Feb 2002 19:42:59 +0100. Date: Sun, 03 Mar 2002 15:52: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: It depends on what authority you associate with the IPsec SA i.e. the policy associated with it. => this does not justify the "MUST NOT" for IPsec alone which is BTW a major step backward (Mobile IPv6 I-Ds had a MUST, IESG asked to change it in a MAY). 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 => as we definitively disagree about what is a certificate I prefer to avoid a new boring discussion. You just don't believe in a very common use of IPsec based VPNs... 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. => this scaling issue is true but still doesn't justify the implicit "MUST NOT" for IPsec alone. So this is the motivation for saying that in general IPsec need to be used in addition to RR. => I *strongly* disagree, especially if the "in general" is replaced by "always". Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 10: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 KAA24458 for ; Sun, 3 Mar 2002 10:10: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 HAA27930; Sun, 3 Mar 2002 07:10:26 -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 HAA00103; Sun, 3 Mar 2002 07:10: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 g23F9ZKL019697 for ; Sun, 3 Mar 2002 07:09:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23F9ZYP019696 for mobile-ip-dist; Sun, 3 Mar 2002 07:09: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 g23F9VKL019689 for ; Sun, 3 Mar 2002 07:09: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 HAA29188 for ; Sun, 3 Mar 2002 07:09:31 -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 IAA28124 for ; Sun, 3 Mar 2002 08:09: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 g23F9Ck18613; Sun, 3 Mar 2002 16:09: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 QAA04773; Sun, 3 Mar 2002 16:09:12 +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 g23F9Cg01177; Sun, 3 Mar 2002 16:09:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031509.g23F9Cg01177@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation In-reply-to: Your message of Thu, 14 Feb 2002 11:46:17 PST. <3C6C1409.A0203AEE@iprg.nokia.com> Date: Sun, 03 Mar 2002 16:09: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: Francis Dupont wrote: > => for quick comments before reading the 35 other messages of the thread! I am also stumbling under this burden. => argh! The 35 moved in ~100... > => 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. => this is obviously not true and the large number of answers against the piggy-backing should show your view is not shared by everybody... - Your point here is not against Binding Update + payload specifically, but against generalized multi-payloads. => yes, if the L2 arguments show piggy-backing is good, they should show that multi-payloads are good. 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. => eventually be done? The strong consensus in the IPv6 WG was clearly this is a very bad idea. - 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. => as control and data planes are not separated (i.e. signaling is online), any pros or cons for piggy-backing can be translated in the same argument for multi-payloads. > 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. => I didn't write security policies, but any policies. That problem is already solved by use of the Binding Authentication Data suboption. => not if you'd like to keep the possibility to use IPsec for BU protection. The option to solve the piggy-backing & IPsec interference by dropping IPsec is *not* admissible. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 10:37: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 KAA24950 for ; Sun, 3 Mar 2002 10:37:39 -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 IAA09000; Sun, 3 Mar 2002 08:37: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 HAA03593; Sun, 3 Mar 2002 07:37: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 g23FanKL019796 for ; Sun, 3 Mar 2002 07:36:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23Fanso019795 for mobile-ip-dist; Sun, 3 Mar 2002 07:36: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 g23FakKL019788 for ; Sun, 3 Mar 2002 07:36:46 -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 HAA11052 for ; Sun, 3 Mar 2002 07:36:46 -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 IAA00219 for ; Sun, 3 Mar 2002 08:36:39 -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 g23FaGk19871 for ; Sun, 3 Mar 2002 16: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 QAA05132 for ; Sun, 3 Mar 2002 16: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 g23FaGg01252 for ; Sun, 3 Mar 2002 16:36:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031536.g23FaGg01252@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 Thu, 14 Feb 2002 22:26:31 GMT. <7F22D3F12C971940848892967327FEB604DB2303@TVP-MSG-01.europe.corp.microsoft.com> Date: Sun, 03 Mar 2002 16: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: 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 => this should be easy. (b) Check that the sender is authorized to the the CoA => I *strongly* disagree because what is needed in (b) is the authorization to use a CoA, not to use this CoA. BTW strong authorization to use a transient address is near infeasible and if we want to mandate your (b) we should before forbid IPsec based VPNs with mobile nodes (in fact nomadic nodes, aka "road warriors"). 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. => until DNSSEC is widely available, IMHO we should avoid to use certificates without addresses. BTW for MN-CN SA establishment there is no reason to use something else than HoA for IKE message transport, in identities (both phases 1 & 2) and in certificates. 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. => another reason is you don't want to do the whole thing for each hand-off. The problem is you ask for the wrong authorization. My current view is that: - you have to do RR for the CoA in all cases; => obviously an overkilling! Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 11:14: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 LAA25485 for ; Sun, 3 Mar 2002 11:14: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 JAA13644; Sun, 3 Mar 2002 09:14: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 IAA15935; Sun, 3 Mar 2002 08:14: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 g23GDYKL019900 for ; Sun, 3 Mar 2002 08:13:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23GDYjj019899 for mobile-ip-dist; Sun, 3 Mar 2002 08:13: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g23GDVKL019892 for ; Sun, 3 Mar 2002 08:13:31 -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 IAA03581 for ; Sun, 3 Mar 2002 08:13:32 -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 JAA13506 for ; Sun, 3 Mar 2002 09:13: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 g23GDSk22040; Sun, 3 Mar 2002 17:13: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 RAA05680; Sun, 3 Mar 2002 17:13: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 g23GDSg01340; Sun, 3 Mar 2002 17:13:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031613.g23GDSg01340@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "'Charlie Perkins'" , "Hesham Soliman (ERA)" Subject: Re: [Fwd: Re: [mobile-ip] Piggybacking - DT recommendation] In-reply-to: Your message of Fri, 15 Feb 2002 16:58:17 +0100. <4DA6EA82906FD511BE2F00508BCF053802C6AA2B@Esealnt861.al.sw.ericsson.se> Date: Sun, 03 Mar 2002 17:13: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: > 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? => HoA address (no need for something else between a MN and a CN). - 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). => yes, if you are authorized to do that you are authorized to do that, where is the problem? The ownership of a HoA does NOT give you the right => we don't speak about ownership, but about strong authentication and authorization. to forward traffic to any address (CoA) on the Internet. => this is what is authorized, and you need the strong authentication in order to really verify the BU is from the node using the HoA. Is your concern the MN may reroute the traffic to itself to a fake CoA? (note this traffic will contain your HoA in a RH type 2) 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. => we agree And you still need to prove that you own a CoA of course. => no, you don't need. Authenticating someone doesn't necessarily give them authorisation to do whatever they want. => we lost one year with the authentication is not authorization thread, please, not again. For the BU, the proof of ownership for the HoA and Coa is needed. => I disagree. Strong authentication of the HoA and authorization to perform BUs are enough too. => What's AAA doing here? My response was on manually configured SAs! => nobody uses configured SAs, please put real tools (IKE for instance) in the context. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 11:31:15 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 LAA25803 for ; Sun, 3 Mar 2002 11:31:15 -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 JAA07504; Sun, 3 Mar 2002 09:31: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 IAA18243; Sun, 3 Mar 2002 08: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 g23GTuKL019982 for ; Sun, 3 Mar 2002 08:29:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23GTuOi019981 for mobile-ip-dist; Sun, 3 Mar 2002 08:29: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g23GTqKL019974 for ; Sun, 3 Mar 2002 08:29:52 -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 IAA10197 for ; Sun, 3 Mar 2002 08:29:53 -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 IAA24946 for ; Sun, 3 Mar 2002 08:29:52 -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 g23GTnk22890; Sun, 3 Mar 2002 17:29:49 +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 RAA05848; Sun, 3 Mar 2002 17:29:49 +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 g23GTng01382; Sun, 3 Mar 2002 17:29:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031629.g23GTng01382@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Charles Perkins , "Hesham Soliman (ERA)" Subject: Re: [mobile-ip] Hesham's note about security and Piggybacking - DT recommendation] In-reply-to: Your message of Fri, 15 Feb 2002 08:47:26 PST. <3C6D3B9E.8FA523FB@iprg.nokia.com> Date: Sun, 03 Mar 2002 17:29:49 +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: If we (still) disagree about merits of piggy-packing, we 100% agree about the security stuff (cf. draft-dupont-ipsec-mipv6-00.txt and the answer to Hesham's note). Some details: - there is no standardized way to say a node is a MN so it is authorized to send BUs but: * the "road warrior" case in VPNs is already supported by all IPsec based VPN implementations, something similar can be specified. * the "home address" identity can be considered as an implicit authorization too (note: this implies a modification of X.509 certificate format?) - the authenticated and authorized BU to a fake CoA threat is not serious: the traffic from the CN to the target (the real user of the CoA) will contain a RH type 2 with the HoA (i.e. the real attacker) in each packet or fragment. If this is not enough for someone he should have shouted against the "new proposal for HAO". So I still argue IPsec without RR MAY protect BUs if the protection covers enough fields (i.e. with ESP an alternate CoA is required, etc), and the protection includes authentication (should be always the case) and the MN is authorized to send BUs. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 11:43: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 LAA25978 for ; Sun, 3 Mar 2002 11:43:58 -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 IAA02037; Sun, 3 Mar 2002 08:43:57 -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 IAA05258; Sun, 3 Mar 2002 08:43: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 g23GgmKL020052 for ; Sun, 3 Mar 2002 08:42:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23GgmiS020051 for mobile-ip-dist; Sun, 3 Mar 2002 08:42: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 g23GgjKL020044 for ; Sun, 3 Mar 2002 08:42: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 IAA05174 for ; Sun, 3 Mar 2002 08:42:46 -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 JAA18671 for ; Sun, 3 Mar 2002 09:42:44 -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 g23Ggfk23678; Sun, 3 Mar 2002 17:42:41 +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 RAA05977; Sun, 3 Mar 2002 17:42:42 +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 g23Ggfg01432; Sun, 3 Mar 2002 17:42:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031642.g23Ggfg01432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: mroe@microsoft.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation In-reply-to: Your message of Mon, 18 Feb 2002 16:28:56 +0100. Date: Sun, 03 Mar 2002 17:42:41 +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 above assumes that there are CAs for PKIs that will actually put IP addresses as subject(Alt)name, => CAs may do that (and OpenBSD certpatch can help to add that :-). and that folks will actually trust those CAs to have correct IP addresses in the certs. => basically folks trust CAs (:-)! 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. => I agree but the end of section 3.4 stands: Ubiquitous deployment of the Secure DNS Extensions ([8]) should be strongly encouraged to facilitate widespread deployment of IPsec (including IKE) without address-based Identity types. So until we have a secured way to verify name-address mapping (DNSSEC is the obvious candidate) I am reluctant to encourage IKE phase one where the addresses can not be verified (this should be allowed but with restriction, look at my I-D about IPsec and Mobile IPv6 for the beginning of a discussion. BTW this is an 100% IPsec topic). 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 => Mike's message seemed to assume manual keying... BTW I agree with your conditionals (and added some others in my I-D). Thanks Francis.Dupont@enst-bretagne.fr PS: do you know why RFC 2956 section 3.4 is explicitely about IPv4 addresses (32-bit IP addresses)? Is there something I've missed? From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 11:48: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 LAA26056 for ; Sun, 3 Mar 2002 11:48:54 -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 JAA18146; Sun, 3 Mar 2002 09:48: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 IAA05805; Sun, 3 Mar 2002 08:48: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 g23GmGKL020117 for ; Sun, 3 Mar 2002 08:48:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23GmFtB020116 for mobile-ip-dist; Sun, 3 Mar 2002 08:48: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 g23GmCKL020109 for ; Sun, 3 Mar 2002 08:48:12 -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 IAA05726 for ; Sun, 3 Mar 2002 08:48:13 -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 JAA19320 for ; Sun, 3 Mar 2002 09:48:12 -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 g23Gm9k24043 for ; Sun, 3 Mar 2002 17:48: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 RAA06044 for ; Sun, 3 Mar 2002 17:48: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 g23GmAg01464 for ; Sun, 3 Mar 2002 17:48:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031648.g23GmAg01464@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 Mon, 18 Feb 2002 10:06:30 PST. <3C7142A6.5E14C726@iprg.nokia.com> Date: Sun, 03 Mar 2002 17:48:10 +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: > 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. => I can see a real problem for the same "protocol" to be both final and not-final. In the future, when selectors get extended to support => when == never (IPsec is already too complex). 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. => James' compromise is a good idea but this detail has to be fixed. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 11: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 LAA26154 for ; Sun, 3 Mar 2002 11:54:49 -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 JAA20066; Sun, 3 Mar 2002 09:54: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 IAA06310; Sun, 3 Mar 2002 08: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 g23GrnKL020184 for ; Sun, 3 Mar 2002 08:53:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23Grn4F020183 for mobile-ip-dist; Sun, 3 Mar 2002 08:53: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 g23GrkKL020176 for ; Sun, 3 Mar 2002 08:53:46 -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 IAA21085 for ; Sun, 3 Mar 2002 08:53:47 -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 JAA10303 for ; Sun, 3 Mar 2002 09:53: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 g23Grhk24367 for ; Sun, 3 Mar 2002 17:53: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 RAA06088 for ; Sun, 3 Mar 2002 17:53: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 g23Grhg01493 for ; Sun, 3 Mar 2002 17:53:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203031653.g23Grhg01493@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, 19 Feb 2002 09:04:24 +0200. <01fe01c1b913$a9fe0a40$8a1b6e0a@arenanet.fi> Date: Sun, 03 Mar 2002 17:53: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: ... 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... => this is explicitely suggested in my IPv6 payload header I-Ds and the first one was announced in the ROHC list (do you think I should announce the new version again in the ROHC list?) Thanks Francis.Dupont@enst-bretagne.fr PS: for me ROHC is the only place at the IETF where this can be done, link-layers are not in our scope... From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 23:11: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 XAA05283 for ; Sun, 3 Mar 2002 23:11:36 -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 VAA07185; Sun, 3 Mar 2002 21:11: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 UAA16375; Sun, 3 Mar 2002 20:11: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 g244AfKL020871 for ; Sun, 3 Mar 2002 20:10:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g244AfO1020870 for mobile-ip-dist; Sun, 3 Mar 2002 20:10: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 g244AbKL020863 for ; Sun, 3 Mar 2002 20:10:37 -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 UAA21359 for ; Sun, 3 Mar 2002 20:10:39 -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 VAA06947 for ; Sun, 3 Mar 2002 21:10:38 -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 g244AbB09532 for ; Mon, 4 Mar 2002 05:10:38 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 05:09:21 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 05:10:37 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA5A@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, 4 Mar 2002 05:10:36 +0100 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 g244AcKL020864 Sender: owner-mobile-ip@sunroof.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 Francis, OK, so I'm not the only one who goes on holidays and tries to catch up with old email :) > 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. > > => I would not like to go backward in the Mobile IPv6 > security issue, > so do you accept an IPsec SA with the proper authorization is > enough to protect the BU, yes or no? (i.e. do you agree with > I-D 00-15 or not about the security constraints?) => I think it's enough to authorise the use of the HoAö if included inside the Certs. However, the issue was brought up by the DT and several drafts to highlight that there is a need to prove ownership of the CoA to avoid bombing attacks. You clearly disagree with that. It took me some time to understand whether there is a significant difference between bombing someone directly or via a CN. I must admit I'm still not 100% convinced that there is a significant difference. But I'm not as sure as you are that it is irrelevant. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 3 23:25: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 XAA05442 for ; Sun, 3 Mar 2002 23:25: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 VAA10067; Sun, 3 Mar 2002 21:25: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 UAA02224; Sun, 3 Mar 2002 20:25: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 g244O4KL020949 for ; Sun, 3 Mar 2002 20:24:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g244O4oi020948 for mobile-ip-dist; Sun, 3 Mar 2002 20: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 g244O1KL020941 for ; Sun, 3 Mar 2002 20:24:01 -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 UAA02106 for ; Sun, 3 Mar 2002 20:24:02 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA27210 for ; Sun, 3 Mar 2002 21:24:02 -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 g244O0Zc014765 for ; Mon, 4 Mar 2002 05:24:00 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 05:24:00 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 05:24:00 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA5B@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, 4 Mar 2002 05:21:19 +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: > => this is explicitely suggested in my IPv6 payload header I-Ds > and the first one was announced in the ROHC list (do you think > I should announce the new version again in the ROHC list?) => The main advantage of multi-payload over piggybacking is that it avoids the IPsec issues. But it doesn't address any of the QoS problems. My earlier note was misunderstood and assumed to be only relevant to certain link layers. Whereas it is relevant for any link along the way. David Oran has clearly explained this. > PS: for me ROHC is the only place at the IETF where this > can be done, > link-layers are not in our scope... => It's _not_ just a link layer issue. If you piggyback a BU (that requires higher priority forwarding by intermediate routers) over your web traffic (low priority), how can we (magically?) set the TOS field?? Not all systems assume e2e QoS signalling (none is deployed today), and even if e2e signalling was to be deployed, I don't know if there is an e2e protocol that says 'do not piggyback the BU' to a CN. I'm probably answering your email and a few earlier ones in one email :). I know you agree with some of these points. Hesham PS: Sorry if I don't reply quickly, I'm not reading email everyday this week. > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 02:57: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 CAA16689 for ; Mon, 4 Mar 2002 02:57: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 AAA28278; Mon, 4 Mar 2002 00:57: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 XAA08913; Sun, 3 Mar 2002 23:57: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 g247uNKL021210 for ; Sun, 3 Mar 2002 23:56:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g247uNnb021209 for mobile-ip-dist; Sun, 3 Mar 2002 23:56: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 g247uKKL021202 for ; Sun, 3 Mar 2002 23:56: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 XAA08845 for ; Sun, 3 Mar 2002 23:56:18 -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 XAA18209 for ; Sun, 3 Mar 2002 23:56:17 -0800 (PST) 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 g247u1B04481; Mon, 4 Mar 2002 08:56:01 +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 g247u0of006121; Mon, 4 Mar 2002 09:56:00 +0200 (EET) Message-ID: <3C832890.7A188DC2@lmf.ericsson.se> Date: Mon, 04 Mar 2002 09:56:00 +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: vijayd@iprg.nokia.com CC: mobile-ip@sunroof.eng.sun.com, Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> <3C7FD59D.1BD7916B@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 wrote: > Returning a value by role changes some assumptions and may not > work so well. Mobility header can't be always transport because > you would not reach the actual transport in case you piggyback. > Defining it as unknown does kind of work but would have the > same problem from the exact transport search: you bail out > with the unknown value too early and do not see the actual > transport when you do piggyback. Yes, but defining the header as unknown would work for the case where piggybacking is not used by the peers. It is only the piggybacking case that needs special treatment. Given that we have been assuming that the sender is responsible for figuring out that there are no IPsec policies related to the payload or the BU, this would seem to indicate that we don't have a problem at all. That is, policy(MH) == pass AND policy(payload) == PASS IMPLIES policy(MH+paylod) == pass. Now, if MH is unknown as far as RFC 2401 is concerned, this means that IPsec will treat the MH+payload packet is it would have treated the MH alone. But since the action in both cases is pass, this does not seem to have an impact. Of course, in order to do the above, an implementation that wants to use piggybacking needs to have an API between MIPv6 and IPsec in order to figure out if the policy lookups really return pass. Conclusion (at this stage, without reading the rest of the thread yet): separate MH header, unknown treatment from RFC 2401, and optional piggybacking support would seem to solve the issue. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 03:12:37 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 DAA16912 for ; Mon, 4 Mar 2002 03:12: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 BAA02432; Mon, 4 Mar 2002 01:12: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 AAA10606; Mon, 4 Mar 2002 00: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 g248BWKL021297 for ; Mon, 4 Mar 2002 00:11:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g248BWIm021296 for mobile-ip-dist; Mon, 4 Mar 2002 00:11: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 g248BTKL021289 for ; Mon, 4 Mar 2002 00:11:29 -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 AAA25854 for ; Mon, 4 Mar 2002 00:11:29 -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 BAA02149 for ; Mon, 4 Mar 2002 01:11:28 -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 g248BBB15447; Mon, 4 Mar 2002 09:11:11 +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 g248BAof007202; Mon, 4 Mar 2002 10:11:10 +0200 (EET) Message-ID: <3C832C1E.244A94AD@lmf.ericsson.se> Date: Mon, 04 Mar 2002 10:11:10 +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: Francis.Dupont@enst-bretagne.fr CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203021257.g22Cvtg97142@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 Dupont wrote: > => basically what is needed is multi-protocol policy selector, > something which is hard to specified, hard to implement, likely > very inefficient and a nightmare to configure... I don't think this is the intention from anyone. I thought most people had the opinion that we should NOT extend IPsec or specify a complicated mechanism to cover both BUs and payloads. HOWEVER, what is being debated now is whether we could still use piggybacking in *some* cases (and define it as optional so not everyone has to implement it if they don't want to, and do it in a separate RFC so the little details that have be done right don't delay the main MIPv6 RFC). The basic approach is checking from MIPv6 code that there are no "troublesome" policies, and proceeding with piggybacking only if there aren't. (Francis, could you take a look at my previous e-mail to the list and comment whether the analysis is right? I know you have a lot of experience on this particular issue so I'd appreciate your comments on it.) Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 03:16:12 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 DAA16969 for ; Mon, 4 Mar 2002 03:16:11 -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 BAA04333; Mon, 4 Mar 2002 01:16: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 AAA11006; Mon, 4 Mar 2002 00: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 g248EcKL021341 for ; Mon, 4 Mar 2002 00:14:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g248EcsS021340 for mobile-ip-dist; Mon, 4 Mar 2002 00: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248EZKL021333 for ; Mon, 4 Mar 2002 00:14: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 AAA26369 for ; Mon, 4 Mar 2002 00:14:35 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23714 for ; Mon, 4 Mar 2002 00:14:34 -0800 (PST) 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 g248ETZc013358; Mon, 4 Mar 2002 09:14:30 +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 g248ETof007467; Mon, 4 Mar 2002 10:14:29 +0200 (EET) Message-ID: <3C832CE5.8C017CCA@lmf.ericsson.se> Date: Mon, 04 Mar 2002 10:14:29 +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: vijayd@iprg.nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> <3C7FD59D.1BD7916B@iprg.nokia.com> <200203012000.WAA01350@burp.tkv.asdf.org> <3C816324.6070605@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 > IPSec policy for IPSec policy > Mobility header for Payload Can piggyback > 1. no no yes > 2. no yes yes > 3. yes no no > 4. yes yes no Isn't line 2 incorrect? If there's a policy for the payload, the the 'MH is unknown for RFC 2401' approach doesn't work anymore, and the packet would go unprotected. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 04:06: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 EAA17638 for ; Mon, 4 Mar 2002 04:06: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 BAA16732; Mon, 4 Mar 2002 01:06:32 -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 BAA16522; Mon, 4 Mar 2002 01:06: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 g2493lKL021568 for ; Mon, 4 Mar 2002 01:03:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2493lE1021567 for mobile-ip-dist; Mon, 4 Mar 2002 01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2493hKL021560 for ; Mon, 4 Mar 2002 01:03: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 BAA06602 for ; Mon, 4 Mar 2002 01:03:44 -0800 (PST) Received: from matell.enst-bretagne.fr (matell.enst-bretagne.fr [192.108.115.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23145 for ; Mon, 4 Mar 2002 02:03:37 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by matell.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2493Jv04632 for ; Mon, 4 Mar 2002 10:03:19 +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 KAA02360 for ; Mon, 4 Mar 2002 10:03:19 +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 g2493Ig03495 for ; Mon, 4 Mar 2002 10:03:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203040903.g2493Ig03495@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 Mon, 04 Mar 2002 05:10:36 +0100. <4DA6EA82906FD511BE2F00508BCF053802C6AA5A@Esealnt861.al.sw.ericsson.se> Date: Mon, 04 Mar 2002 10:03: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: In your previous mail you wrote: OK, so I'm not the only one who goes on holidays => holidays? What is this thing... (:-). and tries to catch up with old email :) => they are not so old because the IPsec issue is not solved. > 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. > > => I would not like to go backward in the Mobile IPv6 > security issue, > so do you accept an IPsec SA with the proper authorization is > enough to protect the BU, yes or no? (i.e. do you agree with > I-D 00-15 or not about the security constraints?) => I think it's enough to authorise the use of the HoAö if included inside the Certs. However, the issue was brought up by the DT and several drafts to highlight that there is a need to prove ownership of the CoA to avoid bombing attacks. => bombing attacks when all packets include the HoA in a RH type 2. I don't believe this is a serious threat! You clearly disagree with that. => YES! It took me some time to understand whether there is a significant difference between bombing someone directly or via a CN. => there is a clear difference: directly you should use forged source addresses and go through ingress filtering, via a CN *with RO* you only expect the target doesn't notice the RH in each packet (:-). I must admit I'm still not 100% convinced that there is a significant difference. But I'm not as sure as you are that it is irrelevant. => do you agree with my argument? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 04:20: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 EAA17796 for ; Mon, 4 Mar 2002 04:20:34 -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 CAA15556; Mon, 4 Mar 2002 02:20: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 BAA07336; Mon, 4 Mar 2002 01:20: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 g249JEKL021647 for ; Mon, 4 Mar 2002 01:19:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249JEd6021646 for mobile-ip-dist; Mon, 4 Mar 2002 01:19: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 g249JBKL021639 for ; Mon, 4 Mar 2002 01:19:11 -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 BAA08626 for ; Mon, 4 Mar 2002 01:19:12 -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 BAA18701 for ; Mon, 4 Mar 2002 01:18:53 -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 g249HQk12987; Mon, 4 Mar 2002 10:17: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 KAA02674; Mon, 4 Mar 2002 10:17: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 g249HQg03595; Mon, 4 Mar 2002 10:17:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203040917.g249HQg03595@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) In-reply-to: Your message of Mon, 04 Mar 2002 09:56:00 +0200. <3C832890.7A188DC2@lmf.ericsson.se> Date: Mon, 04 Mar 2002 10:17: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: Of course, in order to do the above, an implementation that wants to use piggybacking needs to have an API between MIPv6 and IPsec in order to figure out if the policy lookups really return pass. => don't forget this API can not be assumed to exist. Conclusion (at this stage, without reading the rest of the thread yet): separate MH header, unknown treatment from RFC 2401, and optional piggybacking support would seem to solve the issue. => I believe you haven't measured the consequences: - IPsec support is mandatory for all compliant IPv6 implementations - the API is not available or not used in many implementations - so stupid but immediate solution is to disable piggy-backing support on every Mobile IPv6 implementations on platforms which support IPsec, i.e. on at least all compliant platforms. In fact you give the choice to piggy-backing supporters between to disable piggy-backing and/or to wait for the API. I am not a piggy-backing supporter but this is so unfair that I shan't follow you on this path. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 04:38: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 EAA17987 for ; Mon, 4 Mar 2002 04:38:38 -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 CAA06490; Mon, 4 Mar 2002 02:38:38 -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 BAA10102; Mon, 4 Mar 2002 01: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 g249bfKL021742 for ; Mon, 4 Mar 2002 01:37:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249bf28021741 for mobile-ip-dist; Mon, 4 Mar 2002 01:37: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 g249bbKL021734 for ; Mon, 4 Mar 2002 01:37:37 -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 BAA02696 for ; Mon, 4 Mar 2002 01:37:38 -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 CAA06126 for ; Mon, 4 Mar 2002 02:37: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 g249Y9k15229; Mon, 4 Mar 2002 10:34: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 KAA03064; Mon, 4 Mar 2002 10:34:09 +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 g249Y9g03667; Mon, 4 Mar 2002 10:34:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203040934.g249Y9g03667@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) In-reply-to: Your message of Mon, 04 Mar 2002 10:11:10 +0200. <3C832C1E.244A94AD@lmf.ericsson.se> Date: Mon, 04 Mar 2002 10:34: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: Francis Dupont wrote: > => basically what is needed is multi-protocol policy selector, > something which is hard to specified, hard to implement, likely > very inefficient and a nightmare to configure... I don't think this is the intention from anyone. I thought most people had the opinion that we should NOT extend IPsec or specify a complicated mechanism to cover both BUs and payloads. => so we agree that for IPsec a terminal (aka final) "protocol" is required. HOWEVER, what is being debated now is whether we could still use piggybacking in *some* cases (and define it as optional so not everyone has to implement it if they don't want to, and do it in a separate RFC so the little details that have be done right don't delay the main MIPv6 RFC). The basic approach is checking from MIPv6 code that there are no "troublesome" policies, and proceeding with piggybacking only if there aren't. => I have personally no objection to make piggy-backing unfeasible but we know we'll never reach a consensus this way. (Francis, could you take a look at my previous e-mail to the list and comment whether the analysis is right? I know you have a lot of experience on this particular issue so I'd appreciate your comments on it.) => I believe I have an idea which can be accepted by IPsec and piggy-backing folks... Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 04: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 EAA18021 for ; Mon, 4 Mar 2002 04:40:23 -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 CAA07252; Mon, 4 Mar 2002 02:40:23 -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 BAA10568; Mon, 4 Mar 2002 01:40: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 g249dhKL021795 for ; Mon, 4 Mar 2002 01:39:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249dh0Z021794 for mobile-ip-dist; Mon, 4 Mar 2002 01:39: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 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 g249ddKL021787 for ; Mon, 4 Mar 2002 01:39:40 -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 g249dZx11208; Mon, 4 Mar 2002 10:39:35 +0100 (MET) Date: Mon, 4 Mar 2002 10:34:38 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options To: Pekka Nikander Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, rajeev@iprg.nokia.com In-Reply-To: "Your message with ID" <3C81D784.6020106@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: > > For security reasons I think the CN needs to tag conservatively i.e. it > > is fine if it tags when it isn't needed. > > Not so simple. As I argued in another message, *if* firewalls > drop tagged packets, tagging when not needed leads to nasty > denial-of-service attacks against stationary hosts. Yes, but failure to communicae is a security feature and not a security bug :-) From a strict security perspective conservative tagging is fine. Making things actually work requires more than just considering the security perspective. So I agree that you need to consider the claimed desire to have firewalls filter tagged packets, robustness in terms of the MN and CN getting out of synch on the unvHAO state, etc. Erik > Which brings forth an idea: would it be possible to use some > variant of the "one bit" method to signal that a host using > a given address *is* a stationary host, and unvHAOs should not > be accepted for that address at all? In any case, the bidding > down attack is most vicious against stationary hosts that do not > understand MIPv6 signalling at all. > > I know this idea has lots of problems, but maybe somebody could > use the idea to develop something really useful. > > --Pekka Nikander > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 05:10: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 FAA18573 for ; Mon, 4 Mar 2002 05:10: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 DAA19471; Mon, 4 Mar 2002 03:10: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 CAA16735; Mon, 4 Mar 2002 02: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 g24A9uKL022040 for ; Mon, 4 Mar 2002 02:09:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24A9pDL022039 for mobile-ip-dist; Mon, 4 Mar 2002 02:09: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 g24A9mKL022032 for ; Mon, 4 Mar 2002 02:09:48 -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 CAA21704 for ; Mon, 4 Mar 2002 02:09:49 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16551 for ; Mon, 4 Mar 2002 03:09:47 -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 g24A9gZc017718; Mon, 4 Mar 2002 11:09:42 +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 g24A9fof016035; Mon, 4 Mar 2002 12:09:41 +0200 (EET) Message-ID: <3C8347E5.9F842F92@lmf.ericsson.se> Date: Mon, 04 Mar 2002 12:09:41 +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: Francis Dupont CC: vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203040917.g249HQg03595@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 Dupont wrote: > => don't forget this API can not be assumed to exist. I have not forgotten this. That is precisely my point about the piggybacking thing being optional and preferably also in a separate document. So, those who *do* want to take cost can do so, but don't have to bother other folks. > - the API is not available or not used in many implementations So, zero your bit mask and don't worry about it... > - so stupid but immediate solution is to disable piggy-backing > support on every Mobile IPv6 implementations on platforms > which support IPsec, i.e. on at least all compliant platforms. > In fact you give the choice to piggy-backing supporters between to > disable piggy-backing and/or to wait for the API. I am not a > piggy-backing supporter but this is so unfair that I shan't follow you > on this path. Well, I'm really not a fan of piggybacking either but I'm trying to find a way for this WG to move ahead. It seems at least that we agree that the choices are: 1. No piggybacking. 2. Piggybacking in a special case, with an API (optional) (3. Modify IPsec is not an option) I think you favor option 1. I'm between options 1 and 2, but I have this feeling that the WG could close this issue and move forward if we picked 2. That does not seem to cost anything to folks who don't want piggyback. After this explanation, would you Francis be prepared to accept also option 2, or do you think we should try to find consensus for option 1? Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 05:15: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 FAA18623 for ; Mon, 4 Mar 2002 05:15:21 -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 DAA21372; Mon, 4 Mar 2002 03:15: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 CAA17615; Mon, 4 Mar 2002 02:15: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 g24AEVKL022126 for ; Mon, 4 Mar 2002 02:14:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24AEVhQ022125 for mobile-ip-dist; Mon, 4 Mar 2002 02:14: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 g24AESKL022118 for ; Mon, 4 Mar 2002 02:14:28 -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 CAA17436 for ; Mon, 4 Mar 2002 02:14:29 -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 DAA18344 for ; Mon, 4 Mar 2002 03:14:28 -0700 (MST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id 26A8FA; Mon, 4 Mar 2002 12:16:18 +0200 (EET) Message-ID: <3C8348BE.3060205@nomadiclab.com> Date: Mon, 04 Mar 2002 12:13:18 +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: mobile-ip@sunroof.eng.sun.com, rajeev@iprg.nokia.com Subject: Re: [mobile-ip] A new proposal for handling Home Address destination options 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, This is nit picking but... >>> For security reasons I think the CN needs to tag conservatively i.e. it >>> is fine if it tags when it isn't needed. >>> >> Not so simple. As I argued in another message, *if* firewalls >> drop tagged packets, tagging when not needed leads to nasty >> denial-of-service attacks against stationary hosts. > > Yes, but failure to communicae is a security feature and not a security bug :-) > From a strict security perspective conservative tagging is fine. ... the validity of the above statement depends on your definition of security. Some people, including me, tend to count availability of services also as belonging to "security", even though resiliance in the large goes beyound. Thus, if a mechanism creates potential availability problems, i.e. opens up new venues for denial-of-service, I would count it as a security problem. Thus, failure to communicate is not necessarily a security feature, it can also be a security bug. Especially, failure to convey legitimate communication should be considered as an availability bug, and therefore as a security bug. :-) :-) --Pekka From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 05:39:37 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 FAA18981 for ; Mon, 4 Mar 2002 05:39: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 DAA29340; Mon, 4 Mar 2002 03:39: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 CAA24634; Mon, 4 Mar 2002 02:39: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 g24AcgKL022310 for ; Mon, 4 Mar 2002 02:38:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Acfbb022309 for mobile-ip-dist; Mon, 4 Mar 2002 02:38: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 g24AccKL022302 for ; Mon, 4 Mar 2002 02:38: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 CAA21718 for ; Mon, 4 Mar 2002 02:38:40 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27942 for ; Mon, 4 Mar 2002 03:38:38 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA17330; Mon, 4 Mar 2002 12:38:32 +0200 Date: Mon, 4 Mar 2002 12:38:32 +0200 Message-Id: <200203041038.MAA17330@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: <3C832CE5.8C017CCA@lmf.ericsson.se> (message from Jari Arkko on Mon, 04 Mar 2002 10:14:29 +0200) Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> <3C7FD59D.1BD7916B@iprg.nokia.com> <200203012000.WAA01350@burp.tkv.asdf.org> <3C816324.6070605@iprg.nokia.com> <3C832CE5.8C017CCA@lmf.ericsson.se> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: Apparently alternatives are 1) no piggyback, a new TRANSPORT level protocol number for BU or, controversial (?) 2) back to original Mobile IPv6 draft as is, with clarification that accepting certain options (like BU) may be configured to require that packet was protected by IPSEC (similar to neigbour discovery). Accompanied with strong "SHOULD" for requiring that all communcations are protected with sufficient level IPSEC (whether BU is present/piggybacked or not). Neighbor discovery RFC 2461 seems to "get away" with such wording easily, its left up to policies whether IPSEC is used or not. (Of course, in mobile IP IPSEC is more important. Though, ND with a set of manual SA's would be nice for building "virtual private WLAN" :-) From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 05:41: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 FAA19017 for ; Mon, 4 Mar 2002 05:41:19 -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 DAA15373; Mon, 4 Mar 2002 03:41: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 CAA24896; Mon, 4 Mar 2002 02:41: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 g24AeVKL022354 for ; Mon, 4 Mar 2002 02:40:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24AeV1X022353 for mobile-ip-dist; Mon, 4 Mar 2002 02: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 g24AeSKL022346 for ; Mon, 4 Mar 2002 02:40: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 CAA21883 for ; Mon, 4 Mar 2002 02:40:30 -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 DAA29697 for ; Mon, 4 Mar 2002 03:40:29 -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 g24AeSB29384 for ; Mon, 4 Mar 2002 11:40:28 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 11:40:28 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 11:40:00 +0100 Message-ID: From: "Karen E Nielsen (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) Date: Mon, 4 Mar 2002 11:40:22 +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 Vijay > Jari Malinen and I had sent a writeup to the design team describing > when you can piggyback and when you cant, when you have IPSec > turned on. We concluded that piggybacking is possible only in two > cases out of four. Heres a table from the writeup > > Table 1. Piggybacking with IPsec > > IPSec policy for IPSec policy > Mobility header for Payload Can piggyback > 1. no no yes > 2. no yes yes > 3. yes no no > 4. yes yes no > > > From the table, the sender does not piggyback at all whenever the > mobility extension header has an IPSec policy. > > For handling the first two cases, there is no need for any change > to RFC 2401 or the existing IPSec implementations. Please let me > know if I am wrong. > > I do not think that the assumption that the sender is able to determine the presence of IPSec policies is valid: It can probably (by interacting with its IPSec module) determine the presence of IPSec policies on its own link, and it can perhaps also (by asking the peer) determine whether there are IPsec policies on the peers link - But what if some intermediate routers have IPSec policies anchored on the payload which the sender has no knowledge of (e.g. protected tunnels over insecure networks for certain kind of communications). Then the MH can result in these packets not being properly processed (since the IPSec selector will target the MH and not the payload) I would therefore say that even in 1., piggybacking in general is not possible. BR, Karen Egede Nielsen Ericsson Telebit From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 06: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 GAA19447 for ; Mon, 4 Mar 2002 06:10: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 DAA08030; Mon, 4 Mar 2002 03:10:28 -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 DAA27765; Mon, 4 Mar 2002 03:10: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 g24B9SKL022553 for ; Mon, 4 Mar 2002 03:09:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24B9S7F022552 for mobile-ip-dist; Mon, 4 Mar 2002 03: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 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 g24B9NKL022545 for ; Mon, 4 Mar 2002 03:09:24 -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 g24B9Kx22334; Mon, 4 Mar 2002 12:09:20 +0100 (MET) Date: Mon, 4 Mar 2002 12:02:20 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Design team note: Why the "one bit" is needed andwhy it is sufficient To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com, jmalinen@iprg.nokia.com, Pekka Nikander In-Reply-To: "Your message with ID" <00cd01c1c081$8cbee740$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: > 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. Jim, I suspect there are multiple types of policy where the service provider is in a better position to set the policy, as well as cases when a user should be able to override the policy. In general we don't have many IETF protocols to help with this - the only reasonably complete example I can think of is DHCP. But using a protocol (whether DHCP or something else) to control security relevant policy on the host has bootstrapping issues. In some cases this can also be done at subscription time i.e. signing up with a service provider might mean that the host gets suggested and/or mandatory policy settings (in the "dialer" software, or in the SIM card). So I think for security reasons we want the MN to be the entity stating the policy whether or not it has received that policy as a recommendation or a requirement from the service provider. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 06:29: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 GAA19748 for ; Mon, 4 Mar 2002 06:29:10 -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 EAA17343; Mon, 4 Mar 2002 04:29: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 DAA00284; Mon, 4 Mar 2002 03:29: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 g24BS4KL022668 for ; Mon, 4 Mar 2002 03:28:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24BS421022667 for mobile-ip-dist; Mon, 4 Mar 2002 03:28: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 g24BS0KL022660 for ; Mon, 4 Mar 2002 03:28:01 -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 DAA29149 for ; Mon, 4 Mar 2002 03:28:00 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17055 for ; Mon, 4 Mar 2002 04:27:59 -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 g24BRwZc008140 for ; Mon, 4 Mar 2002 12:27:58 +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 g24BRwof022137 for ; Mon, 4 Mar 2002 13:27:58 +0200 (EET) Message-ID: <3C835A3E.C15F76FE@lmf.ericsson.se> Date: Mon, 04 Mar 2002 13:27:58 +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 Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design teamrecommendation: New recommendation on piggybacking) 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 "Karen E Nielsen (TED)" wrote: > It can probably (by interacting with its IPSec module) > determine the presence of IPSec policies on its own link, > and it can perhaps also (by asking the peer) determine > whether there are IPsec policies on the peers link - But > what if some intermediate routers have IPSec policies > anchored on the payload which the sender has no knowledge > of (e.g. protected tunnels over insecure networks > for certain kind of communications). Then the MH can > result in these packets not being properly processed > (since the IPSec selector will target the MH and not > the payload) This is an excellent point, and a point that at least I have forgotten in this discussion. Unless someone sees a way around this, we have then only three alternatives, (1) give up piggybacking altogether, (2) allow piggybacking only in messages that never need to be protected specially by IPsec, or (3) change IPsec. Since changing IPsec particularly on possibly already existing nodes that appear between two MIPv6 hosts is probably out of the question we are left with alternatives 1 and 2. Alternative 2 is troublesome because there seems to be folks who want to use IPsec-only for BU protection; I'd be happy with saying that you'll have to run RR or CGA for every BU. Also, since the Home Agent needs to protect RR messages as they pass through it, making RR messages invisible to IPsec policies would mean running IPsec on all traffic between the HA and the MN. So it looks like what we are left with is alternative 1. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 08:47: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 IAA24261 for ; Mon, 4 Mar 2002 08:47:48 -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 GAA09202; Mon, 4 Mar 2002 06:47: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 FAA14872; Mon, 4 Mar 2002 05:47: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 g24DkgKL023061 for ; Mon, 4 Mar 2002 05:46:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Dkgue023060 for mobile-ip-dist; Mon, 4 Mar 2002 05:46: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 g24DkcKL023053 for ; Mon, 4 Mar 2002 05:46:38 -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 g24Dkax05095; Mon, 4 Mar 2002 14:46:36 +0100 (MET) Date: Mon, 4 Mar 2002 14:41:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Piggybacking - DT recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, mroe@microsoft.com In-Reply-To: "Your message with ID" <200203031642.g23Ggfg01432@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: Francis wrote: > I Wrote: > 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. > > => I agree but the end of section 3.4 stands: > > Ubiquitous deployment of the Secure DNS Extensions ([8]) should be > strongly encouraged to facilitate widespread deployment of IPsec > (including IKE) without address-based Identity types. > > So until we have a secured way to verify name-address mapping > (DNSSEC is the obvious candidate) I am reluctant to encourage > IKE phase one where the addresses can not be verified (this > should be allowed but with restriction, look at my I-D about > IPsec and Mobile IPv6 for the beginning of a discussion. > BTW this is an 100% IPsec topic). BTW: This is habout ow to *use* IPsec for MIPv6. When discussing how to use tools like hammers to build things like buildings it probably isn't useful to defer that to the "hammer" working group. I'm trying to work out an example of where an MN tries to use IKE to do a BU with a CN. It goes something like this: - MN kicks IKE to set up a SA to use for the BU Must the MN verify that it has a certificate with its HoA as subject(alt)name to do this? No, because then it would not be able to take advantage of the DNSSEC reference above. Thus an IPsec SA is always attempted. - MN/CN finishes with SA establishment If the subject(alt)name was the home address then the CN can conclude that BUs protected by the SA are authorized for that Home Address. If not the CN does a DNS lookup of the hostname in the certificate subject(alt)name. It must use DNSsec for this i.e. all signature chains must be verified (the way DNSsec normally does it). If (one of) the IP addresses returned from the DNS is the HoA then BUs protected by the SA are authorized for that HoA. If the subject(alt)names are only mbox names (such as erik.nordmark@eng.sun.com) then this will fail and the SA is not useful for authorizing BUs. Does the above make sense? The looup of a hostname (FQDN) with DNSsec validation is presumably more expensive than the extra roundtrip caused by using RR together with IPsec. And if RR is used together with IPsec you can also handle things for mbox certificates. > PS: do you know why RFC 2956 section 3.4 is explicitely about IPv4 > addresses (32-bit IP addresses)? Is there something I've missed? I don't recall the exact discussion but I think this is written the way it is because the workshop was looking at how to handle the IP layer issues and IPv6 wasn't taken as granted as the solution at that point in time. Thus folks were looking for places where identifying nodes using IPv4 address would cause problems. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 11:47: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 LAA01928 for ; Mon, 4 Mar 2002 11:47:56 -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 JAA24429; Mon, 4 Mar 2002 09:47: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 IAA08680; Mon, 4 Mar 2002 08:47: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 g24GkqKL023445 for ; Mon, 4 Mar 2002 08:46:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24GkquW023444 for mobile-ip-dist; Mon, 4 Mar 2002 08:46: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 g24GknKL023437 for ; Mon, 4 Mar 2002 08:46: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 IAA12168 for ; Mon, 4 Mar 2002 08:46:50 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10466 for ; Mon, 4 Mar 2002 09:46:49 -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 g24GkmZc012008 for ; Mon, 4 Mar 2002 17:46:48 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 17:46:27 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 17:36:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA65@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, 4 Mar 2002 17:39: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: > => bombing attacks when all packets include the HoA in a RH type 2. > I don't believe this is a serious threat! => The only major difference I see is the amplification aspect of the attack. I.e. start the TCP connection then forward it to the victim, and do some TCP sequence number guessing to keep the connection up. > It took me some time to understand > whether there is a significant difference > between bombing someone directly or via a CN. > > => there is a clear difference: directly you should use > forged source > addresses and go through ingress filtering, via a CN *with RO* you > only expect the target doesn't notice the RH in each packet (:-). => It doesn't matter if the target notices the RH or not. The point is you would not be able to prevent it. You will detect the attacker of course, but you won't prevent the attack. > I must admit I'm still not 100% convinced > that there is a significant difference. But > I'm not as sure as you are that it is irrelevant. > > => do you agree with my argument? > => As I said, I see the main difference being the amplification, but I also see a performance loss when always mandating RR for the CoA. Hence, the internal debate with myself :) The question is how secure we want RO to be given the performance loss. I can't answer it yet without looking into it in more detail. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 17:12:15 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 RAA26755 for ; Mon, 4 Mar 2002 17:12:15 -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 PAA06636; Mon, 4 Mar 2002 15:12: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 OAA05148; Mon, 4 Mar 2002 14:12: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 g24MB3KL025051 for ; Mon, 4 Mar 2002 14:11:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24MB33s025050 for mobile-ip-dist; Mon, 4 Mar 2002 14:11: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24MB0KL025043 for ; Mon, 4 Mar 2002 14:11: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 OAA04915 for ; Mon, 4 Mar 2002 14:11:00 -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 OAA24749 for ; Mon, 4 Mar 2002 14:11:00 -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 g24MD6x12409 for ; Mon, 4 Mar 2002 16:13:06 -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, 4 Mar 2002 16:10:56 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 16:09:22 -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: [mobile-ip] Draft Agenda for IETF53 Date: Mon, 4 Mar 2002 16:09:22 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A128E7@daebe007.NOE.Nokia.com> Thread-Topic: Draft Agenda for IETF53 Thread-Index: AcHDyT6dCoN2Vy+zEdaxpQAAhj/HZA== To: X-OriginalArrivalTime: 04 Mar 2002 22:09:22.0642 (UTC) FILETIME=[3D3E4B20:01C1C3C9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g24MB1KL025044 Sender: owner-mobile-ip@sunroof.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 (Draft Agenda) IP Routing for Wireless/Mobile Hosts WG (mobileip) Agenda for IETF53 TUESDAY, March 19, 2002 0900-1130 Morning Sessions ------------------------------------------------------------ 1. Agenda Bashing 10 Minutes Basavaraj Document status 2. Connectathon Update 5 Minutes Samita 3. Mobile IPv6 Discussion 60 Minutes Design Team 4. MIPv4/AAA Keys Open issues 10 Minutes Phil 5. LMM Requirements 15 Minutes Carl draft-ietf-mobileip-lmm-requirements-01.txt 6. NAT/NAPT Traversal 10 Minutes Henrik draft-ietf-mobileip-nat-traversal-00.txt 7. MIP/VPN Issues 10 Minutes Phil draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 17:36: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 RAA28297 for ; Mon, 4 Mar 2002 17:36:54 -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 PAA20576; Mon, 4 Mar 2002 15:36:53 -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 OAA06979; Mon, 4 Mar 2002 14:36: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 g24MZqKL025156 for ; Mon, 4 Mar 2002 14:35:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24MZphE025155 for mobile-ip-dist; Mon, 4 Mar 2002 14:35: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 g24MZmKL025148 for ; Mon, 4 Mar 2002 14:35:48 -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 OAA10395 for ; Mon, 4 Mar 2002 14:35:49 -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 OAA05219 for ; Mon, 4 Mar 2002 14:35:48 -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 g24Mbux14581 for ; Mon, 4 Mar 2002 16:37:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 4 Mar 2002 16:35:45 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 16:35:02 -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: [mobile-ip] Unverified HAO Processing - Recommendation note Date: Mon, 4 Mar 2002 16:35:01 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A128EE@daebe007.NOE.Nokia.com> Thread-Topic: HAO Processing - Recommendation note Thread-Index: AcHDzGByCoN2jC+zEdaxpQAAhj/HZA== To: X-OriginalArrivalTime: 04 Mar 2002 22:35:02.0134 (UTC) FILETIME=[D2DA2160:01C1C3CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g24MZnKL025149 Sender: owner-mobile-ip@sunroof.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 following writeup provides a recommendation for unverified HAO processing by CNs. In order to gauge consensus from the WG, we would like feedback from WG members by 5 PM Thursday of March 7th, 02. -Basavaraj -------------------------------------------------------------------------------------------------- Unverified HAO Processing Rajeev Koodli, Jari T. Malinen and Charles E. Perkins This note specifies the author'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 the recommendation whether they AGREE, CAN TOLERATE, or DISAGREE with them. In case of DISAGREE, please explain why. 1. INTRODUCTION =============== The IPv6 specification [1] requires that every IPv6 node process the Mobile IPv6 Home Address Option (HAO) [2]. In the recent analysis of Mobile IPv6, concerns were raised that such a processing without verifying if the sender actually owned the Home Address (HoA) could lead to certain security vulnerabilities [3]. As a consequence, the unverified use of HAO has not been recommended in the design team recommendation. In this document, we describe a mechanism that allows a CN to process unverified HAO as it is currently specified using some implementation extensions. There are two concerns regarding the unverified use of HAO. First, any node (attacker) may use a CN as a reflector to send packets to one or more victims without being traced, since the CN's response is sent to the HoA with the CN's IP address as the source IP address. This is the traceability problem. As a matter of comparison, if a such a DoS attack were to happen today, the source IP address in the unsolicited packet would be the (typically spoofed) IP address of the sender. Second, as a response to prevent such attacks, source ingress filtering is used to block certain packets. With HAO, such a mechanism cannot readily be used. The solution proposed here requires a CN to include the source IP address of the packet in a response message from the CN. This allows the owner of the HoA to determine, from the ``tag'' present in the packet, the true originator that caused the CN's response. It thus provides traceability. Furthermore, a firewall filter can be set up to scan for the tag (i.e, the IP address of the node causing the CN's response) and apply appropriate filtering rules. Thus, it allows blocking of undesirable packets. We use the following acronyms in this document. BC: Binding Cache BCE: Binding Cache Entry BR: Binding request BDT: Bidirectional Tunneling GN: A Generic IPv6 Node not using Mobile IPv6 HAO: Home Addess Option HoA: Home Address 2. SOLUTION OVERVIEW ==================== The basic protocol is described by the following; 1. Packets arriving with HAO initiate tagging by creating an entry in the unverified Binding Cache (BC) that the CN maintains. As a data structure, the unverified BC contains HoA and CoA (i.e., the sender's IP address). If an entry cannot be created, e.g., due to finite storage, then the CN sends a Binding Request (BR) indicating that the MN should use either RO or Bidirectional Tunneling (BDT). 2. Packets arriving at the CN's address without HAO but with HoA as source IP address remove an existing entry. Care must be taken not to remove an entry when the MN reverse tunnels certain (e.g., multicast) packets. For this, the following rule would apply. if (srcIPaddr == HoA) if (dstIPaddr != CN's IP addr) do not remove tag from unverified BCE 3. If packets arrive with erroneous tags, a Home Agent drops those packets. It may optionally send an ICMP destination unreachable message in which it includes the correct tag (i.e., the correct CoA from its BC) that updates the unverified BCE. Meanwhile, any packet from the genuine MN with an HAO would also correct the CN's entry. On the other hand, the HA tunnels packets with correct tags to the MN. 3. UNVERIFIED HAO OPERATION =========================== When it receives a packet with HAO, if there is no entry in its Binding Cache (BC), the CN inserts the source IP address (CoA) in a small cache called unverified BC. When a packet needs to be sent to HoA, the CN tags the packet with this CoA. This is the basic idea. There are multiple ways in which the unverified BC can be implemented. Indeed, it can be part of the normal Mobile IPv6 BC with an appropriate attribute indicating that the tagged entry is unverified. So, when the CN scans the BC, it would know exactly which entry to tag and which one not to tag. It has also been suggested in the mailing list that the unverified BC could be implemented as an extension in a node's destination cache. The operation when the CN is communicating with a MN is already described by the above rules. So, we consider the scenario involving a Generic IPv6 Node (GN). Consider the case where an attacker binds any GN's address to a bogus or genuine CoA. a) When there is no on-going traffic between the CN and the GN; - the CN may send packets to the GN with a tag without the GN expecting them. The GN's response (TCP Ack, RTCP, etc) would wipe out the tag. - the GN itself may initiate a session to the CN, in which case, there is no tagging in the CN's response. - if the GN's site is configured to filter packets containing the tag, those packets will be dropped. Since the unverified BCE needs refreshing, the entry will expire unless the attacker keeps updating the entry. In any case, This is similar to receiving unsolicited packets in today's Internet. The presence of the tag however, allows traceability. b) If there is on-going traffic, the CN would start tagging packets sometime during the session. - if tagged packets reach the GN, there is no harm other than the tag overhead itself; the GN may simply ignore the tag and process the rest of the packet. Any packet transmission from GN to CN will force the CN not to tag. - if an entity such as a firewall discards packets with the tag, then the traffic from CN to GN would be ``disrupted''. However, the tag disappears when the CN receives a packet from GN (without HAO) or if the lifetime of the tag expires whichever is earlier. Only when the GN is a ``one-way listener'', and the firewall is configured to discard such packets, is there a possibility to disrupt the traffic up to a maximum of the lifetime of the unverified BCE. For this reason, we suggest a relatively short lifetime. 4. CN IMPLEMENTATION ==================== What follows is one possible way to implement the protocol on the CN. There are others. The CN state machine has two states. In the ``tagging'' state, there is a tag present for the destination address (HoA) in the unverified BC and hence the CN tags outgoing packets to that address. In the ``no-tagging'' state, there is no tag present for the HoA, and hence the CN does not tag the outgoing packets to that address. Note that if there is no entry corresponding to the destination address, there is no Mobile IPv6 specific action required. The CN state machine can be descibed by the following diagram. T1 and T2 are two different timers, initially set to zero. ------ (until T2 expires) | | | V ---------- T2 expires | no |----------+ |tagging | | | | V ---------- --------- packet with ^ | | srcIPaddr=HoA | +---------| start | | |HAO pkt | | | V --------- ---------- ^ | | | |tagging |-----------+ | | T1 expires ---------- ^ | | | ------ (until T1 expires) 1. The CN begins in the ``start'' state. If it receives a packet with HAO, it moves to tagging state. If it does not, there is no special action required. It moves back to ``start'' state from ``(no)tagging'' state if timer (T2)T1 expires. 2. When in tagging state if it receives a packet without HAO but with HoA as the source IP address, and CN's address as the destination address, the CN transitions to no-tagging state. However, if the destination address in the received packet is not the CN's address (a multicast address for example), then it remains in the tagging state. When it makes a transition from tagging to no-tagging state, it remains in that state until a randomized ``standby'' timer (T2) expires. 3. When in no-tagging state, the packets without HAO are processed normally. Those with HAO are silently discarded. When timer T2 expires, the CN moves to start state where it will start accepting packets with HAO. The net effect of this behavior is that when there is an attempt to introduce a tag maliciously, there is quick repair and longer timeout before the tag can appear again; on the other hand, if a MN moves away from home and starts using HAO, those packets would be tagged rightfully. The special case when the MN uses HAO for some packets but reverse tunnels others is handled by the rule specified in Section 2. The entries in the unverified BC may be subject to garbage collection. When doing so, removing the active entries is not recommended. In particular, if the CN is in no-tagging state with T2 being non-zero, removing such an entry would mean that the CN transitions to start state where it would accept HAO packets (as opposed to disallowing HAO packets until T2 expires). The typical values for both T1 and T2 are in seconds. The values for T1 and T2 should be chosen based on the following guidelines. Note that if an attacker introduces a spurious tag in the on-going communication between the CN and the GN, then those tagged packets may be dropped by a firewall. While the CN transitions immediately back to no-tagging state upon receiving a packet without HAO from GN, in order to reduce the number of potential packet losses in case the GN does not send packets (while packets are being dropped by its firewall) to CN, the value chosen for T1 should be short, perhaps of the order of few seconds. At the same time, the value chosen for T1 should be sufficiently larger than the inter-packet times so that the CN resides in tagging state long enough for a genuine MN. We recommend using 4 seconds for T1. On the other hand, the value chosen for T2 should disallow introducing a spurios tag by an attacker. Thus, this value should be relatively larger, perhaps of the order of 10's of seconds. Note that a MN should not force a CN to enter no-tagging state unless it is returning home. The reverse tunneled packets do not make the CN enter no-tagging state. The state machine is summarized in the following table. State Event -> New state Action start non-HAO -> no state change - start HAO pkt -> tag, start T1 tag HAO pkt -> no state change, update T1 tag T1 expires -> start, - tag non-HAO -> no-tag, start T2, reset T1 no-tag HAO -> no-tag, drop packet no-tag T2 expires -> start, - no-tag non-HAO -> no state change, - 5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING ================================================= A MN may wish to simultaneously use, for whatever reasons, both HAO and reverse tunneling. If a MN needs to use reverse tunneling while it is using HAO, it should use HAO on those packets that it reverse tunnels. Not doing so _could_ make some of its HAO packets to be dropped, i.e., those HAO packets that arrive when the CN is in no-tagging state. The exact number of packets that might be dropped depends on, among other things, the holding time in no-tagging state, and the likelihood of MN generating packets with HAO while the CN is in no-tagging state. 5. RECOMMENDATION ================== It appears that with the proposed mechanism, the concerns raised regarding the unverified HAO processing can be effectively addressed. While the proposed mechanism may not be perfect, it offers disincentives for an attacker to do harm and provides sufficient correcting ability for a genuine node so that any potential disruption can be quickly repaired. Recommendation R1 : We recommend that unverified HAO processing be done according to the rules specified in Section 2. ACKNOWLEDGMENTS The table for CN state machine is a result of a thorough review from Erik Nordmark. REFERENCES [1] S. Deering and R. Hinden, ``Internet Protocol, Version 6 (IPv6) Specification'', RFC 2460. [2] D. Johnson and C. E. Perkins, ``Mobility Support in IPv6'' draft-ietf-mobileip-ipv6-15.txt, work in progress [3] Mobile IPv6 Design Team, ``Home Address Option: design team recommendation'', Mobile IP mailing list, February 12, 2002. From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 18:40: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 SAA00069 for ; Mon, 4 Mar 2002 18:40:15 -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 QAA19250; Mon, 4 Mar 2002 16:40: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 PAA17776; Mon, 4 Mar 2002 15:40: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 g24NcpKL025305 for ; Mon, 4 Mar 2002 15:38:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24NcpbM025304 for mobile-ip-dist; Mon, 4 Mar 2002 15:38: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 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 g24NclKL025297 for ; Mon, 4 Mar 2002 15:38:47 -0800 (PST) Received: from lillen (vpn-129-156-96-29.EMEA.Sun.COM [129.156.96.29]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g24Ncix05545; Tue, 5 Mar 2002 00:38:44 +0100 (MET) Date: Tue, 5 Mar 2002 00:33:45 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <697DAA22C5004B4596E033803A7CEF44A128EE@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: Rajeev, > 3. If packets arrive with erroneous tags, a Home Agent drops those > packets. It may optionally send an ICMP destination unreachable > message in which it includes the correct tag (i.e., the correct CoA > from its BC) that updates the unverified BCE. Meanwhile, any packet > from the genuine MN with an HAO would also correct the CN's > entry. On the other hand, the HA tunnels packets with correct tags > to the MN. I don't understand what problem this part is solving. It seems to mandate that Home Agents (a kind of routers) inspect the content of the packets they forward into a tunnel to a MN, which isn't good for performance. The ICMP error to "correct" the tag seems a bit odd, since the reason the tag has a particular value might be because an attacker is sending packets with a HAO but with a different CoA ( = IP source address) than the MN is using so I think you want to keep that "bad" tag and not "correct" it. > Only when the GN is a ``one-way listener'', and the firewall > is configured to discard such packets, is there a possibility > to disrupt the traffic up to a maximum of the lifetime of the > unverified BCE. For this reason, we suggest a relatively short > lifetime. ISSUE: I think this is an understatement of the problem since this issue appears e.g. with normal TCP connections and not just one-way listeners. If the CN is sending TCP data segments and those do not reach the MN due to the tag and firewall, the the MN will not send any TCP ACK segments that will remove the tag. > 5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING > ================================================= > > A MN may wish to simultaneously use, for whatever reasons, both HAO > and reverse tunneling. If a MN needs to use reverse tunneling while it > is using HAO, it should use HAO on those packets that it reverse > tunnels. Not doing so _could_ make some of its HAO packets to be > dropped, i.e., those HAO packets that arrive when the CN is in > no-tagging state. The exact number of packets that might be dropped > depends on, among other things, the holding time in no-tagging state, > and the likelihood of MN generating packets with HAO while the CN is in > no-tagging state. When an MN does this I assume it will send packets using triagular routing with source = CoA, HAO = HoA and using reverse tunneling with source = HoA, HAO = HoA since the IP source address must be topologically correct. Did I understand this correctly? In that case what will the tags contain - the source address for the most recently received HAO packet? What about an attacker than injects a packet with source = X, HOA = HoA while the MN is using triangular routing. The writeup doesn't say for how long time the tag would contain X vs. the original CoA. If there is a significant rate of triagular packets from the real MN I think an attacker might be able to "hide" its packets depending on the details of how the tag value is replaced. So I think those rules need to be understood to analyze this further. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 19:08: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 TAA00897 for ; Mon, 4 Mar 2002 19:08: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 RAA10451; Mon, 4 Mar 2002 17:08: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 QAA23739; Mon, 4 Mar 2002 16:08: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 g24Nt3KL025437 for ; Mon, 4 Mar 2002 15:57:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24NsYbO025436 for mobile-ip-dist; Mon, 4 Mar 2002 15:54: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24Nq2KL025403 for ; Mon, 4 Mar 2002 15:53:32 -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 PAA04043 for ; Mon, 4 Mar 2002 15:49:43 -0800 (PST) Received: from jones.siteprotect.com (jones.siteprotect.com [64.41.120.37]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20517 for ; Mon, 4 Mar 2002 15:49:42 -0800 (PST) Received: from nkhanna (pcp01419506pcs.plmthm01.pa.comcast.net [68.81.157.200]) by jones.siteprotect.com (8.9.3/8.9.3) with SMTP id RAA01456 for ; Mon, 4 Mar 2002 17:49:41 -0600 From: "Nitin J. Khanna" To: Subject: [mobile-ip] New to the list Date: Mon, 4 Mar 2002 18:45:36 -0500 Message-ID: <000101c1c3d6$af5fe6c0$9865fea9@nkhanna> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C1C3AC.C689DEC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MS-TNEF-Correlator: 000000003AE2F53CD082D01193EF0080C7ED04BC44CE6100 In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A128EE@daebe007.NOE.Nokia.com> 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: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C1C3AC.C689DEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I have recently graduated with a BS degree in Comp Eng and am a new subscriber to this list. I am currently involved in implementing wireless (802.11b) networks. I would like to contribute to the mobile-ip community and in turn get a lot of valuable knowledge. Can someone please direct me such that I can come upto speed on the projects being discussed on this list and corresponding goals to be achieved. thanks, Nitin J. Khanna ------=_NextPart_000_0002_01C1C3AC.C689DEC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IiUXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAwAEABIALQAAAAEAIAEB A5AGALQGAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAQAAAATmV3IHRvIHRoZSBsaXN0AAIBcQABAAAAFgAAAAHBw9auQ9JKW7LOGUZL uzidAe5S3kUAAAIBHQwBAAAAGwAAAFNNVFA6TktIQU5OQUBXRUJFUkdJWkUuTkVUAAALAAEOAAAA AEAABg4ApvmY1sPBAQIBCg4BAAAAGAAAAAAAAAA64vU80ILQEZPvAIDH7QS8woAAAAMAFA4BAAAA CwAfDgEAAAACAQkQAQAAACQCAAAgAgAA3QIAAExaRnV2jX0sAwAKAHJjcGcxMjXiMgNDdGV4BUEB AwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIs ETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBIdGVsF7AsCqIKgQGRIIggSSAT4HZlIBgg QmMJ8HRseSAJwGFIZHVhDrBkIAPwdOBoIGEgQgXwAQAJwgYgC4ASIW1wIEVuSmcf8G4fkGFtH/Fu UQfRc3ViBPJiEoF0Sm8i8GgEACBsBAB09i4eASHBYwhwGCAewwuAfnYG8B5QH5AgwQdwC1Bl/weA AjALgCFgA/AYICXABBEAKDgwMi4xMWKSKSIBdHcFsGtzI8LZJ8B1bB+QI4BrHmAjAfcFoAIwIqF1 DrAi9B5gBGAyYgMQZS0FICkhbW26dQMAdB7wIYIgwXQIcD0DoGcUIB/xF7AFQG9mPCB2B0AfUAJg HmBrbnRvdyXAZCxQI8AdVEN1A5FzA3BlAiAeYCWxYfcUECBAJnFjBUAHgCJBE9B3IyEfYB4BYwOR KvEeYHXzBTAjEHNwCeAfkAIgKgP6cANgajAhBCAiwCYiL/D9BPB1BBAyZiNVIXMFoRggzzIwAiAv 8CFRZ28HQAQgvyMBIsAf8BPQCJAlIS4dVdsdYzDhbifwHUVOH8AgwUpKI8BLOKFuYR1UfQE6wB4A QhABAAAAQAAAADw2OTdEQUEyMkM1MDA0QjQ1OTZFMDMzODAzQTdDRUY0NEExMjhFRUBkYWViZTAw Ny5OT0UuTm9raWEuY29tPgADAAlZAQAAAAsAAoAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAA AwAEgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAqACCAGAAAAAADAAAAAAAAARgAAAABS hQAAJ2oBAB4AC4AIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALAAyACCAGAAAA AADAAAAAAAAARgAAAAAGhQAAAAAAAAMADYAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAW gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADABeACCAGAAAAAADAAAAAAAAARgAAAAARhQAA AAAAAAMAGYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgAogAggBgAAAAAAwAAAAAAAAEYA AAAANoUAAAEAAAABAAAAAAAAAB4AKYAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAA AAAeACqACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAAgH4DwEAAAAQAAAAOuL1 PNCC0BGT7wCAx+0EvAIB+g8BAAAAEAAAADri9TzQgtARk+8AgMftBLwCAfsPAQAAAIIAAAAAAAAA OKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3Vt ZW50cyBhbmQgU2V0dGluZ3NcQWRtaW5pc3RyYXRvclxNeSBEb2N1bWVudHNcTml0aW5cRW1haWxc b3V0bG9vay5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDAzQUUyRjUz Q0QwODJEMDExOTNFRjAwODBDN0VEMDRCQzQ0Q0U2MTAwAAAAAAMABhDok3vJAwAHEGMBAAADABAQ AAAAAAMAERAAAAAAHgAIEAEAAABlAAAASEVMTE8sSUhBVkVSRUNFTlRMWUdSQURVQVRFRFdJVEhB QlNERUdSRUVJTkNPTVBFTkdBTkRBTUFORVdTVUJTQ1JJQkVSVE9USElTTElTVElBTUNVUlJFTlRM WUlOVk9MVkVESQAAAABwdA== ------=_NextPart_000_0002_01C1C3AC.C689DEC0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 20: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 UAA03902 for ; Mon, 4 Mar 2002 20:56: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 SAA19229; Mon, 4 Mar 2002 18:55:59 -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 RAA19611; Mon, 4 Mar 2002 17:55: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 g251t1KL025720 for ; Mon, 4 Mar 2002 17:55:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g251t1u3025719 for mobile-ip-dist; Mon, 4 Mar 2002 17:55: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 g251swKL025712 for ; Mon, 4 Mar 2002 17:54:58 -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 RAA19177 for ; Mon, 4 Mar 2002 17:54:58 -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 SAA10307 for ; Mon, 4 Mar 2002 18:54:57 -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 RAA24685; Mon, 4 Mar 2002 17:54:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g251svY31723; Mon, 4 Mar 2002 17:54:57 -0800 X-mProtect:  Mon, 4 Mar 2002 17:54:57 -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 smtpdsbiIOT; Mon, 04 Mar 2002 17:54:54 PST Message-ID: <3C84256D.FE92CEF0@iprg.nokia.com> Date: Mon, 04 Mar 2002 17:54:54 -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] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 your comments. Erik Nordmark wrote: > Rajeev, > > > 3. If packets arrive with erroneous tags, a Home Agent drops those > > packets. It may optionally send an ICMP destination unreachable > > message in which it includes the correct tag (i.e., the correct CoA > > from its BC) that updates the unverified BCE. Meanwhile, any packet > > from the genuine MN with an HAO would also correct the CN's > > entry. On the other hand, the HA tunnels packets with correct tags > > to the MN. > > I don't understand what problem this part is solving. > It seems to mandate that Home Agents (a kind of routers) inspect the > content of the packets they forward into a tunnel to a MN, which isn't > good for performance. The MN is isolated from the receipt of packets with spurious tags. In this sense, the Home Agent offers filtering ability. On the other hand, the protocol still works fine without assistance from the Home Agent. > > The ICMP error to "correct" the tag seems a bit odd, since the reason > the tag has a particular value might be because an attacker is sending > packets with a HAO but with a different CoA ( = IP source address) > than the MN is using so I think you want to keep that "bad" tag and not > "correct" it. That's possible if a CN is able to tell the difference between an attacker, a MN and an HA. Since the ICMP error is sent by the HA, the CN could make use of the message to both keep the ``bad'' tag for diagnostics and correct the entry as well. > > > > Only when the GN is a ``one-way listener'', and the firewall > > is configured to discard such packets, is there a possibility > > to disrupt the traffic up to a maximum of the lifetime of the > > unverified BCE. For this reason, we suggest a relatively short > > lifetime. > > ISSUE: I think this is an understatement of the problem since this > issue appears e.g. with normal TCP connections and not just one-way listeners. > If the CN is sending TCP data segments and those do not reach the MN due > to the tag and firewall, the the MN will not send any TCP ACK segments > that will remove the tag. > There are two cases a) and b) considered in Section 3, of which a) addresses this aspect. When there is no on-going traffic between CN and GN, and if a CN tags packets, those packets _may_ get dropped depending on the firewall filter. However, since the timer for tagging state is shorter, no response from GN would make CN to revert to start state. > > > 5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING > > ================================================= > > > > A MN may wish to simultaneously use, for whatever reasons, both HAO > > and reverse tunneling. If a MN needs to use reverse tunneling while it > > is using HAO, it should use HAO on those packets that it reverse > > tunnels. Not doing so _could_ make some of its HAO packets to be > > dropped, i.e., those HAO packets that arrive when the CN is in > > no-tagging state. The exact number of packets that might be dropped > > depends on, among other things, the holding time in no-tagging state, > > and the likelihood of MN generating packets with HAO while the CN is in > > no-tagging state. > > When an MN does this I assume it will send packets using triagular routing > with > source = CoA, HAO = HoA > and using reverse tunneling with > source = HoA, HAO = HoA > since the IP source address must be topologically correct. > Did I understand this correctly? > Yes. > > In that case what will the tags contain - the source address for the > most recently received HAO packet? > If source = HoA and HAO = HoA, the CN neither updates the tag not does it remove the tag. This needs to be specified as such in the document. > > What about an attacker than injects a packet with > source = X, HOA = HoA > while the MN is using triangular routing. The writeup doesn't say > for how long time the tag would contain X vs. the original CoA. > Since the CN cannot distinguish between the attacker and the MN, it updates the tag right away. This is fairly obvious and thus I did not add any text on this..However, those packets still reach the Home Agent and the HA could correct the CN's entry. One thing that might be useful to consider is that instead of dropping the packet containing X as a tag, the HA may tunnel that packet also to the MN. So, the MN always receives packets from the CN. > If there is a significant rate of triagular packets from the real MN > I think an attacker might be able to "hide" its packets depending on > the details of how the tag value is replaced. An existing tag is updated right away if the CoA is different. So, an attacker's source address is seen in the next outgoing packet from the CN. Regards, -Rajeev > > So I think those rules need to be understood to analyze this further. > > Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 21:17: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 VAA04333 for ; Mon, 4 Mar 2002 21:17: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 SAA27451; Mon, 4 Mar 2002 18:17:43 -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 SAA19613; Mon, 4 Mar 2002 18: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 g252FKKL025871 for ; Mon, 4 Mar 2002 18:15:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g252FKIU025870 for mobile-ip-dist; Mon, 4 Mar 2002 18:15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g252FHKL025860 for ; Mon, 4 Mar 2002 18:15:17 -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 SAA26602 for ; Mon, 4 Mar 2002 18:15:17 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA16743 for ; Mon, 4 Mar 2002 19:15:16 -0700 (MST) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g252FFq16395 for ; Mon, 4 Mar 2002 18:15:16 -0800 (PST) Message-ID: <3C842A33.A5F2E78C@cs.ucsb.edu> Date: Mon, 04 Mar 2002 18:15:15 -0800 From: Robert Chalmers Organization: UCSB Computer Science X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Return Routability 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 Hopefully a quick question: In the past, there were a number of proposals for RR, e.g., bu-3way and bake/2. Since then, security analysis has shown that two sets of messages, 1a/b and 2a/b from the DT recommendation, should be involved. However, not much has been said about which technique would be most appropriate to extend with the extra messaging. Did the DT have a particular technique in mind? To be a bit more clear in what I'm after, is the WG leaning toward a) using cookies that are returned to the CN (a la bu-3way), or b) partial keys that are then used to authenticate the BU (a la bake/2). If the answer is option a, then I would imagine two separate cookies would be sent, one over each path, and that both would be included in the final BU. Is that correct? For option b, would the key generated by an initial run of RR be reusable for BU refreshes if the node does not move (I think that this is something Charlie wants). In general, I'd like to get an idea of what the messages will look like and exactly what information would need to be carried in each. thanx in advance, Bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 4 21:39: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 VAA05695 for ; Mon, 4 Mar 2002 21:39:48 -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 SAA00406; Mon, 4 Mar 2002 18:39:48 -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 SAA22778; Mon, 4 Mar 2002 18:39: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 g252cHKL026036 for ; Mon, 4 Mar 2002 18:38:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g252cH7d026035 for mobile-ip-dist; Mon, 4 Mar 2002 18:38: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 g252cEKL026028 for ; Mon, 4 Mar 2002 18:38:14 -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 SAA00166 for ; Mon, 4 Mar 2002 18:38:15 -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 SAA20826 for ; Mon, 4 Mar 2002 18:38:14 -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 SAA26734 for ; Mon, 4 Mar 2002 18:38:14 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g252cDe12985 for ; Mon, 4 Mar 2002 18:38:13 -0800 X-mProtect:  Mon, 4 Mar 2002 18:38:13 -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 smtpdG3qO1X; Mon, 04 Mar 2002 18:38:11 PST Message-ID: <3C842F94.969566E1@iprg.nokia.com> Date: Mon, 04 Mar 2002 18:38: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> 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 Bob! Robert Chalmers wrote: > Hopefully a quick question: > > In the past, there were a number of proposals for RR, e.g., bu-3way and > bake/2. Since then, security analysis has shown that two sets of > messages, 1a/b and 2a/b from the DT recommendation, should be involved. > However, not much has been said about which technique would be most > appropriate to extend with the extra messaging. Did the DT have a > particular technique in mind? > > To be a bit more clear in what I'm after, is the WG leaning toward a) > using cookies that are returned to the CN (a la bu-3way), or b) partial > keys that are then used to authenticate the BU (a la bake/2). If the > answer is option a, then I would imagine two separate cookies would be > sent, one over each path, and that both would be included in the final > BU. Is that correct? For option b, would the key generated by an > initial run of RR be reusable for BU refreshes if the node does not move > (I think that this is something Charlie wants). > Good question. Recently, there was some discussion on the related topic. While doing RR, if we can establish a shared secret at CN, then we can avoid, at least partially, the RR messages even when the MN moves. For instance, with a shared secret, the MN does't have to establish that it owns the Home Address (through the so-called HoA RR tests) until the secret lifetime expires. > > In general, I'd like to get an idea of what the messages will look like > and exactly what information would need to be carried in each. > I am also looking for the exact nature of the messages. The following are additional likely candidates in these messages - indication as to which particular Binding Authorization mechanism to be used. This is likely to be part of the BU itself - piggybacking indication Regards, -Rajeev > > thanx in advance, > Bob > > -- > /**************************************************************** > > Robert Chalmers > UCSB Computer Science Doctoral Candidate > Network and Multimedia Systems Lab (NMSL) > > "My heart is in the code, but my soul lies in the process" > > | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | > > *****************************************************************/ From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 02:31: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 CAA19877 for ; Tue, 5 Mar 2002 02:31: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 AAA11224; Tue, 5 Mar 2002 00:31:41 -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 XAA29048; Mon, 4 Mar 2002 23:31: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 g257UcKL026743 for ; Mon, 4 Mar 2002 23:30:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257UcuJ026742 for mobile-ip-dist; Mon, 4 Mar 2002 23:30: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 g257UXKL026728 for ; Mon, 4 Mar 2002 23:30: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 XAA28820 for ; Mon, 4 Mar 2002 23:30:32 -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 AAA23589 for ; Tue, 5 Mar 2002 00:30: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 XAA06676 for ; Mon, 4 Mar 2002 23:30:31 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g257UVW20982 for ; Mon, 4 Mar 2002 23:30:31 -0800 X-mProtect:  Mon, 4 Mar 2002 23:30:31 -0800 Nokia Silicon Valley Messaging Protection Received: from davpndhcp1744.americas.nokia.com (172.18.174.4, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3UC26Y; Mon, 04 Mar 2002 23:30:29 PST Message-ID: <3C8473F1.1030609@iprg.nokia.com> Date: Mon, 04 Mar 2002 23:29:53 -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] Mobility Extension Header (was ISSUE: Design team recommendation: New recommendation on piggybacking) References: <200203011101.g21B1Bg90134@givry.rennes.enst-bretagne.fr> <3C7FD59D.1BD7916B@iprg.nokia.com> <200203012000.WAA01350@burp.tkv.asdf.org> <3C816324.6070605@iprg.nokia.com> <3C832CE5.8C017CCA@lmf.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 That never occurred to me. (using MH is unknown for RFC 2401 approach). I dont think I want to use that method. Will get back to this later... Connectathon is going on. sorry..... Vijay Jari Arkko wrote: >> IPSec policy for IPSec policy >> Mobility header for Payload Can piggyback >> 1. no no yes >> 2. no yes yes >> 3. yes no no >> 4. yes yes no >> > > Isn't line 2 incorrect? If there's a policy for the > payload, the the 'MH is unknown for RFC 2401' approach > doesn't work anymore, and the packet would go unprotected. > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 03:23: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 DAA20922 for ; Tue, 5 Mar 2002 03:23: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 BAA28707; Tue, 5 Mar 2002 01: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 AAA14285; Tue, 5 Mar 2002 00:23: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 g258N2KL027077 for ; Tue, 5 Mar 2002 00:23:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g258N2E4027076 for mobile-ip-dist; Tue, 5 Mar 2002 00:23: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 g258MxKL027069 for ; Tue, 5 Mar 2002 00:22:59 -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 AAA14151 for ; Tue, 5 Mar 2002 00:22:59 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28378 for ; Tue, 5 Mar 2002 01:22:58 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g258MuX30494 for ; Tue, 5 Mar 2002 10:22:56 +0200 Date: Tue, 5 Mar 2002 10:22:56 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] CLARIFICATION Unverified HAO Processing - Recommendation note In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A128EE@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: Note: I haven't followed UnvHAO discussion at all, so there will probably be some misunderstandings. High level view: is this intended as a completele replacement of the current mechanism? If HAO is authenticated, would it be ok to pass it as before? Another high level view: this *seems* to make DoS more traceable [however, I'm not sure if significant enough numbers of vendors ever log the tag, and the only way to get it would be to capture the packet and decode it from hex]. However, this doesn't address the problem of being able to send e.g. reflected UDP exploits (sure, there's a tag there but does a script-kiddie care?). On Mon, 4 Mar 2002 Basavaraj.Patil@nokia.com wrote: > 2. SOLUTION OVERVIEW > ==================== > > The basic protocol is described by the following; > > 2. Packets arriving at the CN's address without HAO but with HoA as > source IP address remove an existing entry. Care must be taken not > to remove an entry when the MN reverse tunnels certain (e.g., > multicast) packets. For this, the following rule would apply. > > if (srcIPaddr == HoA) > if (dstIPaddr != CN's IP addr) > do not remove tag from unverified BCE Am I missing something blatantly obvious, but why wouldn't the simpler approach work?: if (dstIPaddr = CN's IP addr) if (srcIPaddr == HoA) remove tag I think this satisfies the rules above, *AND* more importantly, can be really implemented -- the proposed solution seems awfully intrusive to me (must add checks like that in the forwarding path, probably) -- it seems much better to check for destination first. > 3. If packets arrive with erroneous tags, a Home Agent drops those > packets. It may optionally send an ICMP destination unreachable > message in which it includes the correct tag (i.e., the correct CoA > from its BC) that updates the unverified BCE. Would Home Agent revealing mapping between Home Address and CoA be counter-productive: there might be reasons to keep this secret from the prying eyes? Did I miss something? > 3. UNVERIFIED HAO OPERATION > =========================== > > When it receives a packet with HAO, if there is no entry in > its Binding Cache (BC), the CN inserts the source IP address (CoA) in a > small cache called unverified BC. You make an assumption that there is a BC in every CN.. that may not necessarily be the case... [skip the actual implementation etc.] -- 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 Mar 5 06:21: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 GAA23710 for ; Tue, 5 Mar 2002 06:21: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 EAA07365; Tue, 5 Mar 2002 04:21: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 DAA25607; Tue, 5 Mar 2002 03: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 g25BKkKL027533 for ; Tue, 5 Mar 2002 03:20:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25BKkve027532 for mobile-ip-dist; Tue, 5 Mar 2002 03:20: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25BKfKL027525 for ; Tue, 5 Mar 2002 03:20:41 -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 DAA25404 for ; Tue, 5 Mar 2002 03:20:40 -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 EAA00841 for ; Tue, 5 Mar 2002 04:20:40 -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 GAA23519; Tue, 5 Mar 2002 06:20:36 -0500 (EST) Message-Id: <200203051120.GAA23519@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-roe-mobileip-updateauth-02.txt Date: Tue, 05 Mar 2002 06:20:36 -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 : Authentication of Mobile IPv6 Binding Updates and Acknowledgments Author(s) : M. Roe et al. Filename : draft-roe-mobileip-updateauth-02.txt Pages : 22 Date : 04-Mar-02 This memo describes three protocols that may be used for authenticating binding updates in mobile IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roe-mobileip-updateauth-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-roe-mobileip-updateauth-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-roe-mobileip-updateauth-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: <20020304140835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-roe-mobileip-updateauth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-roe-mobileip-updateauth-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304140835.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 06:22:46 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 GAA23863 for ; Tue, 5 Mar 2002 06: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 EAA11536; Tue, 5 Mar 2002 04:22: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 DAA25988; Tue, 5 Mar 2002 03:22: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 g25BLmKL027576 for ; Tue, 5 Mar 2002 03:21:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25BLmuw027575 for mobile-ip-dist; Tue, 5 Mar 2002 03: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25BLiKL027568 for ; Tue, 5 Mar 2002 03:21: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 DAA25057 for ; Tue, 5 Mar 2002 03:21:43 -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 EAA08153 for ; Tue, 5 Mar 2002 04:21:42 -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 GAA23683; Tue, 5 Mar 2002 06:21:40 -0500 (EST) Message-Id: <200203051121.GAA23683@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-aura-mipv6-bu-attacks-01.txt Date: Tue, 05 Mar 2002 06:21:40 -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 : MIPv6 BU Attacks and Defenses Author(s) : T. Aura, j. Arkko Filename : draft-aura-mipv6-bu-attacks-01.txt Pages : 27 Date : 04-Mar-02 This document overviews attacks against mobile and fixed IP nodes by exploiting features of the Mobile IPv6 Route Optimization. Many of the attacks can be prevented by authenticating the Mobile IPv6 Binding Updates (BU) but some cannot, some depend on the details of the BU protocol, and some denial-of-service attacks specifically take advantage of authentication mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aura-mipv6-bu-attacks-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-aura-mipv6-bu-attacks-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-aura-mipv6-bu-attacks-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: <20020304141115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aura-mipv6-bu-attacks-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-aura-mipv6-bu-attacks-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304141115.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 07:43:16 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 HAA26431 for ; Tue, 5 Mar 2002 07:43:15 -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 EAA20778; Tue, 5 Mar 2002 04:43: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 EAA12535; Tue, 5 Mar 2002 04: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 g25CgDKL027777 for ; Tue, 5 Mar 2002 04:42:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25CgDgA027776 for mobile-ip-dist; Tue, 5 Mar 2002 04:42: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 g25CgAKL027769 for ; Tue, 5 Mar 2002 04:42:10 -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 EAA04940 for ; Tue, 5 Mar 2002 04:42:09 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25564 for ; Tue, 5 Mar 2002 05:42:09 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA29950 for ; Tue, 5 Mar 2002 05:42:04 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA25013 for ; Tue, 5 Mar 2002 05:41:59 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g25CftO17614 for ; Tue, 5 Mar 2002 06:41:56 -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 D310F2EC83 for ; Tue, 5 Mar 2002 13:41:53 +0100 (CET) To: Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> From: Alexandru Petrescu Date: 05 Mar 2002 13:41:53 +0100 In-Reply-To: <3C842A33.A5F2E78C@cs.ucsb.edu> 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: Hi Robert, Robert Chalmers writes: > In the past, there were a number of proposals for RR, e.g., bu-3way and > bake/2. Since then, security analysis has shown that two sets of > messages, 1a/b and 2a/b from the DT recommendation, should be > involved. I can't seem to find the 1a/b... exchanges in the mails. Could you please post it here so we can discuss it easily. Also, might be useful to find a name for it: say "the generic RR exchange"? From what I remember, these exchanges have been posted mainly to show the complete scenarios that are possible to test the return routability, in order to see where piggybacking can be done, etc.. But I think it will take more time to find exactly what messages are necessary and what are redundant. For example, since the first message goes CN->HA->MN, it might be possible that a subsequent message MN->HA->CN might not need to go through the HA again. One way to do this is that HA inserts a token into the first message transitting through it. This mechanism would prevent other verifications, though. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 07:56: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 HAA26905 for ; Tue, 5 Mar 2002 07:56:05 -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 FAA00602; Tue, 5 Mar 2002 05:55: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 EAA14856; Tue, 5 Mar 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 g25Ct4KL027880 for ; Tue, 5 Mar 2002 04:55:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Ct4bM027879 for mobile-ip-dist; Tue, 5 Mar 2002 04:55: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 g25Ct1KL027872 for ; Tue, 5 Mar 2002 04:55: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 EAA06552 for ; Tue, 5 Mar 2002 04:55:00 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13609 for ; Tue, 5 Mar 2002 04:54:59 -0800 (PST) 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 g25CsvZc021309 for ; Tue, 5 Mar 2002 13:54:58 +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 g25Csuof017117 for ; Tue, 5 Mar 2002 14:54:56 +0200 (EET) Message-ID: <3C84C020.542A4E2C@lmf.ericsson.se> Date: Tue, 05 Mar 2002 14:54:56 +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 Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> 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 Alexandru wrote: > I can't seem to find the 1a/b... exchanges in the mails. See recommendation 4 in http://www.piuha.net/~jarkko/publications/mipv6/RRCGA_Mail.txt We are working on the specifics of the messages. Good names names for these would also be welcome, right now I have: Binding Request (BR) Return Routability HoA Request (RRHR) Return Routability CoA Request (RRCR) Return Routability HoA Answer (RRHA) Return Routability CoA Answer (RRCA) Binding Update (BU) Binding Acknowledgement (BA) But needless to say, I'm not very pleased with the above names... Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 08:47: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 IAA29197 for ; Tue, 5 Mar 2002 08:47: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 GAA22200; Tue, 5 Mar 2002 06:47: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 AAA26031; Tue, 5 Mar 2002 00:53: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 g258peKL027219 for ; Tue, 5 Mar 2002 00:51:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g258pesb027218 for mobile-ip-dist; Tue, 5 Mar 2002 00:51: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 g258pZKL027211 for ; Tue, 5 Mar 2002 00:51:36 -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 g258pTx01295; Tue, 5 Mar 2002 09:51:29 +0100 (MET) Date: Tue, 5 Mar 2002 09:46:31 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C84256D.FE92CEF0@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 ICMP error to "correct" the tag seems a bit odd, since the reason > > the tag has a particular value might be because an attacker is sending > > packets with a HAO but with a different CoA ( = IP source address) > > than the MN is using so I think you want to keep that "bad" tag and not > > "correct" it. > > That's possible if a CN is able to tell the difference > between an attacker, a MN and an HA. Since the ICMP error is sent by > the HA, the CN could make use of the message to both keep the > ``bad'' tag for diagnostics and correct the entry as well. My point is that the ICMP error to "correct" the tag will make it impossible to trace the attacker. Suppose the CN gets HOA packets from the MN (src = CoA) so that it is in tagging state. Then packets arrive with the right HoA but with src = X. This presumably (writeup isn't clear) causes the the CN to change the tag in the unvHAO entry so say "tag with X". Thus the HA or MN can tell that something is odd because of the tag not being the CoA. But if the HA "corrects" this so that the CN will tag with the CoA then you are effective allowing the attacker to circumvent ingress filtering and use the CoA as the source i.e. the victim MN can't tell that the reflected packets originated from X any more. So I don't think the CN can "correct" the entry since that would remove the traceability. > > ISSUE: I think this is an understatement of the problem since this > > issue appears e.g. with normal TCP connections and not just one-way listeners. > > If the CN is sending TCP data segments and those do not reach the MN due > > to the tag and firewall, the the MN will not send any TCP ACK segments > > that will remove the tag. > > > > There are two cases a) and b) considered in Section 3, of which a) addresses > this aspect. When there is no on-going traffic between CN and GN, and if a > CN tags packets, those packets _may_ get dropped depending on the firewall > filter. However, since the timer for tagging state is shorter, no response > from GN would make CN to revert to start state. I agree that the timers limit the time of any black holes. But my issue was with the description of the problem being limited to one-way listeners when the problem in fact applies to things like TCP uni-directional data transfer. > If source = HoA and HAO = HoA, the CN neither updates the tag > not does it remove the tag. This needs to be specified as such in > the document. OK - makes sense. > Since the CN cannot distinguish between the attacker and the MN, > it updates the tag right away. This is fairly obvious and thus I did not > add any text on this..However, those packets still reach > the Home Agent and the HA could correct the CN's entry. One > thing that might be useful to consider is that instead of dropping the packet > containing X as a tag, the HA may tunnel that packet also to the MN. So, the > MN always receives packets from the CN. See above why you can't have the HA correct the tag at the CN. It seems like the CN always need to take the most recent received HAO value (with the above exception for source = HoA and HAO = HoA) and use that to tag outgoing packets. But this would make it possible for an off-path attacker, which can send at least as many packets per second as the MN, to prevent any packets from making it in the reverse direction by sending packets with HAO and src=X - with high probability the tag entry would contain X and not the CoA. Am I missing something? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 12:07: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 MAA09514 for ; Tue, 5 Mar 2002 12:07: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 KAA11497; Tue, 5 Mar 2002 10:07: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 JAA18651; Tue, 5 Mar 2002 09:07: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 g25H6dKL028487 for ; Tue, 5 Mar 2002 09:06:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25H6cVP028486 for mobile-ip-dist; Tue, 5 Mar 2002 09: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25H6ZKL028479 for ; Tue, 5 Mar 2002 09:06:35 -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 JAA15878 for ; Tue, 5 Mar 2002 09:06:36 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10913 for ; Tue, 5 Mar 2002 10:06:35 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA08536 for ; Tue, 5 Mar 2002 10:06:10 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA23840 for ; Tue, 5 Mar 2002 10:06:09 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g25H65l30425; Tue, 5 Mar 2002 11:06: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 E66A62EC84; Tue, 5 Mar 2002 18:06:02 +0100 (CET) To: Cc: Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> From: Alexandru Petrescu Date: 05 Mar 2002 18:06:02 +0100 Message-ID: Lines: 40 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: Jari Arkko writes: > We are working on the specifics of the messages. Good names names > for these would also be welcome, right now I have: Good naming schemes are indeed difficult to find :-) Is this the intended name association?: Return Routability HoA Request (RRHR) 1a. MN(HoA)--->HA--->CN Return Routability CoA Request (RRCR) 1b. MN(CoA)--------->CN Return Routability HoA Answer (RRHA) 2a. CN-------->HA--->MN(HoA) Binding Request (BR) 2b. CN-------------->MN(CoA) Return Routability CoA Answer (RRCA) 3. MN(CoA)--------->CN I'm not sure but I can't figure out a better association. Please enlighten. I would propose: Reverse Binding Warning (RBW) 1a. MN(HoA)--->HA (RBW) HA--->CN Binding Warning (BW) 1b. MN(CoA)--------->CN Reverse Binding Request (RBR) 2a. CN-------->HA (RBR) HA--->MN(HoA) Binding Request (BR) 2b. CN-------------->MN(CoA) RR Binding Update (RR-BU) 3. MN(CoA)--------->CN BW is from BAKE. BU3WAY calls it Binding Update Request, in danger of being abbreviated to Binding Request. All 'reverse' messages transit the HA, instead of going directly, like in "reverse tunnelling". I separated the reverse messages in two, but I doubt naming them is of any use. > The design team recommends both CoA and HoA tests to be performed Which of the above messages are part of the CoA test and which are part of the HoA test? I'm asking because I'm trying to figure out what each of these tests protects. Thanks, Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 12:16: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 MAA10066 for ; Tue, 5 Mar 2002 12:16: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 KAA17119; Tue, 5 Mar 2002 10:16: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 JAA22830; Tue, 5 Mar 2002 09:16: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 g25HFuKL028622 for ; Tue, 5 Mar 2002 09:15:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HFuVZ028621 for mobile-ip-dist; Tue, 5 Mar 2002 09:15: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 g25HFqKL028614 for ; Tue, 5 Mar 2002 09:15:52 -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 JAA23730 for ; Tue, 5 Mar 2002 09:15:53 -0800 (PST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19319 for ; Tue, 5 Mar 2002 10:15:51 -0700 (MST) Received: from jariws1 ([62.248.148.147]) by fep06-app.kolumbus.fi with SMTP id <20020305171550.YQFM20539.fep06-app.kolumbus.fi@jariws1>; Tue, 5 Mar 2002 19:15:50 +0200 Message-ID: <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Alexandru Petrescu" Cc: References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> Subject: Re: [mobile-ip] Return Routability Date: Tue, 5 Mar 2002 19:16:06 +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 The association is RRHR = 1a, RRCR = 1b, RRHA = 2a, RRCA = 2b, and BU = 3. BR and BA are then as they have always been. RRHR and RRHA are part of the HoA test, RRCR and RRCA are part of the CoA test, and BU draws everything together. Basically, the -R messages are requests to start the tests, and don't contain any real information. The -A messages are the real tests, and the test ends with BU using data learned in the test messages. How about 1a = HoA Test Init (HTI) 1b = CoA Test Init (CTI) 2a = HoA Test (HT) 2b = CoA Test (CT) 3 = BU Jari ----- Original Message ----- From: "Alexandru Petrescu" To: Cc: Sent: 5. maaliskuuta 2002 19:06 Subject: Re: [mobile-ip] Return Routability > Jari Arkko writes: > > We are working on the specifics of the messages. Good names names > > for these would also be welcome, right now I have: > > Good naming schemes are indeed difficult to find :-) > > Is this the intended name association?: > > Return Routability HoA Request (RRHR) 1a. MN(HoA)--->HA--->CN > Return Routability CoA Request (RRCR) 1b. MN(CoA)--------->CN > Return Routability HoA Answer (RRHA) 2a. CN-------->HA--->MN(HoA) > Binding Request (BR) 2b. CN-------------->MN(CoA) > Return Routability CoA Answer (RRCA) 3. MN(CoA)--------->CN > > I'm not sure but I can't figure out a better association. Please > enlighten. I would propose: > > Reverse Binding Warning (RBW) 1a. MN(HoA)--->HA > (RBW) HA--->CN > Binding Warning (BW) 1b. MN(CoA)--------->CN > Reverse Binding Request (RBR) 2a. CN-------->HA > (RBR) HA--->MN(HoA) > Binding Request (BR) 2b. CN-------------->MN(CoA) > RR Binding Update (RR-BU) 3. MN(CoA)--------->CN > > BW is from BAKE. BU3WAY calls it Binding Update Request, in danger of > being abbreviated to Binding Request. All 'reverse' messages transit > the HA, instead of going directly, like in "reverse tunnelling". I > separated the reverse messages in two, but I doubt naming them is of > any use. > > > The design team recommends both CoA and HoA tests to be performed > > Which of the above messages are part of the CoA test and which are > part of the HoA test? I'm asking because I'm trying to figure out > what each of these tests protects. > > Thanks, > > Alex > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 13:18: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 NAA14040 for ; Tue, 5 Mar 2002 13:18: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 LAA23931; Tue, 5 Mar 2002 11:17:44 -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 KAA12952; Tue, 5 Mar 2002 10:17: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 g25IGPKL028990 for ; Tue, 5 Mar 2002 10:16:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IGOcT028989 for mobile-ip-dist; Tue, 5 Mar 2002 10:16: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 g25IGLKL028982 for ; Tue, 5 Mar 2002 10:16:21 -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 KAA12493 for ; Tue, 5 Mar 2002 10:16:22 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27013 for ; Tue, 5 Mar 2002 11:16:22 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA07964 for ; Tue, 5 Mar 2002 11:16:21 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA18586 for ; Tue, 5 Mar 2002 11:16:19 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g25IGEl12815; Tue, 5 Mar 2002 12:16:15 -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 092792EC84; Tue, 5 Mar 2002 19:16:13 +0100 (CET) To: "Jari Arkko" Cc: Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> From: Alexandru Petrescu Date: 05 Mar 2002 19:16:12 +0100 In-Reply-To: <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> Message-ID: Lines: 21 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: "Jari Arkko" writes: > 1a = HoA Test Init (HTI) 1a. MN(HoA)--->HA--->CN > 1b = CoA Test Init (CTI) 1b. MN(CoA)--------->CN > 2a = HoA Test (HT) 2a. CN-------->HA--->MN(HoA) > 2b = CoA Test (CT) 2b. CN-------------->MN(CoA) > 3 = BU 3. MN(CoA)--------->CN Aha, that makes sense thanks. Getting back to the recommendation: > 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). In order to avoid the same reflection problems, the inverse is also valid: a BU authorization request sent from the HoA should not be answered to the CoA. Right? Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 13:19:53 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 NAA14136 for ; Tue, 5 Mar 2002 13:19: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 LAA29076; Tue, 5 Mar 2002 11:19: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 KAA13815; Tue, 5 Mar 2002 10:19: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 g25IJ0KL029043 for ; Tue, 5 Mar 2002 10:19:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IJ0aS029042 for mobile-ip-dist; Tue, 5 Mar 2002 10:19: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 g25IIuKL029035 for ; Tue, 5 Mar 2002 10:18:56 -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 KAA15027 for ; Tue, 5 Mar 2002 10:18:57 -0800 (PST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23189 for ; Tue, 5 Mar 2002 10:18:56 -0800 (PST) Received: from jariws1 ([62.248.148.147]) by fep06-app.kolumbus.fi with SMTP id <20020305181854.YVQR20539.fep06-app.kolumbus.fi@jariws1>; Tue, 5 Mar 2002 20:18:54 +0200 Message-ID: <01c001c1c472$3f961200$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Alexandru Petrescu" Cc: References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> Subject: Re: [mobile-ip] Return Routability Date: Tue, 5 Mar 2002 20:19:11 +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 > In order to avoid the same reflection problems, the inverse is also > valid: a BU authorization request sent from the HoA should not be > answered to the CoA. Right? Right. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 13:27: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 NAA14928 for ; Tue, 5 Mar 2002 13:27:33 -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 LAA00372; Tue, 5 Mar 2002 11:27: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 KAA16190; Tue, 5 Mar 2002 10:27: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 g25IQVKL029180 for ; Tue, 5 Mar 2002 10:26:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IQVCS029179 for mobile-ip-dist; Tue, 5 Mar 2002 10: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 g25IQRKL029172 for ; Tue, 5 Mar 2002 10:26: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 KAA19941 for ; Tue, 5 Mar 2002 10:26: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 LAA29752 for ; Tue, 5 Mar 2002 11:26: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 KAA03860; Tue, 5 Mar 2002 10:26:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g25IQPQ26458; Tue, 5 Mar 2002 10:26:25 -0800 X-mProtect:  Tue, 5 Mar 2002 10:26: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 smtpdy9oEwe; Tue, 05 Mar 2002 10:26:22 PST Message-ID: <3C850DCF.5BB1A33E@iprg.nokia.com> Date: Tue, 05 Mar 2002 10:26: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] CLARIFICATION: Unverified HAO Processing - Recommendation note 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: > > > The ICMP error to "correct" the tag seems a bit odd, since the reason > > > the tag has a particular value might be because an attacker is sending > > > packets with a HAO but with a different CoA ( = IP source address) > > > than the MN is using so I think you want to keep that "bad" tag and not > > > "correct" it. > > > > That's possible if a CN is able to tell the difference > > between an attacker, a MN and an HA. Since the ICMP error is sent by > > the HA, the CN could make use of the message to both keep the > > ``bad'' tag for diagnostics and correct the entry as well. > > My point is that the ICMP error to "correct" the tag will make it impossible > to trace the attacker. > Suppose the CN gets HOA packets from the MN (src = CoA) > so that it is in tagging state. > Then packets arrive with the right HoA but with src = X. > This presumably (writeup isn't clear) causes the the CN to change the tag > in the unvHAO entry so say "tag with X". > Right. For the same HoA, if there is a new CoA, that could be because the MN moved. The CN updates the tag right away. > Thus the HA or MN can tell that something is odd because of the tag not > being the CoA. > Right. That's the idea. > But if the HA "corrects" this so that the CN will tag with the CoA > then you are effective allowing the attacker to circumvent ingress > filtering and use the CoA as the source i.e. the victim MN can't tell > that the reflected packets originated from X any more. > I meant when the CN receives the ICMP error, it can potentially log the existing tag entry and then correct it with what the HA sent. But, I agree with you that doing both has its overhead; extra storage for the bad tag. Also, from a protocol perspective, it is not necessary that the tag is a `good' one; of course I would like it be a good one :-) > > So I don't think the CN can "correct" the entry since that would remove > the traceability. > > > > ISSUE: I think this is an understatement of the problem since this > > > issue appears e.g. with normal TCP connections and not just one-way listeners. > > > If the CN is sending TCP data segments and those do not reach the MN due > > > to the tag and firewall, the the MN will not send any TCP ACK segments > > > that will remove the tag. > > > > > > > There are two cases a) and b) considered in Section 3, of which a) addresses > > this aspect. When there is no on-going traffic between CN and GN, and if a > > CN tags packets, those packets _may_ get dropped depending on the firewall > > filter. However, since the timer for tagging state is shorter, no response > > from GN would make CN to revert to start state. > > I agree that the timers limit the time of any black holes. > But my issue was with the description of the problem being limited > to one-way listeners when the problem in fact applies to things like > TCP uni-directional data transfer. > Ok. > > > If source = HoA and HAO = HoA, the CN neither updates the tag > > not does it remove the tag. This needs to be specified as such in > > the document. > > OK - makes sense. > > > Since the CN cannot distinguish between the attacker and the MN, > > it updates the tag right away. This is fairly obvious and thus I did not > > add any text on this..However, those packets still reach > > the Home Agent and the HA could correct the CN's entry. One > > thing that might be useful to consider is that instead of dropping the packet > > containing X as a tag, the HA may tunnel that packet also to the MN. So, the > > MN always receives packets from the CN. > > See above why you can't have the HA correct the tag at the CN. > > It seems like the CN always need to take the most recent received > HAO value (with the above exception for source = HoA and HAO = HoA) > and use that to tag outgoing packets. > > But this would make it possible for an off-path attacker, which can send at > least as many packets per second as the MN, to prevent any packets from > making it in the reverse direction by sending packets with HAO and src=X - > with high probability the tag entry would contain X and not the CoA. > Let's see what is the effect. - what is in the tag is less important compared to the presence of tag itself. So, packets should not be dropped because tag=X. Having said this, what is in the tag is important for diagnostics. - if the CN sends an unsolicited packet because the attacker initiated a response, that response would contain the tag. So, there is traceability - if the CN is responding to the MN's packets, but includes tag=X, what's the harm ? The MN (or the HA) can find out that someone is attempting to use the MN'a HoA. The packet as such is fine; in fact, it has important traceability information. So, an attacker cannot disrupt the flow to a MN. Hope this is useful.. Regards, -Rajeev > > Am I missing something? > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 13:31: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 NAA15494 for ; Tue, 5 Mar 2002 13:31:52 -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 KAA15368; Tue, 5 Mar 2002 10:31: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 KAA17619; Tue, 5 Mar 2002 10: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 g25IUtKL029262 for ; Tue, 5 Mar 2002 10:30:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IUt62029261 for mobile-ip-dist; Tue, 5 Mar 2002 10:30: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 g25IUpKL029254 for ; Tue, 5 Mar 2002 10:30: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 KAA18047 for ; Tue, 5 Mar 2002 10:30:51 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29134 for ; Tue, 5 Mar 2002 10:30:50 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA22686; Tue, 5 Mar 2002 11:30:47 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA05814; Tue, 5 Mar 2002 11:30:46 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g25IUfl07625; Tue, 5 Mar 2002 12:30:41 -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 C04902EC83; Tue, 5 Mar 2002 19:30:37 +0100 (CET) To: "Jari Arkko" Cc: Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> <01c001c1c472$3f961200$8a1b6e0a@arenanet.fi> From: Alexandru Petrescu Date: 05 Mar 2002 19:30:37 +0100 In-Reply-To: <01c001c1c472$3f961200$8a1b6e0a@arenanet.fi> 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: "Jari Arkko" writes: > > In order to avoid the same reflection problems, the inverse is > > also valid: a BU authorization request sent from the HoA should > > not be answered to the CoA. Right? > > Right. But in that case I can be at home and flood HTI's to CN that will flood the attacked MN with with CT's right? Alex > 1a = HoA Test Init (HTI) 1a. MN(HoA)--->HA--->CN > 1b = CoA Test Init (CTI) 1b. MN(CoA)--------->CN > 2a = HoA Test (HT) 2a. CN-------->HA--->MN(HoA) > 2b = CoA Test (CT) 2b. CN-------------->MN(CoA) > 3 = BU 3. MN(CoA)--------->CN From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 13:36: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 NAA15898 for ; Tue, 5 Mar 2002 13:36: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 LAA05503; Tue, 5 Mar 2002 11:36: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 KAA19166; Tue, 5 Mar 2002 10: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 g25IZVKL029389 for ; Tue, 5 Mar 2002 10:35:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IZUM2029388 for mobile-ip-dist; Tue, 5 Mar 2002 10: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 g25IZQKL029381 for ; Tue, 5 Mar 2002 10:35:26 -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 KAA18853 for ; Tue, 5 Mar 2002 10:35:26 -0800 (PST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00617 for ; Tue, 5 Mar 2002 10:35:24 -0800 (PST) Received: from jariws1 ([62.248.148.147]) by fep06-app.kolumbus.fi with SMTP id <20020305183511.YWYB20539.fep06-app.kolumbus.fi@jariws1>; Tue, 5 Mar 2002 20:35:11 +0200 Message-ID: <020501c1c474$85e65600$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Alexandru Petrescu" Cc: References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi><01c001c1c472$3f961200$8a1b6e0a@arenanet.fi> Subject: Re: [mobile-ip] Return Routability Date: Tue, 5 Mar 2002 20:35:28 +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 > But in that case I can be at home and flood HTI's to CN that will > flood the attacked MN with with CT's right? Right, but that's no different from regular packets. The issue is having a third address somewhere in the packet that redirects you to another place, and bypasses possible ingress filtering that was performed on your packets. As long as answers go where requests came from, we are as safe as we can be in the current internet. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 14:08: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 OAA16119 for ; Tue, 5 Mar 2002 14:08:13 -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 MAA24182; Tue, 5 Mar 2002 12:08: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 LAA27646; Tue, 5 Mar 2002 11:07: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 g25J6lKL029604 for ; Tue, 5 Mar 2002 11:06:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25J6lhR029603 for mobile-ip-dist; Tue, 5 Mar 2002 11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25J6hKL029596 for ; Tue, 5 Mar 2002 11:06:43 -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 LAA08960 for ; Tue, 5 Mar 2002 11:06:43 -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 MAA16156 for ; Tue, 5 Mar 2002 12:06:42 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA16438; Tue, 5 Mar 2002 12:06:39 -0700 (MST)] Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA04232; Tue, 5 Mar 2002 12:06:38 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id g25J6VA05419; Tue, 5 Mar 2002 13:06:32 -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 C31342EC83; Tue, 5 Mar 2002 20:06:29 +0100 (CET) To: "Jari Arkko" Cc: Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> <01c001c1c472$3f961200$8a1b6e0a@arenanet.fi> <020501c1c474$85e65600$8a1b6e0a@arenanet.fi> From: Alexandru Petrescu Date: 05 Mar 2002 20:06:29 +0100 In-Reply-To: <020501c1c474$85e65600$8a1b6e0a@arenanet.fi> Message-ID: Lines: 24 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: "Jari Arkko" writes: > > But in that case I can be at home and flood HTI's to CN that will > > flood the attacked MN with with CT's right? > > Right, but that's no different from regular packets. The issue is > having a third address somewhere in the packet that redirects you to > another place, and bypasses possible ingress filtering that was > performed on your packets. As long as answers go where requests came > from, we are as safe as we can be in the current internet. Aha, I see your above "first do no harm" point. I fail to see, however, the exact meaning probably because I don't know what exactly goes into each RR message. I was trying to say that the "reflection" thing is valid the other way around too, and the mechanisms used to protect against it (I have rate limiting in mind) should work for the first one too, this leading to possibly not needing the HTI. But I find it difficult to look at a protocol to which I can only make assumptions of how it works. I probably need to wait for when further refinements come out. Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 14:18: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 OAA21752 for ; Tue, 5 Mar 2002 14:18: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 MAA03440; Tue, 5 Mar 2002 12:18: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 LAA00587; Tue, 5 Mar 2002 11:17: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 g25JFwKL029801 for ; Tue, 5 Mar 2002 11:15:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JFw1B029800 for mobile-ip-dist; Tue, 5 Mar 2002 11:15: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 g25JFrKL029793 for ; Tue, 5 Mar 2002 11:15:53 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25JFkx01031; Tue, 5 Mar 2002 20:15:46 +0100 (MET) Date: Tue, 5 Mar 2002 20:10:45 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C850DCF.5BB1A33E@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: > - what is in the tag is less important compared to the presence of tag > itself. > So, packets should not be dropped because tag=X. > Having said this, what is in the tag is important for diagnostics. I think the content of the tag is important for traceback reasons as well as for filtering reasons at a HA. For instance, if an attacker sending packets with src=X and HOA=HoA can cause packets to be reflected from the CN with dst=HoA, src=CN, tag=CoA then it is as if the attacker had managed to send a packet with src=CoA, HOA=HoA. The purpose of this exercise is to at least be able to trace such cases in order for the MN (or HA) to get the value X i.e. to know the IP address of the attacker. > - if the CN sends an unsolicited packet because the attacker initiated > a response, that response would contain the tag. So, there is > traceability That assumes that the MN doesn't send packets to the CN with such timing that the unvHAO cache entry always contains tag=CoA when the CN sends packets (and never tag=X when the CN sends packets). This is hard to predict since it depends on the timing patterns of the application and transport protocols as well as the ability of the attacker to predict those patterns. One way of trying to capture this is by asking a question about the requirements. Imagine that P percent of the packets arriving at the CN have src=X, HOA=HoA and 100-P percent have src = CoA, HOA=HoA Then what is an acceptable range of percentage of packets sent by the CN that have tag=X? (Call this value Q) Is zero ok? Is close to zero ok? Should it be same order of magnitude as P? Is 100% ok? > - if the CN is responding to the MN's packets, but includes > tag=X, what's > the harm ? The MN (or the HA) can find out that someone is attempting > to use the MN'a HoA. The packet as such is fine; in fact, it has important > traceability information. For one thing your writeup says that the HA is free (should?) drop such packets. If P is 10% then if Q becomes 100% then the off-path attacker has managed a DoS attack against the MNs traffic. If P is 10% makes Q become 0% then the off-path attacker has managed to do undetectable reflection attacks. > So, an attacker cannot disrupt the flow to a MN. Hope this is useful.. See above. I think requiring that the HA pass packets indepedent of the tag value (i.e. the tag value is purely for traceability) at least doesn't cause problems in the case when Q becomes 100%. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 14:25: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 OAA22302 for ; Tue, 5 Mar 2002 14:25:49 -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 MAA07610; Tue, 5 Mar 2002 12:25: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 LAA02945; Tue, 5 Mar 2002 11:25: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 g25JOnKL000111 for ; Tue, 5 Mar 2002 11:24:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JOnAO000110 for mobile-ip-dist; Tue, 5 Mar 2002 11:24: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 g25JOjKL000103 for ; Tue, 5 Mar 2002 11:24:45 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25JOdx01639; Tue, 5 Mar 2002 20:24:39 +0100 (MET) Date: Tue, 5 Mar 2002 20:19:38 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Return Routability To: jari.arkko@kolumbus.fi Cc: Alexandru Petrescu , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <020501c1c474$85e65600$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: > > But in that case I can be at home and flood HTI's to CN that will > > flood the attacked MN with with CT's right? > > Right, but that's no different from regular packets. The issue > is having a third address somewhere in the packet that redirects > you to another place, and bypasses possible ingress filtering > that was performed on your packets. As long as answers go > where requests came from, we are as safe as we can be in > the current internet. Hmm.. The response to a HTI would be a HT, and the response to a CTI would be a CT. Thus the response it always sent to the IP source address of the request/init. Hence there is no reflection danger. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 14:31:17 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 OAA22766 for ; Tue, 5 Mar 2002 14:31:17 -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 LAA01722; Tue, 5 Mar 2002 11:31: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 LAA04391; Tue, 5 Mar 2002 11:31: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 g25JTiKL000165 for ; Tue, 5 Mar 2002 11:29:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JTh14000164 for mobile-ip-dist; Tue, 5 Mar 2002 11:29: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 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 g25JTgKL000155 for ; Tue, 5 Mar 2002 11:29:42 -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 OAA23542 for ; Tue, 5 Mar 2002 14:29:41 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA10245 for mobile-ip@sunroof.eng.sun.com; Tue, 5 Mar 2002 14:30:33 -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 g254MjKL026186 for ; Mon, 4 Mar 2002 20:22:45 -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 UAA25230 for ; Mon, 4 Mar 2002 20:22:47 -0800 (PST) Received: from tesla.eecs.ku.edu (tesla.eecs.ku.edu [129.237.116.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15159 for ; Mon, 4 Mar 2002 20:22:47 -0800 (PST) Received: from tesla.eecs.ku.edu (tesla.eecs.ku.edu [129.237.116.6]) by tesla.eecs.ku.edu (8.10.2/8.10.2) with ESMTP id g254MfF60927; Mon, 4 Mar 2002 22:22:41 -0600 (CST) Date: Mon, 4 Mar 2002 22:22:41 -0600 (CST) From: Gurunandan Pai To: mobile-ip@sunroof.eng.sun.com, , Subject: [mobile-ip] Mobile IP setup (fwd) Message-ID: <20020304221039.G60567-100000@tesla.eecs.ku.edu> 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: Sir, I am trying to implement the draft "NAT traversal using UDP tunneling draft". I have the setup (described at the end of the email) running but I am confused about something. It would be great if you can help me out with this. I am either doing something terribly wrong if I am thinking that I should configure the NAT on the gateway (Testbed9) or I am confused. Lets assume the the NAT is on the gateway(testbed9) and see what happens. The MN on testbed23 which is behind the NAT GW on testbed9 will send a registration request to HA(Testbed31). Ok, so the NAT translates the IP source address in the IP header of that packet while it is flowing out of the gateway testbed9. HA gets that packet. But even though the source IP address in the IP header has been changed from 10.50.50.50 to something else it still reads in the Registration Request message that the care of address is 10.50.50.50. It looks at that and creates a mobility binding in its kernel which associates the 10.50.50.50 care of address and its original home IP address. Next time it gets a packet destined for mobile node's original home IP address, it can do the IP-IP encapsulation (lower IP header has destn address as original IP address of the MN and upper IP has destn address as care-of-address). The packet can now reach the MN if testbed31 has a route to 10.50.50.50. Right now, it does,through the GW although ideally the 10.50.50.50 should be hidden behind the NAT and no host outside the NAT should have a route to it through the NAT. But since the MN revealed its care-of-address which was private, to HA, HA can reach the MN. Now lets assume that in the ideal case HA has a route till only the gateway and not to 10.50.50.50. The packet HA created/encapsulated shows an outer IP destn Address as 10.50.50.50. The HA woulndt know what to do with it and puts it out on the default router. How would the UDP header help in this case? Even if the UDP header is inserted between the two IP headers, the outer IP destn address is still 10.50.50.50 and not a public address the NAT translated the 10.50.50.50 to. Even if the gateway with NAT on it picks it up (if I make that as a default router) it does not need extra info about the UDP port cause the packet exclusively says that it is addressed to 10.50.50.50. Now, what if the NAT is on the MN itself? Will the care of address field in the registration reuqest also be translated? I dont think so. The draft too says that there is a expected dicrpeancy between the IP source address in the IP header that is translated and the care-of-address field in the regitration request which is not. If HA was looking at the IP source address of the registration to gain info about the care-of-address then everything fits in place. But the HA, atleast in the Mosquito Net implementation, looks directly at the care-of-address field of the reg req message which is left untranslated. Your thoughts on this???? ---------------------SETUP---------------------------------- We got the Mosquito Net mobilei implementation running with the home agent on the ITTC (home) network and the mobile node with a co-located care of address in a foreign network. |-----------------------| eth0 |-------| |ITTC n/w (Home n/w) |-------|TB31 HA| |-----------------------| |-------| | 129.237.126.206(also vif's addy) eth0 |129.237.125.144 |---------| |TB9 GW | |---------| eth1 |10.50.50.51 | | |---------| | Switch | |---------| | eth1 |10.50.50.50 |---------| |TB23 MN | |---------| Testbed23: Mobile Node. linux 2.2.14 with MIP patch provided by Mosquito Mobile IP support,IP:advanced router,IP:policy routing, IP:tunneling, Kernel/User netlink socket and routing messages enabled Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 129.237.120.0 10.50.50.51 255.255.248.0 UG 0 0 0 eth1 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 10.50.50.51 0.0.0.0 UG 0 0 0 eth1 Testbed 31 Home agent. linux 2.2.14 with MIP patch provided by Mosquito Mobile IP support,IP:advanced router,IP:policy routing, IP:tunneling, Kernel/User netlink socket and routing messages enabled Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 129.237.120.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0 129.237.120.0 0.0.0.0 255.255.248.0 U 0 0 0 vif 10.0.0.0 129.237.125.144 255.0.0.0 UG 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 129.237.127.254 0.0.0.0 UG 0 0 0 eth0 Testbed 9 Gateway to foreign n/w linux 2.3.99 ip_forwarding enabled Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 129.237.120.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0 10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 129.237.127.254 0.0.0.0 UG 0 0 0 eth0 Contents of mhd.conf file: HOME_ADDR = 129.237.125.244 HOME_NETMASK = 255.255.248.0 HOMEAGENT_ADDR = 129.237.126.206 HOME_INTERFACE = eth0 DEFAULT_LIFETIME = 1800 SECURITY_ASSOCIATION = 1000 1234567890abcdef Contents of had.conf file: HA_IPADDR = 129.237.126.206 HOME_NETMASK = 255.255.248.0 HOME_INTERFACE = eth0 # This should be the last part of the configuration file. # Make sure the specified number of moble hosts match the number of lines # for mobile host configuration. MOBILE_HOSTS = 1 129.237.125.244 1000 1234567890abcdef Sincerely, Gurunandan.Pai From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 15:06: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 PAA24555 for ; Tue, 5 Mar 2002 15:06:09 -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 NAA01938; Tue, 5 Mar 2002 13:06: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 MAA14114; Tue, 5 Mar 2002 12:05: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 g25K4bKL000509 for ; Tue, 5 Mar 2002 12:04:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25K4aO1000508 for mobile-ip-dist; Tue, 5 Mar 2002 12: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 g25K4XKL000501 for ; Tue, 5 Mar 2002 12:04: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 MAA04533 for ; Tue, 5 Mar 2002 12:04:34 -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 NAA25561 for ; Tue, 5 Mar 2002 13:04: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 MAA11307; Tue, 5 Mar 2002 12:04:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g25K4XV20777; Tue, 5 Mar 2002 12:04:33 -0800 X-mProtect:  Tue, 5 Mar 2002 12:04:33 -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 smtpdwMHcJK; Tue, 05 Mar 2002 12:04:31 PST Message-ID: <3C8524CF.81116F57@iprg.nokia.com> Date: Tue, 05 Mar 2002 12:04:31 -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] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 in the tag is less important compared to the presence of tag > > itself. > > So, packets should not be dropped because tag=X. > > Having said this, what is in the tag is important for diagnostics. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I think the content of the tag is important for traceback reasons > as well as for filtering reasons at a HA. I think we are saying the same thing.. Note that I didn't say the content of the tag is not important. > > > For instance, if an attacker sending packets with src=X and HOA=HoA > can cause packets to be reflected from the CN with dst=HoA, src=CN, tag=CoA > then it is as if the attacker had managed to send a packet > with src=CoA, HOA=HoA. The purpose of this exercise is to at least be > able to trace such cases in order for the MN (or HA) to get the value X > i.e. to know the IP address of the attacker. > Couldn't agree more, never has disagreed. > > > - if the CN sends an unsolicited packet because the attacker initiated > > a response, that response would contain the tag. So, there is > > traceability > > That assumes that the MN doesn't send packets to the CN with such timing that > the unvHAO cache entry always contains tag=CoA when the CN sends packets > (and never tag=X when the CN sends packets). > This is hard to predict since it depends on the timing patterns > of the application and transport protocols as well as the ability of the > attacker to predict those patterns. > Actually, there is no such assumption. In any case, - if the MN did not send any packets, CN's packets will contain tag=X. - if the MN did send packets, tag=CoA > > One way of trying to capture this is by asking a question about the > requirements. > > Imagine that P percent of the packets arriving at the CN have > src=X, HOA=HoA > and 100-P percent have > src = CoA, HOA=HoA > Then what is an acceptable range of percentage of packets sent > by the CN that have tag=X? (Call this value Q) > Is zero ok? Is close to zero ok? Should it be same order of magnitude as P? > Is 100% ok? > I don't know what you are trying to convey here.. - if tag=X, you know someone is trying to introduce a spurious tag. - _if_ it so happens that you never see tag=X, the attacker has not succeeded in actually introducing the spurious tag - if some packets contain tag=X, others contain tag=CoA, that's still ok; i.e., there is no disruption. Am I missing something here from a protocol perspective ? > > > - if the CN is responding to the MN's packets, but includes > > tag=X, what's > > the harm ? The MN (or the HA) can find out that someone is attempting > > to use the MN'a HoA. The packet as such is fine; in fact, it has important > > traceability information. > > For one thing your writeup says that the HA is free (should?) drop such > packets. In a previous e-mail, I did mention that we should consider HA tunneling all packets regardless of the tag value. See below. "Since ..... One thing that might be useful to consider is that instead of dropping the packet containing X as a tag, the HA may tunnel that packet also to the MN. So, the MN always receives packets from the CN." > > If P is 10% then if Q becomes 100% then the off-path attacker has managed > a DoS attack against the MNs traffic. > This cannot happen when the HA tunnels all packets. > If P is 10% makes Q become 0% then the off-path attacker has managed to do > undetectable reflection attacks. For Q to be 0%, there has to be correcting operation, meaning packet flow from the MN in such a manner that it exactly coincides with removing every single tag=X, something you have expressed your own reservations above in "That assumes that the MN doesn't send packets to the CN with such timing that the unvHAO cache entry always contains tag=CoA when the CN sends packets (and never tag=X when the CN sends packets). This is hard to predict since it depends on the timing patterns of the application and transport protocols as well as the ability of the attacker to predict those patterns." > > > > So, an attacker cannot disrupt the flow to a MN. Hope this is useful.. > > See above. > > I think requiring that the HA pass packets indepedent of the tag value (i.e. > the tag value is purely for traceability) at least doesn't cause > problems in the case when Q becomes 100%. > I did mention this in a previous e-mail. Looks like it is good thing to specify the HA to tunnel all packets. -Rajeev > > Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 16:06: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 QAA28751 for ; Tue, 5 Mar 2002 16:05: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 OAA02960; Tue, 5 Mar 2002 14:05: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 NAA00874; Tue, 5 Mar 2002 13:05: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 g25L4VKL000699 for ; Tue, 5 Mar 2002 13:04:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25L4V0i000698 for mobile-ip-dist; Tue, 5 Mar 2002 13:04: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 g25L4QKL000691 for ; Tue, 5 Mar 2002 13:04:27 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25L4Hx07762; Tue, 5 Mar 2002 22:04:17 +0100 (MET) Date: Tue, 5 Mar 2002 21:59:17 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C8524CF.81116F57@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: > - if tag=X, you know someone is trying to introduce a spurious tag. Or trying to use the CN as a reflector for DoS purposes. This is fine in the sense that it is observable by the MN (or HA) - they can see the value X. > - _if_ it so happens that you never see tag=X, the attacker has not succeeded > in actually introducing the spurious tag Introducing a spurios tag isn't the original security problem we tried to address, but a security problem which appeared in earlier versions of your proposal. The original security problem is reflection attacks using HAO that can - not be prevented using ingress filtering - not be detected Thus my issue is about the original security problem. What if the all packets arrive at the HA and MN with tag=CoA but the attacker X is in fact injecting 10 Mbps per second of packets (with src=X, HAO=HoA) that get reflected to the poor MN (all with tag=CoA). See below for examples. > - if some packets contain tag=X, others contain tag=CoA, that's still ok; i.e., > there is no disruption. Yes, as long as you remove the suggestion that says: 3. If packets arrive with erroneous tags, a Home Agent drops those packets. It may optionally send an ICMP destination unreachable message in which it includes the correct tag (i.e., the correct CoA from its BC) that updates the unverified BCE. Meanwhile, any packet from the genuine MN with an HAO would also correct the CN's entry. On the other hand, the HA tunnels packets with correct tags to the MN. and instead require the HA and MN to process packets indepedent of their tag value. When the CN receives a mix of packets with src=X,HAO=HoA and src=CoA,HAO=HoA it will hopefully mark a mix of packets with tag=X and tag=CoA (and we need to figure out to ensure that at least some packets have tag=X for traceability). My point is that the tag value can't be use to filter out the bad packets because there will not be any correlation between the src of a packet received at the CN and the tag value of the response to that packet when there are multiple packets in progress. For example, if the attacker sends TCP SYN packets packets while the real MN is doing VoIP with the CN we could have this time line at the CN: src=CoA,HAO=HoA VoIP UDP packet received by IP tag value set to CoA src=CoA,HAO=HoA VoIP UDP packet received by IP src=CoA,HAO=HoA VoIP UDP packet received by IP src=X,HAO=HoA tcp syn port 80 received by IP tag value set to X VoIP UDP packet sent by IP - gets tagged with X VoIP UDP packet sent by IP - gets tagged with X VoIP UDP packet sent by IP - gets tagged with X src=CoA,HAO=HoA VoIP UDP packet received by IP tag value set to CoA TCP SYN ack sent by IP - gets tagged with CoA In the above extreme example the "good" packets all the get the "bad" X tag and the reflected attack packets get the "good" CoA tag. Thus the HA and/or CN can't use the tag value to filter out the reflected packets. Reordering the packets in the above example we can also get src=CoA,HAO=HoA VoIP UDP packet received by IP tag value set to CoA src=CoA,HAO=HoA VoIP UDP packet received by IP src=CoA,HAO=HoA VoIP UDP packet received by IP src=X,HAO=HoA tcp syn port 80 received by IP tag value set to X src=CoA,HAO=HoA VoIP UDP packet received by IP tag value set to CoA VoIP UDP packet sent by IP - gets tagged with CoA VoIP UDP packet sent by IP - gets tagged with CoA VoIP UDP packet sent by IP - gets tagged with CoA TCP SYN ack sent by IP - gets tagged with CoA Thus none of the packets get tagged with X. This means that the HA and/or MN can't even tell that they are subject to a DoS reflection attack using the content of the tags. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 5 22:23: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 WAA12281 for ; Tue, 5 Mar 2002 22:23: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 TAA29239; Tue, 5 Mar 2002 19: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 TAA21727; Tue, 5 Mar 2002 19:23: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 g263M8KL001628 for ; Tue, 5 Mar 2002 19:22:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g263M7Qk001627 for mobile-ip-dist; Tue, 5 Mar 2002 19:22: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 g263M4KL001620 for ; Tue, 5 Mar 2002 19:22:04 -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 TAA22300 for ; Tue, 5 Mar 2002 19:22:05 -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 TAA27244 for ; Tue, 5 Mar 2002 19:22: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 TAA09115; Tue, 5 Mar 2002 19:22:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g263M3o18205; Tue, 5 Mar 2002 19:22:03 -0800 X-mProtect:  Tue, 5 Mar 2002 19:22:03 -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 smtpd0G6mP6; Tue, 05 Mar 2002 19:22:01 PST Message-ID: <3C858B5A.5AFAC28A@iprg.nokia.com> Date: Tue, 05 Mar 2002 19:22:02 -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] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 tag=X, you know someone is trying to introduce a spurious tag. > > Or trying to use the CN as a reflector for DoS purposes. > This is fine in the sense that it is observable by the MN (or HA) - they > can see the value X. > > > - _if_ it so happens that you never see tag=X, the attacker has not succeeded > > in actually introducing the spurious tag > > Introducing a spurios tag isn't the original security problem we tried to > address, but a security problem which appeared in earlier versions of > your proposal. A spurious tag means the attacker introduces his source IP address. There is no security problem with it. > The original security problem is reflection attacks using HAO that can > - not be prevented using ingress filtering > - not be detected > > Thus my issue is about the original security problem. > What if the all packets arrive at the HA and MN with tag=CoA but the > attacker X is in fact injecting 10 Mbps per second of packets (with > src=X, HAO=HoA) that get reflected to the poor MN (all with tag=CoA). > See below for examples. > It is a good "what if". If the attacker is injecting at the rate you mention, I don't see how even a small percentage of packets do not contain tag=X, and hence get traced. I will wait for your examples.. > > > - if some packets contain tag=X, others contain tag=CoA, that's still ok; i.e., > > there is no disruption. > > Yes, as long as you remove the suggestion that says: > 3. If packets arrive with erroneous tags, a Home Agent drops those > packets. It may optionally send an ICMP destination unreachable > message in which it includes the correct tag (i.e., the correct CoA > from its BC) that updates the unverified BCE. Meanwhile, any packet > from the genuine MN with an HAO would also correct the CN's > entry. On the other hand, the HA tunnels packets with correct tags > to the MN. > and instead require the HA and MN to process packets indepedent of > their tag value. > I don't know why this is still lingering.. - in an earlier e-mail I said the HA tunneling all packets is a good thing - in my previous e-mail I said such a specification would be a good thing. Did I indicate any reservations otherwise ? In any case, please note that I have already agreed to this (after proposing it even earlier). > > When the CN receives a mix of packets with src=X,HAO=HoA and src=CoA,HAO=HoA > it will hopefully mark a mix of packets with tag=X and tag=CoA > (and we need to figure out to ensure that at least some packets have tag=X > for traceability). > You didn't respond to your own observation in the previous e-mail. "That assumes that the MN doesn't send packets to the CN with such timing that the unvHAO cache entry always contains tag=CoA when the CN sends packets (and never tag=X when the CN sends packets). This is hard to predict since it depends on the timing patterns of the application and transport protocols as well as the ability of the attacker to predict those patterns." > > My point is that the tag value can't be use to filter out the bad > packets because there will not be any correlation between > the src of a packet received at the CN and the tag value of the response > to that packet when there are multiple packets in progress. > If the tag!=CoA, you know there is an attempt to use HoA. If your argument is against using filtering, that's valid. Please also specify where in the current text you would like this to be noted. > > For example, if the attacker sends TCP SYN packets packets while the > real MN is doing VoIP with the CN we could have this time line at the CN: > src=CoA,HAO=HoA VoIP UDP packet received by IP > tag value set to CoA > src=CoA,HAO=HoA VoIP UDP packet received by IP > src=CoA,HAO=HoA VoIP UDP packet received by IP > src=X,HAO=HoA tcp syn port 80 received by IP > tag value set to X > VoIP UDP packet sent by IP - gets tagged with X > VoIP UDP packet sent by IP - gets tagged with X > VoIP UDP packet sent by IP - gets tagged with X > src=CoA,HAO=HoA VoIP UDP packet received by IP > tag value set to CoA > TCP SYN ack sent by IP - gets tagged with CoA > > > In the above extreme example the "good" packets all the get the "bad" X tag > and the reflected attack packets get the "good" CoA tag. > > Thus the HA and/or CN can't use the tag value to filter out the reflected > packets. Ok. I am willing to include this "extreme example" in the document. You can still ascertain that there is an attempt to cause reflection attack. > > > Reordering the packets in the above example we can also get > src=CoA,HAO=HoA VoIP UDP packet received by IP > tag value set to CoA > src=CoA,HAO=HoA VoIP UDP packet received by IP > src=CoA,HAO=HoA VoIP UDP packet received by IP > src=X,HAO=HoA tcp syn port 80 received by IP > tag value set to X > src=CoA,HAO=HoA VoIP UDP packet received by IP > tag value set to CoA > VoIP UDP packet sent by IP - gets tagged with CoA > VoIP UDP packet sent by IP - gets tagged with CoA > VoIP UDP packet sent by IP - gets tagged with CoA > TCP SYN ack sent by IP - gets tagged with CoA > > > Thus none of the packets get tagged with X. This means that the HA and/or MN > can't even tell that they are subject to a DoS reflection attack using the > content of the tags. > In this particular case, you cannot determine the source of TCP SYN. Here is a way to resolve this: the CN must `commit' a new update only after sending at least one packet with the existing tag! A counter is set to one (or some small integer to account for packet losses) when a new CoA (such as X) is received. When the MN's VoIP packet is received, its CoA does not replace X until the counter is zero. The counter is decremented every time an entry is tagged. Downside: extra storage for another address. Still does not necessarily provide the ability to put the bad tag on the bad packet. However, it provides the alarm ability. -Rajeev > > Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 03:07: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 DAA27042 for ; Wed, 6 Mar 2002 03:07:57 -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 AAA29446; Wed, 6 Mar 2002 00:07: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 AAA24410; Wed, 6 Mar 2002 00:07: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 g2686wKL002221 for ; Wed, 6 Mar 2002 00:06:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2686wlH002220 for mobile-ip-dist; Wed, 6 Mar 2002 00:06: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 g2686tKL002213 for ; Wed, 6 Mar 2002 00:06: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 AAA15092 for ; Wed, 6 Mar 2002 00:06:53 -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 AAA19347 for ; Wed, 6 Mar 2002 00:06:52 -0800 (PST) Received: from nomadiclab.com (n100.nomadiclab.com [131.160.193.100]) by ws177.nomadiclab.com (Postfix) with ESMTP id E59FBA; Wed, 6 Mar 2002 10:08:42 +0200 (EET) Message-ID: <3C85CDD6.3030102@nomadiclab.com> Date: Wed, 06 Mar 2002 10:05:42 +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: Rajeev Koodli , Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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: > When the CN receives a mix of packets with src=X,HAO=HoA and src=CoA,HAO=HoA > it will hopefully mark a mix of packets with tag=X and tag=CoA > (and we need to figure out to ensure that at least some packets have tag=X > for traceability). This is an observation that makes me to think that using any kind of cache for tagging is going to be very very hard. In fact, it looks like getting tagging "right", i.e. each packet is tagged with exactly the source address that triggered its sending, is impossible with caching techniques. Changing the API, as we discussed earlier, seems to fix the problem, and make tagging possible. These observations lead me, personally, to the opinion that we should make triangular routing and tagging an option. It looks like it will be extremely hard to require this from all CNs. Indeed, it looks much easier to require RR based RO from all CNs than this HAO prosessing and tagging support. As an option this seems to be fine, though, since the problems are related to local implementation at the CN, not the method as such. That is, *assuming* that the CN does tagging exactly correctly, it does not seem to open up new security problems. The hard part is getting the tagging implemented correctly. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 04:12: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 EAA28079 for ; Wed, 6 Mar 2002 04:12:13 -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 BAA10161; Wed, 6 Mar 2002 01:12: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 BAA11176; Wed, 6 Mar 2002 01: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 g269AfKL002375 for ; Wed, 6 Mar 2002 01:10:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g269Ae3d002374 for mobile-ip-dist; Wed, 6 Mar 2002 01:10: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 g269AXKL002367 for ; Wed, 6 Mar 2002 01:10:33 -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 BAA01773 for ; Wed, 6 Mar 2002 01:10:32 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26827 for ; Wed, 6 Mar 2002 01:10:21 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA21317; Wed, 6 Mar 2002 02:10:11 -0700 (MST)] Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id CAA03463; Wed, 6 Mar 2002 02:10:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id g269A2i13087; Wed, 6 Mar 2002 03:10:04 -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 42A2B2EC85; Wed, 6 Mar 2002 10:09:55 +0100 (CET) To: "Jari Arkko" Cc: Subject: Re: [mobile-ip] Return Routability References: <3C842A33.A5F2E78C@cs.ucsb.edu> <3C84C020.542A4E2C@lmf.ericsson.se> <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> From: Alexandru Petrescu Date: 06 Mar 2002 10:09:55 +0100 In-Reply-To: <010301c1c469$6fff5860$8a1b6e0a@arenanet.fi> Message-ID: Lines: 11 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: "Jari Arkko" writes: > 1a = HoA Test Init (HTI) > 1b = CoA Test Init (CTI) > 2a = HoA Test (HT) > 2b = CoA Test (CT) > 3 = BU I think I've already seen somewhere HTI short for Handoff Transfer Initiate and CTI short for Context Transfer Initiate... Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 04:40: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 EAA28524 for ; Wed, 6 Mar 2002 04:40:50 -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 CAA12084; Wed, 6 Mar 2002 02:40: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 BAA05084; Wed, 6 Mar 2002 01:40: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 g269dqKL002541 for ; Wed, 6 Mar 2002 01:39:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g269dqZg002540 for mobile-ip-dist; Wed, 6 Mar 2002 01:39: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 g269dlKL002533 for ; Wed, 6 Mar 2002 01:39:48 -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 g269dgx20731; Wed, 6 Mar 2002 10:39:42 +0100 (MET) Date: Wed, 6 Mar 2002 10:34:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: Rajeev Koodli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C858B5A.5AFAC28A@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 don't know why this is still lingering.. > > - in an earlier e-mail I said the HA tunneling all packets is a good thing > - in my previous e-mail I said such a specification would be a good thing. > > Did I indicate any reservations otherwise ? In any case, please note that I > have already agreed to this (after proposing it even earlier). The reason I brought it up this time was that it would seem useful for the HA to be able to filter such reflected DoS packets as you had originally suggested. But the behavior of the tagging doesn't allow it. Sorry for not making this clear. > You didn't respond to your own observation in the previous e-mail. Was I supposed to respond to myself? > "That assumes that the MN doesn't send packets to the CN with such timing > that the unvHAO cache entry always contains tag=CoA when the CN sends packets > (and never tag=X when the CN sends packets). This is hard to predict since > it depends on the timing patterns of the application and transport protocols > as well as the ability of the attacker to predict those patterns." > If the tag!=CoA, you know there is an attempt to use HoA. If your > argument is against using filtering, that's valid. Please also > specify where in the current text you would like this to be noted. I'm sufficiently confused by what problem we are trying to solve here to not be able to suggest text. Is the only problem we are trying to solve the ability for the MN/HA to tell that it is likely under a reflection attack? It seems like it could tell that e.g. by observing all the SYN ACK packets in my example. Or are we also trying to give the MN/HA the tag(s) associated with the attackers so that they could try to convince entities between the CN and those attackers to filter out those packets? (As already pointed out no filtering can be done between the CN and HA on the tag content.) It would be useful to agree on the goals before proceeding. The goals of the DT proposal was "do no harm" i.e. don't open up new ways that an attacker can circumvent prevention measures like ingress filtering as well as not making it harder to detect/traceback the attackers. As far as I can tell the goals of the unvHAO proposal are different, but I don't have a good handle on exactly what the security goals are here. > In this particular case, you cannot determine the source of TCP SYN. Here is > a way to resolve this: the CN must `commit' a new update only after sending > at least one packet with the existing tag! A counter is set to one (or some > small integer to > account for packet losses) when a new CoA (such as X) is received. When the > MN's VoIP packet is received, its CoA does not replace X until the counter > is zero. The counter is decremented every time an entry is tagged. > Downside: extra storage for another address. Still does not necessarily > provide the ability to put the bad tag on the bad packet. However, it > provides the alarm ability. Once we know what the goals are we could actual discuss something closer to proportial tagging as well. Imagine where a MN is flooded due to multiple attackers. It would be benefitial to be able to determine which source addresses cause the most amount of flooding. So there could be a small list of unvHAO source addresses that have been seen recently (LRU replacement) with a counter of how many have been seen. Those counters then effect the proportion of the tags. Sure, this isn't capable to placing the bad tags on the bad packets either. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 05:00: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 FAA28802 for ; Wed, 6 Mar 2002 05:00:19 -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 DAA20063; Wed, 6 Mar 2002 03:00: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 CAA07677; Wed, 6 Mar 2002 02:00: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 g269xOKL002616 for ; Wed, 6 Mar 2002 01:59:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g269xOnY002615 for mobile-ip-dist; Wed, 6 Mar 2002 01:59: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 g269xKKL002608 for ; Wed, 6 Mar 2002 01:59:20 -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 g269xHx22569; Wed, 6 Mar 2002 10:59:17 +0100 (MET) Date: Wed, 6 Mar 2002 10:54:16 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: Pekka Nikander Cc: mobile-ip@sunroof.eng.sun.com, Rajeev Koodli , Erik Nordmark In-Reply-To: "Your message with ID" <3C85CDD6.3030102@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: > These observations lead me, personally, to the opinion that we should > make triangular routing and tagging an option. It looks like it will > be extremely hard to require this from all CNs. Indeed, it looks > much easier to require RR based RO from all CNs than this HAO > prosessing and tagging support. Just to clarify, are you saying that we should make "exact tagging" an option (as opposed to the "cached/approximate tagging" we have been discussing recently) > As an option this seems to be fine, though, since the > problems are related to local implementation at the CN, not > the method as such. That is, *assuming* that the CN does > tagging exactly correctly, it does not seem to open up new > security problems. The hard part is getting the tagging > implemented correctly. If it is optional we need the ability for the MN to determine whether it can send unvHAO to a given CN. Seems to require a roundtrip exchange to determine this. Also, is the idea that nodes which implement exact tagging implement it for all transports i.e. for UDP as well as TCP, ICMP echo, SCTP, etc? The reason I ask is that it is easier to implement this as long as the application doesn't need to get involved, which it does for UDP at least. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 05:26: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 FAA29519 for ; Wed, 6 Mar 2002 05:26:46 -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 DAA11469; Wed, 6 Mar 2002 03:26: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 CAA10797; Wed, 6 Mar 2002 02:26: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 g26APNKL002846 for ; Wed, 6 Mar 2002 02:25:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26APNjW002845 for mobile-ip-dist; Wed, 6 Mar 2002 02:25: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 g26APGKL002838 for ; Wed, 6 Mar 2002 02:25:16 -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 CAA10635 for ; Wed, 6 Mar 2002 02:25:16 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10771 for ; Wed, 6 Mar 2002 03:24:40 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26ANx318729 for ; Wed, 6 Mar 2002 12:23:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 12:24:35 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 12:24:35 +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] Return Routability Date: Wed, 6 Mar 2002 12:24:34 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B20@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] Return Routability Thread-Index: AcHE7ygTAqAwqjLFT6ysc3DFPSkY2gACb/lg To: , X-OriginalArrivalTime: 06 Mar 2002 10:24:35.0252 (UTC) FILETIME=[1CD22740:01C1C4F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26APHKL002839 Sender: owner-mobile-ip@sunroof.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, > "Jari Arkko" writes: > > 1a = HoA Test Init (HTI) > > 1b = CoA Test Init (CTI) > > 2a = HoA Test (HT) > > 2b = CoA Test (CT) > > 3 = BU > > I think I've already seen somewhere HTI short for Handoff Transfer > Initiate and CTI short for Context Transfer Initiate... Which means we could have: 1a = HoA Test Init (HoTI) 1b = CoA Test Init (CoTI) 2a = HoA Test (HoT) 2b = CoA Test (CoT) 3 = BU Don't know if these are any better ;) John From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 06:27: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 GAA01511 for ; Wed, 6 Mar 2002 06:27:16 -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 EAA04772; Wed, 6 Mar 2002 04:27: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 DAA17290; Wed, 6 Mar 2002 03:27: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 g26BQAKL003052 for ; Wed, 6 Mar 2002 03:26:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26BQAIa003051 for mobile-ip-dist; Wed, 6 Mar 2002 03:26: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BQ7KL003044 for ; Wed, 6 Mar 2002 03:26:07 -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 DAA27090 for ; Wed, 6 Mar 2002 03:26:06 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23728 for ; Wed, 6 Mar 2002 03:26:04 -0800 (PST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA01584; Wed, 6 Mar 2002 04:25:45 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA04968; Wed, 6 Mar 2002 04:14:01 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g26BPIa28214; Wed, 6 Mar 2002 04:25:20 -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 2EE842EC84; Wed, 6 Mar 2002 12:25:38 +0100 (CET) To: , Cc: Subject: Re: [mobile-ip] Return Routability References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B20@esebe004.NOE.Nokia.com> From: Alexandru Petrescu Date: 06 Mar 2002 12:25:37 +0100 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B20@esebe004.NOE.Nokia.com> Message-ID: Lines: 35 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: > > "Jari Arkko" writes: > > > 1a = HoA Test Init (HTI) > > > 1b = CoA Test Init (CTI) > > > 2a = HoA Test (HT) > > > 2b = CoA Test (CT) > > > 3 = BU > > > > I think I've already seen somewhere HTI short for Handoff Transfer > > Initiate and CTI short for Context Transfer Initiate... john.loughney@nokia.com writes: > Which means we could have: > > 1a = HoA Test Init (HoTI) MN(HoA)--->HA--->CN > 1b = CoA Test Init (CoTI) MN(CoA)--------->CN > 2a = HoA Test (HoT) CN-------->HA--->MN(HoA) > 2b = CoA Test (CoT) CN-------------->MN(CoA) > 3 = BU MN(CoA)--------->CN > > Don't know if these are any better ;) I can use them, even if they're a bit long :-) One can notice that CoT is very close in meaning to a BR. Thus, we can consider that a normal packet that has a BR option will have an additional CoT option. This, of course, modulo the piggybacking discussion. Also, a HoT can be considered as a BR whose destination address is the HA address with the Home Address option of the MN. Again, modulo the piggybacking discussion. Thus only HoTI and CoTI are new messages to be defined. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 08:17: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 IAA06391 for ; Wed, 6 Mar 2002 08:17: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 FAA21260; Wed, 6 Mar 2002 05:16:51 -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 FAA08593; Wed, 6 Mar 2002 05: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 g26DFwKL003404 for ; Wed, 6 Mar 2002 05:15:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26DFwav003403 for mobile-ip-dist; Wed, 6 Mar 2002 05:15: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 g26DFsKL003396 for ; Wed, 6 Mar 2002 05:15:54 -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 FAA28978 for ; Wed, 6 Mar 2002 05:15:44 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04203 for ; Wed, 6 Mar 2002 06:15:43 -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 IAA06194; Wed, 6 Mar 2002 08:15:40 -0500 (EST) Message-Id: <200203061315.IAA06194@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-nat-traversal-01.txt Date: Wed, 06 Mar 2002 08:15:39 -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 : Mobile IP NAT/NAPT Traversal using UDP Tunnelling Author(s) : H. Levkowetz, S. Vaarala Filename : draft-ietf-mobileip-nat-traversal-01.txt Pages : 27 Date : 05-Mar-02 Mobile IP's datagram tunnelling is incompatible with Network Address Translation (NAT). This document presents extensions to the Mobile IP protocol and a tunnelling method which permits mobile nodes using Mobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-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-ietf-mobileip-nat-traversal-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-ietf-mobileip-nat-traversal-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: <20020305134225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 13:36: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 NAA25429 for ; Wed, 6 Mar 2002 13:36:04 -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 LAA08527; Wed, 6 Mar 2002 11:36: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 KAA13565; Wed, 6 Mar 2002 10:35: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 g26IYvKL005074 for ; Wed, 6 Mar 2002 10:34:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26IYvPQ005073 for mobile-ip-dist; Wed, 6 Mar 2002 10:34: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 g26IYsKL005066 for ; Wed, 6 Mar 2002 10:34:54 -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 KAA04490; Wed, 6 Mar 2002 10:34:52 -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 LAA26231; Wed, 6 Mar 2002 11:34:52 -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 KAA17424; Wed, 6 Mar 2002 10:34:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26IYpN32174; Wed, 6 Mar 2002 10:34:51 -0800 X-mProtect:  Wed, 6 Mar 2002 10:34:51 -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 smtpdd2gYZZ; Wed, 06 Mar 2002 10:34:49 PST Message-ID: <3C86614A.768D1D7C@iprg.nokia.com> Date: Wed, 06 Mar 2002 10:34:50 -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: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 > > You didn't respond to your own observation in the previous e-mail. > > Was I supposed to respond to myself? > I wasn't expecting you to do so :-) . I was referring to your text that I had included in _my_ e-mail that seemed to suggest that it is harder for an attacker to predict the timing patterns of applications on the MN. > > > "That assumes that the MN doesn't send packets to the CN with such timing > > that the unvHAO cache entry always contains tag=CoA when the CN sends packets > > (and never tag=X when the CN sends packets). This is hard to predict since > > it depends on the timing patterns of the application and transport protocols > > as well as the ability of the attacker to predict those patterns." > > > If the tag!=CoA, you know there is an attempt to use HoA. If your > > argument is against using filtering, that's valid. Please also > > specify where in the current text you would like this to be noted. > > I'm sufficiently confused by what problem we are trying to solve here > to not be able to suggest text. > > Is the only problem we are trying to solve the ability for the MN/HA to tell > that it is likely under a reflection attack? It seems like it could tell > that e.g. by observing all the SYN ACK packets in my example. > Or are we also trying to give the MN/HA the tag(s) associated with the > attackers so that they could try to convince entities between the CN > and those attackers to filter out those packets? > (As already pointed out no filtering can be done between the CN and HA > on the tag content.) > Let me try to clarify. - provide traceability. This would be more than detecting a reflection attack is underway. - allow for filtering. Here I see the confusion that arose above. I was thinking of filtering between CN and a GN, BTW. This was motivated by the fact that a GN's traffic should not be harmed, a point that Pekka Nikander had brought up earlier.. In that case, the packet mix would be between tag=X and no-tag. It is easier to distinguish; yet some good packets may get tagged with X, and may get dropped by a firewall. However, there is quick recovery. This is in the document, Section 3. As you rightly point out, this harder (due to approximate tagging) between CN and HA. However, as you say, you could offer such a possibility between CN and the attacker. [GN= Generic (non-mobile) IPv6 Node, MN at home] > > It would be useful to agree on the goals before proceeding. > The goals of the DT proposal was "do no harm" i.e. don't open up new ways > that an attacker can circumvent prevention measures like ingress filtering > as well as not making it harder to detect/traceback the attackers. > As far as I can tell the goals of the unvHAO proposal are different, but > I don't have a good handle on exactly what the security goals are here. > The goals are not any different. The Introduction section refers to traceability and filtering. If I could summarize this discussion, the proposal - offers traceability - facilitates filtering between CN and GN. It helps to see two different cases. First, e.g., the CN sends a TCP SYN ACK with tag=X. It gets dropped, which is what should happen. Second, during on-going session(s), tag=X appears, and the packet gets dropped. In this case, the min of {timer T1, next pkt arrival} wipes the tag out. Here, there is quick recovery from disruption. I hope this is helpful.. > > > In this particular case, you cannot determine the source of TCP SYN. Here is > > a way to resolve this: the CN must `commit' a new update only after sending > > at least one packet with the existing tag! A counter is set to one (or some > > small integer to > > account for packet losses) when a new CoA (such as X) is received. When the > > MN's VoIP packet is received, its CoA does not replace X until the counter > > is zero. The counter is decremented every time an entry is tagged. > > Downside: extra storage for another address. Still does not necessarily > > provide the ability to put the bad tag on the bad packet. However, it > > provides the alarm ability. > > Once we know what the goals are we could actual discuss something closer > to proportial tagging as well. > Imagine where a MN is flooded due to multiple attackers. > It would be benefitial to be able to determine which source addresses > cause the most amount of flooding. > So there could be a small list of unvHAO source addresses that have been > seen recently (LRU replacement) with a counter of how many have been seen. > Those counters then effect the proportion of the tags. > Hopefully the above is useful. To summarize again, always offer traceability and facilitate filtering with quick recovery (between CN and GN) were what we have attempted to address. Between a MN and CN, the proposal relies on `auto repair'. What should we do next ? I want to move forward :-) Regards, -Rajeev > > Sure, this isn't capable to placing the bad tags on the bad packets either. > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 15:18: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 PAA03085 for ; Wed, 6 Mar 2002 15:18: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 MAA05997; Wed, 6 Mar 2002 12:18:27 -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 MAA00843; Wed, 6 Mar 2002 12:18: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 g26KHIKL005461 for ; Wed, 6 Mar 2002 12:17:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26KHI2e005460 for mobile-ip-dist; Wed, 6 Mar 2002 12:17: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26KHFKL005453 for ; Wed, 6 Mar 2002 12:17:15 -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 MAA00600 for ; Wed, 6 Mar 2002 12:17:15 -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 NAA01615 for ; Wed, 6 Mar 2002 13:17: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 MAA25309; Wed, 6 Mar 2002 12:17:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26KHCC06757; Wed, 6 Mar 2002 12:17:12 -0800 X-mProtect:  Wed, 6 Mar 2002 12:17:12 -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 smtpdFNbjbo; Wed, 06 Mar 2002 12:17:10 PST Message-ID: <3C867946.B4B34215@iprg.nokia.com> Date: Wed, 06 Mar 2002 12:17:10 -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, Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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, I think it's time to step back and take a look at the overall situation in the discussion about Home Address Options (HAO). In order to avoid the need to read zillions of previous notes, I'd summarize the current status of the discussion as follows: - We have defined "Unverified HAO" to be one for which the correspondent node (CN) cannot be sure that the care-of address is correct, and "Verified HAO" to be one for which the correspondent node has a Binding Cache entry, perhaps secured by the return routability test. - We have proposed a scheme by which the CN tags outgoing packets with the care-of address claimed in a previously received unverified HAO. - There are cases where it is difficult to tag outgoing packets in a way so that the outgoing packets are tagged with the same care-of address claimed in the incoming packet that evoked the response. I believe that it is important to get this tagging capability represented in the upcoming base Mobile IPv6 specification. Here is a comparison of the advantages and disadvantages, on which we can try to make the decision. Unverified HAO allowable Unverified HAO prohibited - Robust to cache entry If CN times out or loses a Binding timeout and reclamation Cache entry, MN traffic is blackholed - Fast response to packets Delays for either reverse tunneling initiated by MN or Binding Cache Entry establishment. Worse if CN implements ONLY RR. - "Do No Harm" satisfied Reverse tunneling and black-holing is a "harm" - Vulnerability == "way_small" Vulnerability == 0. Briefly, I think that with the current tagging scheme, the vulnerability is so microscopic, and the benefits quite clearly worthwhile, that we should go for it. To be completely honest, I do not have data to determine whether the vulnerability is completely negligible, or only very, very small. I think that one could guesstimate the likelihood of the occurrences that you described, based on IP reordering pprobabilities, and it surely is a tiny probability. We have already designed ingress filtering techniques that almost completely eliminate any lingering abilities for attackers to mount this highly improbable attack. Furthermore, I suggest that the tagging be considered a typical part of a procedure to initiate the Return Routability establishment for a Binding Cache entry. This limits the window of vulnerability even more. It seems to be very natural. It would not MANDATE that the mobile node initiate the RR procedure, but that would be the typical case, and it would be the case we should design for general deployment. We only have to specify in the upcoming draft what the format of the tag should be, and that the CN is required to keep count of the incoming unverified HAOs. The way that the CN determines what to put in the tag can be an appendix, and would pretty much conform to the latest discussion that you have had with Rajeev. The protocol would not depend on the degree of precision by which the CN can determine the correct tag. As has been discussed, I can imagine that in the future a better method (perhaps involving changes to the socket structure) could be devised in the future, without changing the format of the tag. That is why I believe this material belongs in the appendix. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 15:44: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 PAA04603 for ; Wed, 6 Mar 2002 15:44:14 -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 NAA19580; Wed, 6 Mar 2002 13:44: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 MAA02535; Wed, 6 Mar 2002 12:44: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 g26KgTKL005574 for ; Wed, 6 Mar 2002 12:42:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26KgShp005573 for mobile-ip-dist; Wed, 6 Mar 2002 12:42: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 g26KgPKL005566 for ; Wed, 6 Mar 2002 12:42:25 -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 MAA01898; Wed, 6 Mar 2002 12:42:10 -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 MAA09573; Wed, 6 Mar 2002 12:42:08 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g26Kg6k16575; Wed, 6 Mar 2002 22:42:06 +0200 Date: Wed, 6 Mar 2002 22:42:06 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note In-Reply-To: <3C867946.B4B34215@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 Wed, 6 Mar 2002, Charles E. Perkins wrote: [snip] > Briefly, I think that with the current tagging scheme, the > vulnerability is so microscopic, and the benefits quite > clearly worthwhile, that we should go for it. > To be completely honest, I do not have data to determine > whether the vulnerability is completely negligible, or > only very, very small. I think that one could guesstimate > the likelihood of the occurrences that you described, based > on IP reordering pprobabilities, and it surely is a tiny > probability. We have already designed ingress filtering > techniques that almost completely eliminate any lingering > abilities for attackers to mount this highly improbable attack. Which vulnerability? If DoS reflecting is a vulnerability, I think I agree; packets will be tagged with something which can be traced (even though tracing may be very difficult at first because systems wouldn't support it). If being able to spoof one's source address is a vulnerability, I don't think the proposal addresses this..? -- 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 Mar 6 15:54: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 PAA05093 for ; Wed, 6 Mar 2002 15:54:54 -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 NAA25284; Wed, 6 Mar 2002 13:54: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 MAA06388; Wed, 6 Mar 2002 12:54: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 g26KroKL005652 for ; Wed, 6 Mar 2002 12:53:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26KroSs005651 for mobile-ip-dist; Wed, 6 Mar 2002 12:53: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 g26KrkKL005644 for ; Wed, 6 Mar 2002 12:53:46 -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 MAA08656 for ; Wed, 6 Mar 2002 12:53:47 -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 NAA17972 for ; Wed, 6 Mar 2002 13:53:46 -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 MAA27335 for ; Wed, 6 Mar 2002 12:53:46 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26KrjN20420; Wed, 6 Mar 2002 12:53:45 -0800 X-mProtect:  Wed, 6 Mar 2002 12:53: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 smtpdbq83yn; Wed, 06 Mar 2002 12:53:42 PST Message-ID: <3C8681D6.4EEF14EF@iprg.nokia.com> Date: Wed, 06 Mar 2002 12:53:42 -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 CC: mobile-ip@sunroof.eng.sun.com, Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 Pekka, Pekka Savola wrote: > On Wed, 6 Mar 2002, Charles E. Perkins wrote: > [snip] > > Briefly, I think that with the current tagging scheme, the > > vulnerability is so microscopic, and the benefits quite > > clearly worthwhile, that we should go for it. > Which vulnerability? I was referring to Erik's observation that, given Rajeev's state-based "best-effort" tagging proposal, packet reordering at the CN could cause packets to be sent out with the "wrong" tag. The malicious care-of address would still be observable, albeit in a different packet. But this would be a very rare occurrence. > If being able to spoof one's source address is a vulnerability, I don't > think the proposal addresses this..? That is true. We are assuming ingress filtering applies. If not, then anyway there is no real discussion because in that case the whole HAO design is just as traceable as non-ingress filtered packets (i.e., not). Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 17:15: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 RAA10468 for ; Wed, 6 Mar 2002 17:15: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 PAA15676; Wed, 6 Mar 2002 15:15: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 OAA12462; Wed, 6 Mar 2002 14:15: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 g26MEEKL006186 for ; Wed, 6 Mar 2002 14:14:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26MEE27006185 for mobile-ip-dist; Wed, 6 Mar 2002 14: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26MEBKL006178 for ; Wed, 6 Mar 2002 14:14: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 OAA02731 for ; Wed, 6 Mar 2002 14:14:10 -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 PAA28014 for ; Wed, 6 Mar 2002 15:14:09 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g26ME8w17290; Thu, 7 Mar 2002 00:14:08 +0200 Date: Thu, 7 Mar 2002 00:14:08 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note In-Reply-To: <3C8681D6.4EEF14EF@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 Wed, 6 Mar 2002, Charles E. Perkins wrote: > > If being able to spoof one's source address is a vulnerability, I don't > > think the proposal addresses this..? > > That is true. We are assuming ingress filtering applies. We may or may not be able to assume that. But unless ingress filtering is "smart" (c.f. Francis' approach), it won't help for the address in HAO case: that can still be spoofed regardless of ingress filtering. > If not, then anyway there is no real discussion because > in that case the whole HAO design is just as traceable as > non-ingress filtered packets (i.e., not). There are some small variations there but nothing earth-shattering. -- 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 Mar 6 17:54: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 RAA13191 for ; Wed, 6 Mar 2002 17:54: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 OAA09124; Wed, 6 Mar 2002 14:54:02 -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 OAA19360; Wed, 6 Mar 2002 14:53: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 g26Mr5KL006272 for ; Wed, 6 Mar 2002 14:53:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Mr5Ie006271 for mobile-ip-dist; Wed, 6 Mar 2002 14:53: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 g26Mr1KL006264 for ; Wed, 6 Mar 2002 14:53:02 -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 OAA19134 for ; Wed, 6 Mar 2002 14:53:01 -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 PAA26387 for ; Wed, 6 Mar 2002 15:53:00 -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 g26MqxW03538 for ; Wed, 6 Mar 2002 16:52:59 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 16:52:59 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0273A09E@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommenda tion note Date: Wed, 6 Mar 2002 16:52:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C561.A9425200" Sender: owner-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_01C1C561.A9425200 Content-Type: text/plain; charset="iso-8859-1" Rajeev, Jari and Charlie, My initial comments are interspersed. I have not had time to review all of the other related posts on the list so there may be duplicate comments/concerns. > Unverified HAO Processing > > Rajeev Koodli, Jari T. Malinen and Charles E. Perkins > > > This note specifies the author'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 the recommendation whether they > AGREE, CAN TOLERATE, or DISAGREE with them. In case of DISAGREE, > please explain why. > > > 1. INTRODUCTION > =============== > > The IPv6 specification [1] requires that every IPv6 node > process the Mobile IPv6 Home Address Option (HAO) [2]. In the > recent analysis of Mobile IPv6, concerns were raised that such a > processing without verifying if the sender actually owned the Home > Address (HoA) could lead to certain security vulnerabilities > [3]. As a consequence, the unverified use of HAO has > not been recommended in the design team recommendation. In this > document, we describe a mechanism that allows a CN to process > unverified HAO as it is currently specified using some implementation > extensions. > > There are two concerns regarding the unverified use of HAO. First, any > node (attacker) may use a CN as a reflector to send packets to one or > more victims without being traced, since the CN's response is sent to > the HoA with the CN's IP address as the source IP address. This is the > traceability problem. As a matter of comparison, if a such a DoS > attack were to happen today, the source IP address in the unsolicited > packet would be the (typically spoofed) IP address of the > sender. Second, as a response to prevent such attacks, source ingress > filtering is used to block certain packets. With HAO, such a mechanism > cannot readily be used. The solution proposed here requires a CN to > include the source IP address of the packet in a response message from > the CN. This allows the owner of the HoA to determine, from > the ``tag'' > present in the packet, the true originator that caused the CN's > response. It thus provides traceability. Furthermore, a firewall > filter can be set up to scan for the tag (i.e, the IP address of the > node causing the CN's response) and apply appropriate filtering rules. > Thus, it allows blocking of undesirable packets. > [GM]This firewall where would it be physically and which of the node(s) is it providing these services for and how do you propose that the state necessary to perform the filtering gets installed in the node(s). I have inferred you mean some sort of external firewall to these victim nodes and not a firewall on the hosts themselves where the net gain would be negligable from a processing standpoint; though I am not certain this is what you mean? Firewall the HA, MN, CN, Firewall all nodes, etc..? I am concerned about the route optimisation getting blocked altogether. > We use the following acronyms in this document. > > BC: Binding Cache > BCE: Binding Cache Entry > BR: Binding request > BDT: Bidirectional Tunneling > GN: A Generic IPv6 Node not using Mobile IPv6 > HAO: Home Addess Option > HoA: Home Address > > 2. SOLUTION OVERVIEW > ==================== > > The basic protocol is described by the following; > > 1. Packets arriving with HAO initiate tagging by creating an entry in > the unverified Binding Cache (BC) that the CN maintains. As a > data structure, the unverified BC contains HoA and CoA (i.e., the > sender's IP address). If an entry cannot be created, > e.g., due to finite storage, then the CN sends a Binding > Request (BR) indicating that the MN should use either RO or > Bidirectional Tunneling (BDT). > Is this cache to be a MUST or a SHOULD for all IPv6 nodes? > 2. Packets arriving at the CN's address without HAO but with HoA as > source IP address remove an existing entry. Care must be taken not > to remove an entry when the MN reverse tunnels certain (e.g., > multicast) packets. For this, the following rule would apply. > > if (srcIPaddr == HoA) > if (dstIPaddr != CN's IP addr) > do not remove tag from unverified BCE > [GM]Clarification: What would prevent another node in between the HA and the CN from destroying the entry for a valid MN? - asside1 - not sure if this is an anyworse problem because a TCP reset could have similar affects unless access control lists are used with standard non-mobile nodes? Note-all this recent MIPv6 work seems to be very familiar to the experimental VISA work with an end to end spin that went on in the late 80's. > 3. If packets arrive with erroneous tags, a Home Agent drops those > packets. It may optionally send an ICMP destination unreachable > message in which it includes the correct tag (i.e., the correct CoA > from its BC) that updates the unverified BCE. Meanwhile, any packet > from the genuine MN with an HAO would also correct the CN's > entry. On the other hand, the HA tunnels packets with correct tags > to the MN. > [GM] Clarification: Some may see a malicious cache exhaustion hole unless the HA sends an indication to the CN that the MN is bogus. Of course the CN would still have to store the state for the bogus MN in order to drop it or notify some external trusted firewall to block it on behalf of the CN which is also an exhaustion hole for the firewall. Is this what you meant by firewall? > > 3. UNVERIFIED HAO OPERATION > =========================== > > When it receives a packet with HAO, if there is no entry in > its Binding Cache (BC), the CN inserts the source IP address > (CoA) in a > small cache called unverified BC. When a packet needs to be sent to > HoA, the CN tags the packet with this CoA. This is the basic > idea. There are multiple ways in which the unverified BC can be > implemented. Indeed, it can be part of the normal Mobile IPv6 BC with > an appropriate attribute indicating that the tagged entry is > unverified. So, when the CN scans the BC, it would know exactly which > entry to tag and which one not to tag. It has also been suggested in > the mailing list that the unverified BC could be implemented as an > extension in a node's destination cache. > > The operation when the CN is communicating with a MN is already > described by the above rules. So, we consider the scenario involving a > Generic IPv6 Node (GN). > > Consider the case where an attacker binds any GN's > address to a bogus or genuine CoA. > > a) When there is no on-going traffic between the CN and the GN; > - the CN may send packets to the GN with a tag without the GN > expecting them. The GN's response (TCP Ack, RTCP, etc) would > wipe out the tag. [GM]However, as pointed out earlier, this could certainly be used to disrupt ongoing communications. I.e. an organization could exploit this to make another organizations' resources look flaky and/or of poor quality. I think we have a very recent and vivid example with the mobile IP mail list itself. > - the GN itself may initiate a session to the CN, in which case, > there is no tagging in the CN's response. > - if the GN's site is configured to filter packets containing > the tag, those packets will be dropped. Since the unverified > BCE needs refreshing, the entry will expire unless the > attacker keeps updating the entry. In any case, This is similar > to receiving unsolicited packets in today's Internet. The > presence of the tag however, allows traceability. [GM] Same as above with the caveat that these disruptions and attack scenarios exist in the non-mobile IPv6 with (to a lesser extent) or without (to a greater extent) ingress filtering. > > > b) If there is on-going traffic, the CN would start tagging packets > sometime during the session. > - if tagged packets reach the GN, there is no harm other than the > tag overhead itself; the GN may simply ignore the tag and process > the rest of the packet. Any packet transmission from GN to CN > will force the CN not to tag. [GM] MITM for a short period - same old no worse response. > - if an entity such as a firewall discards packets with the tag, > then the traffic from CN to GN would be ``disrupted''. However, > the tag disappears when the CN receives a packet from GN (without > HAO) or if the lifetime of the tag expires whichever is earlier. > [GM] A firewall where and how would it know to discard, etc.. > Only when the GN is a ``one-way listener'', and the firewall > is configured to discard such packets, is there a possibility > to disrupt the traffic up to a maximum of the lifetime of the > unverified BCE. For this reason, we suggest a relatively short > lifetime. [GM] I can live with this; however, cellular operators probably won't like this unless you build a proxy or something for these updates, etc.. I don't like the idea that a firewall could block route optimized communications from occuring. I suspect the default for these firewalls will be to block it entirely. A completely sucure method with no security holes and that simply can't be blocked by firewalls seems to be a superior solution in that the users could actually be guaranteed the functionality. > > 5. RECOMMENDATION > ================== > > It appears that with the proposed mechanism, the concerns raised > regarding the unverified HAO processing can be effectively > addressed. While the proposed mechanism may not be perfect, it > offers disincentives for an attacker to do harm and provides > sufficient correcting ability for a genuine node so that any potential > disruption can be quickly repaired. > [GM] My first glance appears that it is not much worse than the threats to plain old IPv6 without mobility; however, it served to remind us of the holes that really ought to be plugged first in non-mobile IPv6 before people go off dumping billions into its deployment. I am very pleased to actually see some of this work to fix these holes starting up in other WGs. I am also pleased that at least people have seemed to come to the conclusion that state must be kept at least on the CN to do any form of route optimization. > Recommendation R1 : We recommend that unverified HAO processing be > done according to the rules specified in Section 2. [GM] This seems like quite a large and somewhat complex change to possibly all IPv6 hosts for such a quick decision without interoperability, simulation etc.. Perhaps a more formal ID that is separate from the IPv6 spec should be done first that clarifies many of the points above. I would rather have the group find a solution that has no holes and even allows for route optimization both ways as the state to do it at all is similar. As usual I am always interested in the question about SHOULD and MUST above. Even with a hopeful answer to this, I'm a bit leary of such a change for only half the gain and so late in the game. Thanks, Glenn ------_=_NextPart_001_01C1C561.A9425200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CLARIFICATION: [mobile-ip] Unverified HAO Processing - = Recommendation note

Rajeev, Jari and Charlie,

My initial comments are interspersed. I have not had = time to review all of the other related posts on the list so there may = be duplicate comments/concerns.

          &nb= sp;            =
>          = ;        Unverified HAO = Processing
>
>          = ; Rajeev Koodli, Jari T. Malinen and Charles E. Perkins
>
>
> This note specifies the author'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 the = recommendation 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
>
> The IPv6 specification [1] requires that every = IPv6 node
> process the Mobile IPv6 Home Address Option = (HAO) [2]. In the
> recent analysis of Mobile IPv6, concerns were = raised that such a
> processing without verifying if the sender = actually owned the Home
> Address (HoA) could lead to certain security = vulnerabilities
> [3]. As a consequence, the unverified use of = HAO has
> not been recommended in the design team = recommendation. In this
> document, we describe a mechanism that allows a = CN to process
> unverified HAO as it is currently specified = using some implementation
> extensions.
>
> There are two concerns regarding the unverified = use of HAO. First, any
> node (attacker) may use a CN as a reflector to = send packets to one or
> more victims without being traced, since the = CN's response is sent to
> the HoA with the CN's IP address as the source = IP address. This is the
> traceability problem. As a matter of = comparison, if a such a DoS
> attack were to happen today, the source IP = address in the unsolicited
> packet would be the (typically spoofed) IP = address of the
> sender. Second, as a response to prevent such = attacks, source ingress
> filtering is used to block certain packets. = With HAO, such a mechanism
> cannot readily be used. The solution proposed = here requires a CN to
> include the source IP address of the packet in = a response message from
> the CN. This allows the owner of the HoA to = determine, from
> the ``tag''
> present in the packet, the true originator that = caused the CN's
> response. It thus provides traceability. = Furthermore, a firewall
> filter can be set up to scan for the tag (i.e, = the IP address of the
> node causing the CN's response) and apply = appropriate filtering rules.
> Thus, it allows blocking of undesirable = packets.
>

[GM]This firewall where would it be physically and = which of the node(s) is it providing these services for and how do you = propose that the state necessary to perform the filtering gets = installed in the node(s). I have inferred you mean some sort of = external firewall to these victim nodes and not a firewall on the hosts = themselves where the net gain would be negligable from a processing = standpoint; though I am not certain this is what you mean? Firewall the = HA, MN, CN, Firewall all nodes, etc..? I am concerned about the route = optimisation getting blocked altogether.

> We use the following acronyms in this = document.
>
> BC: Binding Cache
> BCE: Binding Cache Entry
> BR: Binding request
> BDT: Bidirectional Tunneling
> GN: A Generic IPv6 Node not using Mobile = IPv6
> HAO: Home Addess Option
> HoA: Home Address
>
> 2. SOLUTION OVERVIEW
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> The basic protocol is described by the = following;
>
> 1. Packets arriving with HAO initiate tagging = by creating an entry in
>    the unverified Binding Cache = (BC) that the CN maintains. As a
>    data structure, the = unverified BC contains HoA and CoA (i.e., the
>    sender's IP address). If an = entry cannot be created,
>    e.g., due to finite storage, = then the CN sends a Binding
>    Request (BR) indicating that = the MN should use either RO or
>    Bidirectional Tunneling = (BDT).
>

Is this cache to be a MUST or a SHOULD for all IPv6 = nodes?

> 2. Packets arriving at the CN's address without = HAO but with HoA as
>    source IP address remove an = existing entry. Care must be taken not
>    to remove an entry when the = MN reverse tunnels certain (e.g.,
>    multicast) packets. For this, = the following rule would apply.
>
>          = ;   if (srcIPaddr =3D=3D HoA)
>          = ;      if (dstIPaddr !=3D CN's IP addr)
>          = ;         do not remove tag = from unverified BCE
>

[GM]Clarification:
What would prevent another node in between the HA = and the CN from destroying the entry for a valid MN? - asside1 - not = sure if this is an anyworse problem because a TCP reset could have = similar affects unless access control lists are used with standard = non-mobile nodes? Note-all this recent MIPv6 work seems to be very = familiar to the experimental VISA work with an end to end spin that = went on in the late 80's.


> 3. If packets arrive with erroneous tags, a Home = Agent drops those
>    packets. It may optionally = send an ICMP destination unreachable
>    message in which it includes = the correct tag (i.e., the correct CoA
>    from its BC) that updates the = unverified BCE. Meanwhile, any packet
>    from the genuine MN with an = HAO would also correct the CN's
>    entry. On the other hand, the = HA tunnels packets with correct tags
>    to the MN.
>

[GM] Clarification: Some may see a malicious cache = exhaustion hole unless the HA sends an indication to the CN that the MN = is bogus. Of course the CN would still have to store the state for the = bogus MN in order to drop it or notify some external trusted firewall = to block it on behalf of the CN which is also an exhaustion hole for = the firewall. Is this what you meant by firewall?

>
> 3. UNVERIFIED HAO OPERATION
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> When it receives a packet with HAO, if there is = no entry in
> its Binding Cache (BC), the CN inserts the = source IP address
> (CoA) in a
> small cache called unverified BC. When a packet = needs to be sent to
> HoA, the CN tags the packet with this CoA. This = is the basic
> idea. There are multiple ways in which the = unverified BC can be
> implemented. Indeed, it can be part of the = normal Mobile IPv6 BC with
> an appropriate attribute indicating that the = tagged entry is
> unverified. So, when the CN scans the BC, it = would know exactly which
> entry to tag and which one not to tag. It has = also been suggested in
> the mailing list that the unverified BC could = be implemented as an
> extension in a node's destination cache.
>
> The operation when the CN is communicating with = a MN is already
> described by the above rules. So, we consider = the scenario involving a
> Generic IPv6 Node (GN).
>
> Consider the case where an attacker binds any = GN's
> address to a bogus or genuine CoA.
>
> a) When there is no on-going traffic between = the CN and the GN;
>    - the CN may send packets to = the GN with a tag without the GN
>      expecting them. = The GN's response (TCP Ack, RTCP, etc) would
>      wipe out the tag. =

[GM]However, as pointed out earlier, this could = certainly be used to disrupt ongoing communications. I.e. an = organization could exploit this to make another organizations' = resources look flaky and/or of poor quality. I think we have a very = recent and vivid example with the mobile IP mail list = itself.

>    - the GN itself may initiate a = session to the CN, in which case,
>      there is no = tagging in the CN's response.
>    - if the GN's site is = configured to filter packets containing
>      the tag, those = packets will be dropped. Since the unverified
>      BCE needs = refreshing, the entry will expire unless the
>      attacker keeps = updating the entry. In any case, This is similar
>      to receiving = unsolicited packets in today's Internet. The
>      presence of the = tag however, allows traceability.

[GM] Same as above with the caveat that these = disruptions and attack scenarios exist in the non-mobile IPv6 with (to = a lesser extent) or without (to a greater extent) ingress filtering. =

>
>
> b) If there is on-going traffic, the CN would = start tagging packets
> sometime during the session.
>    - if tagged packets reach the = GN, there is no harm other than the
>      tag overhead = itself; the GN may simply ignore the tag and process
>      the rest of the = packet. Any packet transmission from GN to CN
>      will force the CN = not to tag.

[GM] MITM for a short period - same old no worse = response.

>   - if an entity such as a firewall = discards packets with the tag,
>      then the traffic = from CN to GN would be ``disrupted''. However,
>      the tag = disappears when the CN receives a packet from GN (without
>      HAO) or if the = lifetime of the tag expires whichever is earlier.
>     

[GM] A firewall where and how would it know to = discard, etc..

>      Only when the GN = is a ``one-way listener'', and the firewall
>      is configured to = discard such packets, is there a possibility
>      to disrupt the = traffic up to a maximum of the lifetime of the
>      unverified = BCE.  For this reason, we suggest a relatively short
>      lifetime.

[GM] I can live with this; however, cellular = operators probably won't like this unless you build a proxy or = something for these updates, etc.. I don't like the idea that a = firewall could block route optimized communications from occuring. I = suspect the default for these firewalls will be to block it entirely. A = completely sucure method with no security holes and that simply can't = be blocked by firewalls seems to be a superior solution in that the = users could actually be guaranteed the functionality.


>
> 5. RECOMMENDATION
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> It appears that with the proposed mechanism, = the concerns raised
> regarding the unverified HAO processing can be = effectively
> addressed. While the proposed mechanism may not = be perfect, it
> offers disincentives for an attacker to do harm = and provides
> sufficient correcting ability for a genuine = node so that any potential
> disruption can be quickly repaired.
>

[GM] My first glance appears that it is not much = worse than the threats to plain old IPv6 without mobility; however, it = served to remind us of the holes that really ought to be plugged first = in non-mobile IPv6 before people go off dumping billions into its = deployment. I am very pleased to actually see some of this work to fix = these holes starting up in other WGs. I am also pleased that at least = people have seemed to come to the conclusion that state must be kept at = least on the CN to do any form of route optimization.

 
> Recommendation R1 : We recommend that = unverified HAO processing be
> done according to the rules specified in = Section 2.

[GM] This seems like quite a large and somewhat = complex change to possibly all IPv6 hosts for such a quick decision = without interoperability, simulation etc.. Perhaps a more formal ID = that is separate from the IPv6 spec should be done first that clarifies = many of the points above. I would rather have the group find a solution = that has no holes and even allows for route optimization both ways as = the state to do it at all is similar. As usual I am always interested = in the question about SHOULD and MUST above. Even with a hopeful answer = to this, I'm a bit leary of such a change for only half the gain and so = late in the game.

Thanks,

Glenn

------_=_NextPart_001_01C1C561.A9425200-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 22:21: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 WAA25222 for ; Wed, 6 Mar 2002 22:21: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 TAA22303; Wed, 6 Mar 2002 19:21:27 -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 TAA06624; Wed, 6 Mar 2002 19:21: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 g273KNKL006773 for ; Wed, 6 Mar 2002 19:20:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g273KNw9006772 for mobile-ip-dist; Wed, 6 Mar 2002 19:20: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 g273KKKL006765 for ; Wed, 6 Mar 2002 19:20:20 -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 TAA06299 for ; Wed, 6 Mar 2002 19:20:20 -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 TAA03703 for ; Wed, 6 Mar 2002 19:20:20 -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 TAA23724 for ; Wed, 6 Mar 2002 19:20:20 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g273KJj21848 for ; Wed, 6 Mar 2002 19:20:19 -0800 X-mProtect:  Wed, 6 Mar 2002 19:20:19 -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 smtpdGxCwOO; Wed, 06 Mar 2002 19:20:16 PST Message-ID: <3C86DC71.E7048501@iprg.nokia.com> Date: Wed, 06 Mar 2002 19:20:17 -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: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommendation note References: <933FADF5E673D411B8A30002A5608A0E0273A09E@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 Hello Glenn, thank you for reading the document and providing your comments. I will try to answer your concerns below. Regards, -Rajeev Glenn Morrow wrote: > > > > present in the packet, the true originator that caused the CN's > > response. It thus provides traceability. Furthermore, a firewall > > filter can be set up to scan for the tag (i.e, the IP address of the > > > node causing the CN's response) and apply appropriate filtering > rules. > > Thus, it allows blocking of undesirable packets. > > > > [GM]This firewall where would it be physically and which of the > node(s) is it providing these services for and how do you propose that > the state necessary to perform the filtering gets installed in the > node(s). I have inferred you mean some sort of external firewall to > these victim nodes and not a firewall on the hosts themselves where > the net gain would be negligable from a processing standpoint; though > I am not certain this is what you mean? Firewall the HA, MN, CN, > Firewall all nodes, etc..? I am concerned about the route optimisation > getting blocked altogether. > Our document does not propose there be firewalls, much less indicate where they need to be. IF there is a firewall protecting a node, then such a firewall may drop the tagged packets. I am not sure I understand your concern regarding RO packets being blocked. I don't see how they will be blocked. On the other hand, a tag may follow the same format as RO packet (RH type 2). Is that your concern ? I would support using the same format, but I agree that a firewall must not drop packets insensitively. > Is this cache to be a MUST or a SHOULD for all IPv6 nodes? Tagging is MUST. Since it could be implemented differently, the unverified BC is a SHOULD. > > > > 2. Packets arriving at the CN's address without HAO but with HoA as > > source IP address remove an existing entry. Care must be taken > not > > to remove an entry when the MN reverse tunnels certain (e.g., > > multicast) packets. For this, the following rule would apply. > > > > if (srcIPaddr == HoA) > > if (dstIPaddr != CN's IP addr) > > do not remove tag from unverified BCE > > > > [GM]Clarification: > What would prevent another node in between the HA and the CN from > destroying the entry for a valid MN? - asside1 - not sure if this is > an anyworse In fact some _could_ overwrite it. If it does, it's IP address is seen in the response packet from the CN and hence could be traced. Also, a packet from MN with HAO would correct it back. > problem because a TCP reset could have similar affects unless access > control lists are used with standard non-mobile nodes? Note-all this > recent MIPv6 work seems to be very familiar to the experimental VISA > work with an end to end spin that went on in the late 80's. > I an not familiar with the VISA story. Perhaps you could explain that to me another time :-) > > > 3. If packets arrive with erroneous tags, a Home Agent drops those > > packets. It may optionally send an ICMP destination unreachable > > message in which it includes the correct tag (i.e., the correct > CoA > > from its BC) that updates the unverified BCE. Meanwhile, any > packet > > from the genuine MN with an HAO would also correct the CN's > > entry. On the other hand, the HA tunnels packets with correct > tags > > to the MN. > > > > [GM] Clarification: Some may see a malicious cache exhaustion hole > unless the HA sends an indication to the CN that the MN is bogus. Of > course the CN would still have to store the state for the bogus MN in > order to drop it or notify some external trusted firewall to block it > on behalf of the CN which is also an exhaustion hole for the firewall. > Is this what you meant by firewall? > I see you have interpreted the proposal differently. The CN only maintains the mapping from HoA to CoA. And, the CoA could be malicious node's IP address. If a malicious node fills the available space with multiple HoA's all mapped to the same CoA (which BTW itself is a red flag), - any packets from the rightful owners of those HoAs would replace the tags - tags themselves timeout unless there is traffic - the CN's firewall could set up a filter for the bad CoA. Does this answer your concern ? > > > > > a) When there is no on-going traffic between the CN and the GN; > > - the CN may send packets to the GN with a tag without the GN > > expecting them. The GN's response (TCP Ack, RTCP, etc) would > > wipe out the tag. > > [GM]However, as pointed out earlier, this could certainly be used to > disrupt ongoing communications. I.e. an organization could exploit > this to make another organizations' resources look flaky and/or of > poor quality. I think we have a very recent and vivid example with the > mobile IP mail list itself. > Two things can happen right ? - packets with tag make it to the GN, which responds back. The tag disappears - GN's firewall drops packets with tags. This might be a good thing if the traffic is unsolicited. If it was good traffic, then any packet from GN would remove the tag or the CN times out the tag. Once in no-tagging state, the CN stays there for a long time. > > > - the GN itself may initiate a session to the CN, in which case, > > there is no tagging in the CN's response. > > - if the GN's site is configured to filter packets containing > > the tag, those packets will be dropped. Since the unverified > > BCE needs refreshing, the entry will expire unless the > > attacker keeps updating the entry. In any case, This is similar > > > to receiving unsolicited packets in today's Internet. The > > presence of the tag however, allows traceability. > > [GM] Same as above with the caveat that these disruptions and attack > scenarios exist in the non-mobile IPv6 with (to a lesser extent) or > without (to a greater extent) ingress filtering. > See above. Good you point that some of the issues persist. We are trying to stick with do no harm. > > > > > > > b) If there is on-going traffic, the CN would start tagging packets > > sometime during the session. > > - if tagged packets reach the GN, there is no harm other than the > > > tag overhead itself; the GN may simply ignore the tag and > process > > the rest of the packet. Any packet transmission from GN to CN > > will force the CN not to tag. > > [GM] MITM for a short period - same old no worse response. > > > - if an entity such as a firewall discards packets with the tag, > > then the traffic from CN to GN would be ``disrupted''. However, > > > the tag disappears when the CN receives a packet from GN > (without > > HAO) or if the lifetime of the tag expires whichever is > earlier. > > > > [GM] A firewall where and how would it know to discard, etc.. > This would be the GN's firewall. As I mentioned earlier, we do not specify the firewall operation. We only allow for a firewall to use tags to filter. > > > Only when the GN is a ``one-way listener'', and the firewall > > is configured to discard such packets, is there a possibility > > to disrupt the traffic up to a maximum of the lifetime of the > > unverified BCE. For this reason, we suggest a relatively short > > > lifetime. > > [GM] I can live with this; however, cellular operators probably won't > like this unless you build a proxy or something for these updates, > etc.. I don't like the idea that a firewall could block route > optimized communications from occuring. I suspect the default for > these firewalls will be to block it entirely. A completely sucure > method with no security holes and that simply can't be blocked by > firewalls seems to be a superior solution in that the users could > actually be guaranteed the functionality. > Certainly we are not proposing to block RO packets. We are also not proposing that the firewall block tagged packets. The text regarding the firewall is there to illustrate the operation _if_ a firewall blocked tagged packets. > > > > > 5. RECOMMENDATION > > ================== > > > > It appears that with the proposed mechanism, the concerns raised > > regarding the unverified HAO processing can be effectively > > addressed. While the proposed mechanism may not be perfect, it > > offers disincentives for an attacker to do harm and provides > > sufficient correcting ability for a genuine node so that any > potential > > disruption can be quickly repaired. > > > > [GM] My first glance appears that it is not much worse than the > threats to plain old IPv6 without mobility; however, it served to > remind us of the holes that really ought to be plugged first in > non-mobile IPv6 before people go off dumping billions into its > deployment. I am very pleased to actually see some of this work to fix > these holes starting up in other WGs. I am also pleased that at least > people have seemed to come to the conclusion that state must be kept > at least on the CN to do any form of route optimization. > > ok. > > > Recommendation R1 : We recommend that unverified HAO processing be > > done according to the rules specified in Section 2. > > [GM] This seems like quite a large and somewhat complex change to > possibly all IPv6 hosts for such a quick decision without > interoperability, simulation etc.. Perhaps a more formal ID that is > separate from the IPv6 spec should be done first that clarifies many > of the points above. I would rather have the group find a solution > that has no holes and even allows for route optimization both ways as > the state to do it at all is similar. As usual I am always interested > in the question about SHOULD and MUST above. Even with a hopeful > answer to this, I'm a bit leary of such a change for only half the > gain and so late in the game. > Let me try to clarify few things. - the requirement (i.e., MUST) is that tagging be specified for CNs while processing unverified HAO. As a matter of comparison, a CN includes HoA in a routing header when verified BC exists. - there can be multiple implementations supporting the above requirement. Each requirement however has to ensure that every tag is represented in at least one outgoing packet from the CN. This is to ensure that no tag is overwritten and hence not traced. - what we have described in the document is one implementation. It has been recently termed as "best-effort" tagging and I personally don't mind the name. Since there is considerable detail, I can understand your overall characterization of the proposal as complex. I do hope that you draw the distinction between the policy (i.e., tagging) and the mechanism (i.e, BE tagging described in the document), and draw a different conclusion on tagging itself as a proposal. In our proposal, we have attempted to provide traceability and the possibility to do filtering (most likely at the CN's domain to weed out attacker's packets traced via the tag). I may not have seen the holes apparent to you. So, please explain any while keeping in mind that we are trying to stick with do no harm (i.e., not raise the bar). > > Thanks, > > Glenn From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 6 23:13: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 XAA28641 for ; Wed, 6 Mar 2002 23:13:04 -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 UAA28043; Wed, 6 Mar 2002 20:13: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 UAA03648; Wed, 6 Mar 2002 20:12: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 g274CBKL006856 for ; Wed, 6 Mar 2002 20:12:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g274CBgA006855 for mobile-ip-dist; Wed, 6 Mar 2002 20:12: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 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 g274C9KL006848 for ; Wed, 6 Mar 2002 20:12:10 -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 XAA06652 for ; Wed, 6 Mar 2002 23:12:10 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id XAA10678 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Mar 2002 23:13:02 -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 g26M5IKL006165 for ; Wed, 6 Mar 2002 14:05:18 -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 OAA09994 for ; Wed, 6 Mar 2002 14:05:17 -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 PAA02819 for ; Wed, 6 Mar 2002 15:05:17 -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 g26M5FW23706 for ; Wed, 6 Mar 2002 16:05:15 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 16:05:15 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A034B4354@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Drafts on MIP extensions to support DNS Date: Wed, 6 Mar 2002 16:05:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C55A.FEE3E040" Sender: owner-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_01C1C55A.FEE3E040 Content-Type: text/plain; charset="iso-8859-1" Hello, We have recently submitted two new drafts, http://search.ietf.org/internet-drafts/draft-bharatia-mobileip-v4-dns-ext-00 .txt and http://search.ietf.org/internet-drafts/draft-bharatia-mobileip-v6-dns-ext-00 .txt These drafts define MIP RRP extensions to support transfer of DNS addresses assigned by HA to the MN. This work is resulted from the original requirements in 3GPP2 where DNS addresses are currently transferred to MN using IPCP, which is basically a link layer specific solution. The attached emails determine previous Mobile IP mailing list discussion where the need of doing this work in separate (other than RFC3220) draft was identified. The mechanism we have offered in these two drafts is link layer independent solution. Your comments on these drafts are appreciated. Thanks, Jayshree -----Original Message----- From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] Sent: Thursday, October 04, 2001 8:02 PM To: Chowdhury, Kuntal [RICH2:2H18:EXCH] Subject: Re: MIP extensions to support DNS Hello Kuntal, I do not think this is possible. I think it would be quite possible to make a separate draft for this extension, though. And, it seems to me to more appropriate anyway than trying to add it to RFC2002bis, since the latter document wasn't supposed to have new features (despite appearances to the contrary). Regards, Charlie P. Kuntal Chowdhury wrote: Charlie, I was wondering if we still have time to add MIP extensions in 2002bis so that DNS server addresses can be returned by the home network? We discussed this issue in 3GPP2 and there was a requirement for this feature. Currently DNS server addresses are negotiated by MN with PDSN/FA during IPCP phase (RFC 1877), however there is no way to assign these DNS servers in the home network. It would be nice if HA has option to send these DNS addresses in the RRP message. I can help in writing up the text for this, if you think it's still possible to add this feature in the draft. Please let me know. Thanks and best regards, Kuntal ------_=_NextPart_001_01C1C55A.FEE3E040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
We = have recently=20 submitted two new drafts, http://search.ietf.org/internet-drafts/draft-bharatia-= mobileip-v4-dns-ext-00.txt and=20 http://search.ietf.org/internet-drafts/draft-bharatia-= mobileip-v6-dns-ext-00.txt
 
These = drafts define=20 MIP RRP extensions to support transfer of DNS addresses assigned by HA = to the=20 MN. This work is resulted from the original requirements in 3GPP2 where = DNS=20 addresses are currently transferred to MN using IPCP, which is = basically a link=20 layer specific solution. The attached emails determine previous Mobile = IP=20 mailing list discussion where the need of doing this work in separate = (other=20 than RFC3220) draft was identified.
 
The = mechanism we=20 have offered in these two drafts is link layer independent=20 solution.
 
Your = comments on=20 these drafts are appreciated.
 
Thanks,
Jayshree
-----Original Message-----
From: Charlie Perkins=20 [mailto:charliep@IPRG.nokia.com]
Sent: Thursday, October = 04, 2001=20 8:02 PM
To: Chowdhury, Kuntal = [RICH2:2H18:EXCH]
Subject:=20 Re: MIP extensions to support DNS

  =
Hello Kuntal,=20

I do not think this is possible.  I think it would be quite = possible=20
to make a separate draft for this extension, though.  And, = it seems=20
to me to more appropriate anyway than trying to add it to = RFC2002bis,=20
since the latter document wasn't supposed to have new features=20
(despite appearances to the contrary).=20

Regards,
Charlie P.
 =20

Kuntal Chowdhury wrote:=20

 =20

Charlie, =
I was wondering if we still have time = to add MIP=20 extensions in 2002bis so that DNS server addresses can be returned = by the=20 home network? We discussed this issue in 3GPP2 and there was a = requirement=20 for this feature. Currently DNS server addresses are negotiated by = MN with=20 PDSN/FA during IPCP phase (RFC 1877), however there is no way to = assign=20 these DNS servers in the home network. It would be nice if HA has = option to=20 send these DNS addresses in the RRP message.=20

I can help in writing up the = text for=20 this, if you think it's still possible to add this feature in the=20 draft.=20

Please let me = know.=20

Thanks and best = regards,=20
Kuntal

------_=_NextPart_001_01C1C55A.FEE3E040-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 01:15: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 BAA02735 for ; Thu, 7 Mar 2002 01:15:10 -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 XAA26331; Wed, 6 Mar 2002 23:15: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 WAA27066; Wed, 6 Mar 2002 22:14: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 g276EAKL007209 for ; Wed, 6 Mar 2002 22:14:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g276EA0u007208 for mobile-ip-dist; Wed, 6 Mar 2002 22:14: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 g276E6KL007201 for ; Wed, 6 Mar 2002 22:14: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 WAA26927 for ; Wed, 6 Mar 2002 22:14:06 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA18100 for ; Wed, 6 Mar 2002 23:14:05 -0700 (MST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5B90F5B5E for ; Thu, 7 Mar 2002 01:14:05 -0500 (EST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 23B6317FD for ; Thu, 7 Mar 2002 01:14:05 -0500 (EST) Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id BAA0001763510; Thu, 7 Mar 2002 01:14:04 -0500 (EST) Message-ID: <3C870502.D442C0B0@compaq.com> Date: Thu, 07 Mar 2002 01:13:22 -0500 From: Brian Haley Organization: Tru64 UNIX Base OS Networks X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Drafts on MIP extensions to support DNS References: <1B54FA3A2709D51195C800508BF9386A034B4354@zrc2c000.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 "Jayshree Bharatia" wrote: > We have recently submitted two new drafts, >http://search.ietf.org/internet-drafts/draft-bharatia-mobileip-v4-dns-ext-00.txt and > http://search.ietf.org/internet-drafts/draft-bharatia-mobileip-v6-dns-ext-00.txt Hi Jayshree, Thanks for writing this up, I have a couple of comments on the v6 draft. > 1.1 Glossary of Terms > > FA Foreign Agent You can remove FA from the v6 draft. > Step 2: The MN sends a Binding Update message to the HA. It is > recommended that the MN should set `A' bit in the Binding > Update message requesting the Binding Acknowledgement from > the HA. Don't know if it matters, but the HA must always return an Ack to the MN, regardless of the A bit (section 9.1, page 69 of mipv6 draft 15). > The Mobile IP Sub-Optionsfor primary and secondary DNS servers shall > have the following format I think this sub-option requires alignment, like the HAO or alt-COA in mipv6: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DNS Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Don't know if the v4 one has the same requirement. And just another comment. Would it be useful to have this a variable number of addresses instead of fixed at two? The length would tell you how many there were, similar to the ICMP Home Agent Address Discovery Reply Message in section 5.8 of mipv6. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 06:21: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 GAA17100 for ; Thu, 7 Mar 2002 06:21: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 EAA02356; Thu, 7 Mar 2002 04:21: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 DAA27311; Thu, 7 Mar 2002 03:21: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 g27BKVKL007888 for ; Thu, 7 Mar 2002 03:20:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27BKUTb007887 for mobile-ip-dist; Thu, 7 Mar 2002 03:20: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 g27BKRKL007880 for ; Thu, 7 Mar 2002 03:20: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 DAA27069 for ; Thu, 7 Mar 2002 03:20:26 -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 EAA02007 for ; Thu, 7 Mar 2002 04:20:26 -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 GAA16917; Thu, 7 Mar 2002 06:20:20 -0500 (EST) Message-Id: <200203071120.GAA16917@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-reg-revok-02.txt Date: Thu, 07 Mar 2002 06:20: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. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Registration Revocation in Mobile IP Author(s) : S. Glass, M. Chandra Filename : draft-ietf-mobileip-reg-revok-02.txt Pages : 31 Date : 06-Mar-02 During the original design of Mobile IP, the need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that instead of an active revocation mechanism explicitly for the purpose of registration revocation, a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registrations from a mobile node, would likely be sufficient for this purpose. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-revok-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-reg-revok-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-reg-revok-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: <20020306142123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-reg-revok-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-reg-revok-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020306142123.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 07:58:28 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 HAA21311 for ; Thu, 7 Mar 2002 07:58:28 -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 FAA06131; Thu, 7 Mar 2002 05:58: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 EAA23209; Thu, 7 Mar 2002 04:58: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 g27CvcKL008164 for ; Thu, 7 Mar 2002 04:57:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Cvc2H008163 for mobile-ip-dist; Thu, 7 Mar 2002 04:57: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 g27CvYKL008156 for ; Thu, 7 Mar 2002 04:57: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 EAA07778 for ; Thu, 7 Mar 2002 04:57:35 -0800 (PST) Received: from kings.mei.co.jp (kings.mei.co.jp [202.224.189.27]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16357 for ; Thu, 7 Mar 2002 05:57:34 -0700 (MST) Received: by kings.mei.co.jp (8.11.6/3.7W/kings) with ESMTP id g27CvVp15829 for ; Thu, 7 Mar 2002 21:57:31 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id g27CvWS12950 for ; Thu, 7 Mar 2002 21:57:32 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:01122508) id g27CvWL28672; Thu, 7 Mar 2002 21:57:32 +0900 (JST) Received: from mobilemaster1.mtc.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id g27Cv7L07168 for ; Thu, 7 Mar 2002 21:57:07 +0900 (JST) Received: from iida-machin by mobilemaster1.mtc.mci.mei.co.jp (8.11.6/3.7W-MTC) with ESMTP id g27CvUR15796 for ; Thu, 7 Mar 2002 21:57:30 +0900 (JST) Message-Id: <4.2.0.58.J.20020307214307.00c1eac0@mail.mtc.mci.mei.co.jp> X-Sender: kiida@mail.mtc.mci.mei.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 07 Mar 2002 21:54:29 +0900 To: mobile-ip@sunroof.eng.sun.com From: Kenichiro Iida Subject: [mobile-ip] question on the location of MN functions In-Reply-To: <3C8681D6.4EEF14EF@iprg.nokia.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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. I read Mobile IPv6 I-D. I have a question about Mobile IPv6. In Mobile IPv6 Protocol, MN has the functions of forming CoA and sending BU. I think, If AR(Access Router) can have these functions, there will be the following advantages. (1) AR can form MN's new CoA and perform DAD before Handover. (2) The delay to register with HA and CN is reduced, because the delay between AR and MN is eliminated. In case that the link between AR and MN is wireless, e.g. WCDMA, its transmission delay will be about several ten msec( 40-50msec ). If AR sends BU, this transmission delay is eliminated. Are there any problems on this idea? Could you give me any comments? Best regards, K.Iida ********************************************** $BHSED!!7r0lO:!!(B(Kenichiro Iida) $B>>2; Thu, 7 Mar 2002 08:11:04 -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 GAA10636; Thu, 7 Mar 2002 06:11: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 FAA26566; Thu, 7 Mar 2002 05:10: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 g27DA9KL008311 for ; Thu, 7 Mar 2002 05:10:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DA9xM008310 for mobile-ip-dist; Thu, 7 Mar 2002 05:10: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 g27DA6KL008303 for ; Thu, 7 Mar 2002 05:10:06 -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 FAA24431 for ; Thu, 7 Mar 2002 05:10:07 -0800 (PST) Received: from kings.mei.co.jp (kings.mei.co.jp [202.224.189.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03697 for ; Thu, 7 Mar 2002 05:10:06 -0800 (PST) Received: by kings.mei.co.jp (8.11.6/3.7W/kings) with ESMTP id g27DA3p23314 for ; Thu, 7 Mar 2002 22:10:03 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id g27DA4S21916 for ; Thu, 7 Mar 2002 22:10:04 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:01122508) id g27DA4L01462; Thu, 7 Mar 2002 22:10:04 +0900 (JST) Received: from mobilemaster1.mtc.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id g27D9ej07752 for ; Thu, 7 Mar 2002 22:09:40 +0900 (JST) Received: from iida-machin by mobilemaster1.mtc.mci.mei.co.jp (8.11.6/3.7W-MTC) with ESMTP id g27DA3R16695 for ; Thu, 7 Mar 2002 22:10:03 +0900 (JST) Message-Id: <4.2.0.58.J.20020307220444.00c18b00@mail.mtc.mci.mei.co.jp> X-Sender: kiida@mail.mtc.mci.mei.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 07 Mar 2002 22:06:45 +0900 To: mobile-ip@sunroof.eng.sun.com From: Kenichiro Iida Subject: [mobile-ip] question on the location of MN functions 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. I read Mobile IPv6 I-D. I have a question about Mobile IPv6. In Mobile IPv6 Protocol, MN has the functions of forming CoA and sending BU. I think, If AR(Access Router) can have these functions, there will be the following advantages. (1) AR can form MN's new CoA and perform DAD before Handover. (2) The delay to register with HA and CN is reduced, because the delay between AR and MN is eliminated. In case that the link between AR and MN is wireless, e.g. WCDMA, its transmission delay will be about several ten msec( 40-50msec ). If AR sends BU, this transmission delay is eliminated. Are there any problems on this idea? Could you give me any comments? Best regards, K.Iida From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 10:34:12 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 KAA00556 for ; Thu, 7 Mar 2002 10:34: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 IAA17165; Thu, 7 Mar 2002 08:34:12 -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 HAA25906; Thu, 7 Mar 2002 07:34: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 g27FXHKL008861 for ; Thu, 7 Mar 2002 07:33:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FXHCH008860 for mobile-ip-dist; Thu, 7 Mar 2002 07: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 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 g27FXDKL008853 for ; Thu, 7 Mar 2002 07:33:13 -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 g27FXAx12655; Thu, 7 Mar 2002 16:33:10 +0100 (MET) Date: Thu, 7 Mar 2002 16:28:06 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, Rajeev Koodli In-Reply-To: "Your message with ID" <3C8681D6.4EEF14EF@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 was referring to Erik's observation that, given Rajeev's > state-based "best-effort" tagging proposal, packet reordering > at the CN could cause packets to be sent out with the "wrong" > tag. The malicious care-of address would still be observable, > albeit in a different packet. But this would be a very rare > occurrence. Charlie, there was no reordering in my examples. There was just multiple concurrent "streams" of packets arriving at the CN - one stream being sent by the CN and one stream being sent by the attacker. As such there is no assumption about the network reordering packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 10:38: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 KAA00883 for ; Thu, 7 Mar 2002 10:38:00 -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 HAA12529; Thu, 7 Mar 2002 07:38:00 -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 HAA12114; Thu, 7 Mar 2002 07:37: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 g27FbDKL008925 for ; Thu, 7 Mar 2002 07:37:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FbDqP008924 for mobile-ip-dist; Thu, 7 Mar 2002 07: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 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 g27Fb8KL008917 for ; Thu, 7 Mar 2002 07:37:09 -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 g27Fb3x13014; Thu, 7 Mar 2002 16:37:03 +0100 (MET) Date: Thu, 7 Mar 2002 16:31:59 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Rajeev Koodli 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 be completely honest, I do not have data to determine > whether the vulnerability is completely negligible, or > only very, very small. I think that one could guesstimate > the likelihood of the occurrences that you described, based > on IP reordering pprobabilities, and it surely is a tiny > probability. We have already designed ingress filtering > techniques that almost completely eliminate any lingering > abilities for attackers to mount this highly improbable attack. Charlie, Are you talking about the ideas about "smart" ingress filtering or something else here? As I hope I showed with my examples today's ingress filtering before the CN can't do anything since it will just inspect the IP source address which the attacker does not need to spoof. And filtering after the CN can't tell the difference between the good and bad packets since the tags assigned to the packets can be quite random when the CN receives multiple HAO values for the same HoA. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 10:48: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 KAA01573 for ; Thu, 7 Mar 2002 10:48:41 -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 IAA25219; Thu, 7 Mar 2002 08:48: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 HAA13892; Thu, 7 Mar 2002 07:48: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 g27FleKL009025 for ; Thu, 7 Mar 2002 07:47:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FleZ9009024 for mobile-ip-dist; Thu, 7 Mar 2002 07:47: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 g27FlZKL009017 for ; Thu, 7 Mar 2002 07:47:36 -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 g27FlUx14511; Thu, 7 Mar 2002 16:47:30 +0100 (MET) Date: Thu, 7 Mar 2002 16:42:26 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Rajeev Koodli In-Reply-To: "Your message with ID" <3C867946.B4B34215@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: Charlie, Some comments on the claimed benefits. > Unverified HAO allowable Unverified HAO prohibited > > - Robust to cache entry If CN times out or loses a Binding > timeout and reclamation Cache entry, MN traffic is blackholed You seem to be forgetting that the unvHAO (just like the binding cache) will be of finite size. If you take that into account you'll see that the unvHAO is actually less robust because a MN will send unvHAO which will be dropped during normal operation. Some error can be sent to the MN is this case but that is after the packets have been lost. I think an attacker can easily fill the unvHAO cache with garbage since there is no verification of the information that goes in there. Thus an attacker can send src=X HoA=::1 dst=cnn.com and increase "1" until the unvHAO is filled. Also, on the right you claim that timing out a BCE will cause packet loss which isn't true. The MN knows the binding lifetime it its binding update list which tell the MN for how long time it can continue to send HAOs. The only case the strict HAO verification will drop packets (and send an error to inform the MN) is when it has had a fatal loss of state (i.e. crashed and rebooted). This is normally a rather rare event and when it happens it will disrupt the actual data traffic (TCP, RTP state being lost as well at the CN). This is quite different than dropping packets during normal operation when the unvHAO cache is full - whether due to high load or due to attacks. > - Fast response to packets Delays for either reverse tunneling > initiated by MN or Binding Cache Entry establishment. > Worse if CN implements ONLY RR. What is the delay? A MN which cares about performance presumably starts the data traffic using reverse tunneling while the 1.5 roundtrips of RR+BU are in effect. When it gets the BAck it can then switch to fully optimized path in both directions. > - "Do No Harm" satisfied Reverse tunneling and black-holing > is a "harm" We've talked about "do no harm" in the context of security. You don't seem to be talking about security here so am I a bit confused. > - Vulnerability == "way_small" Vulnerability == 0. "way_small" > "do no harm"? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 10:59: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 KAA02393 for ; Thu, 7 Mar 2002 10:59:01 -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 HAA18622; Thu, 7 Mar 2002 07:59:00 -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 HAA15792; Thu, 7 Mar 2002 07:58: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 g27FvrKL009086 for ; Thu, 7 Mar 2002 07:57:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Fvrjo009085 for mobile-ip-dist; Thu, 7 Mar 2002 07:57: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 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 g27FvnKL009078 for ; Thu, 7 Mar 2002 07:57:50 -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 g27Fvlx15859; Thu, 7 Mar 2002 16:57:47 +0100 (MET) Date: Thu, 7 Mar 2002 16:52:43 +0100 (CET) From: Erik Nordmark Subject: Re: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommenda tion note To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E0273A09E@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: > > response. It thus provides traceability. Furthermore, a firewall > > filter can be set up to scan for the tag (i.e, the IP address of the > > node causing the CN's response) and apply appropriate filtering rules. > > Thus, it allows blocking of undesirable packets. > > > > [GM]This firewall where would it be physically and which of the node(s) is > it providing these services for and how do you propose that the state > necessary to perform the filtering gets installed in the node(s). I have > inferred you mean some sort of external firewall to these victim nodes and > not a firewall on the hosts themselves where the net gain would be > negligable from a processing standpoint; though I am not certain this is > what you mean? Firewall the HA, MN, CN, Firewall all nodes, etc..? I am > concerned about the route optimisation getting blocked altogether. Glenn, I think that the discussion I and Rajeev had on the list resulted in the above statement about "the IP address of the node causing the CN's response" no longer being true. A firewall in front of a non-mobile node (a GN) can be configured to drop all tagged packets without too bad effects since the state machine on the CN is designed to effectively favor generating non-tagged packets. But what can't be done is to have a firewall in front of a HA (or as part of a HA) filter based on the actual tag value since that would make it trivial for any attacker on the Internet to cause many good packets to be dropped by such a filter. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 11:04: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 LAA02852 for ; Thu, 7 Mar 2002 11:04:16 -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 JAA28396; Thu, 7 Mar 2002 09:04: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 IAA17101; Thu, 7 Mar 2002 08:04: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 g27G3LKL009159 for ; Thu, 7 Mar 2002 08:03:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27G3LQ5009158 for mobile-ip-dist; Thu, 7 Mar 2002 08:03: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 g27G3HKL009151 for ; Thu, 7 Mar 2002 08:03:17 -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 g27G3Bx16453; Thu, 7 Mar 2002 17:03:11 +0100 (MET) Date: Thu, 7 Mar 2002 16:58:07 +0100 (CET) From: Erik Nordmark Subject: Re: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommendation note To: rajeev@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C86DC71.E7048501@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: > In our proposal, we have attempted to provide traceability and the > possibility to do filtering (most likely at the CN's domain to weed out > attacker's packets traced via the tag). I may not have seen the holes > apparent to you. So, please explain any while keeping in mind that we > are trying to stick with do no harm (i.e., not raise the bar). Rajeev, I'm trying to understand how such filtering would happen in practise - how can the HA/MN get the CN's domain to install a filter specifically for one MN? Imagine a practical case where by PDA is being attacked using *.cnn.com as the CNs. Do I give cnn a call to have them install a filter for src=X, HAO=me for inbound packets? This is very different than handling DoS attacks today because a customer can interact with their ISP (an entity with which the customer has a business relationship) and that ISP can interact with their upsteam ISPs or peers (with which the ISP has a business relationship). But there isn't a business relationship between me and all CNs in the world. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 11:35:35 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 LAA05261 for ; Thu, 7 Mar 2002 11:35: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 JAA00142; Thu, 7 Mar 2002 09:35: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 IAA24280; Thu, 7 Mar 2002 08:35: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 g27GYPKL009286 for ; Thu, 7 Mar 2002 08:34:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27GYPTV009285 for mobile-ip-dist; Thu, 7 Mar 2002 08:34: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 g27GYMKL009278 for ; Thu, 7 Mar 2002 08:34:22 -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 IAA14670 for ; Thu, 7 Mar 2002 08:34:22 -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 JAA29367 for ; Thu, 7 Mar 2002 09:34: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 IAA22799; Thu, 7 Mar 2002 08:34:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g27GYK625185; Thu, 7 Mar 2002 08:34:20 -0800 X-mProtect:  Thu, 7 Mar 2002 08:34:20 -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 smtpdx0DG7C; Thu, 07 Mar 2002 08:34:18 PST Message-ID: <3C87968B.ABD4CEBC@iprg.nokia.com> Date: Thu, 07 Mar 2002 08:34:19 -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, Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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: >> Unverified HAO allowable Unverified HAO prohibited >> >> - Robust to cache entry If CN times out or loses a Binding >> timeout and reclamation Cache entry, MN traffic is blackholed > > You seem to be forgetting that the unvHAO (just like the binding cache) > will be of finite size. No, and you are right that size matters here. However, my model is that the unvHAO will be somewhat less common, because typically nodes would start to set up a Binding Cache entry. This should be even more true now that we have a reasonable way to do so, using the Return Routability procedures. So, I reckon that finite size (but nonzero) should be O.K. The size depends on how many mobile senders the recevier expects to hear from. > If you take that into account you'll see that the unvHAO is actually less > robust because a MN will send unvHAO which will be dropped during normal > operation. Some error can be sent to the MN is this case but that is > after the packets have been lost. I think that nonzero cache size will be a lot more robust than zero cache size! > I think an attacker can easily fill the unvHAO cache with garbage since > there is no verification of the information that goes in there. > Thus an attacker can send > src=X HoA=::1 dst=cnn.com > and increase "1" until the unvHAO is filled. But this sort of behavior would be traceable to the source of the attack, and amounts to a temporary decrease in robustness at cnn.com. I admit it's not perfect, but it is improveable by techniques such as we have discussed, and it's a lot better than nothing. > Also, on the right you claim that timing out a BCE will cause packet loss > which isn't true. The MN knows the binding lifetime it its binding update list > which tell the MN for how long time it can continue to send HAOs. This is also true, and we can hope that the mobile node will send Binding Update packets before the cache times out. However, these Binding Update packets can be lost, and typically are not expected to be acknowledged. Furthermore, there are cases where clocks can be skewed. All in all, I think that we can expect some timeouts to occur. > The only case the strict HAO verification will drop packets (and send an > error to inform the MN) is when it has had a fatal loss of state > (i.e. crashed and rebooted). Not according to my understanding in the last paragraph. > This is normally a rather rare event and when it happens it will > disrupt the actual data traffic (TCP, RTP state being lost as well at the CN). > This is quite different than dropping packets during normal operation when > the unvHAO cache is full - whether due to high load or due to attacks. I don't think this is right. If we expect that the unvHAO entry is temporary until the verifiable Binding Cache entry is set up, then the scenario you describe is quite unlikely. >> - Fast response to packets Delays for either reverse tunneling >> initiated by MN or Binding Cache Entry establishment. >> Worse if CN implements ONLY RR. > > What is the delay? It is faster to send packets directly to the correspondent node than to use reverse tunneling. It takes a while to set up a Binding Cache entry, longer than reverse tunneling. If the CN implements only RR, and the mobile node requires something more, then there will be even more delay. > A MN which cares about performance presumably starts the data traffic > using reverse tunneling while the 1.5 roundtrips of RR+BU are > in effect. When it gets the BAck it can then switch to fully optimized path > in both directions. I definitely agree with you. >> - "Do No Harm" satisfied Reverse tunneling and black-holing >> is a "harm" > > We've talked about "do no harm" in the context of security. > You don't seem to be talking about security here so am I a bit confused. I didn't think it was very confusing! But you are right, that this effort to avoid harm is concerned with performance and robustness, at no cost in security. >> - Vulnerability == "way_small" Vulnerability == 0. > > "way_small" > "do no harm"? I don't think there is any realistic harm done here, and I do think that there is performance and robustness gains to be had that are worthwhile. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 12:52: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 MAA10528 for ; Thu, 7 Mar 2002 12:52: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 KAA29797; Thu, 7 Mar 2002 10:52: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 JAA12641; Thu, 7 Mar 2002 09:51: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 g27Hp0KL009497 for ; Thu, 7 Mar 2002 09:51:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Hox4q009496 for mobile-ip-dist; Thu, 7 Mar 2002 09:50: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 g27HouKL009489 for ; Thu, 7 Mar 2002 09:50:56 -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 JAA12130 for ; Thu, 7 Mar 2002 09:50:58 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13141 for ; Thu, 7 Mar 2002 09:50:56 -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 g27Hose25834 for ; Thu, 7 Mar 2002 09:50:54 -0800 (PST) Message-ID: <008101c1c600$680ce620$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4.2.0.58.J.20020307214307.00c1eac0@mail.mtc.mci.mei.co.jp> Subject: Re: [mobile-ip] question on the location of MN functions Date: Thu, 7 Mar 2002 09:49:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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 Iida-san, Have you read draft-ietf-mobileip-fast-mipv6-04.txt? It includes approaches to optimizing this. jak ----- Original Message ----- From: "Kenichiro Iida" To: Sent: Thursday, March 07, 2002 4:54 AM Subject: [mobile-ip] question on the location of MN functions > Hi. > > I read Mobile IPv6 I-D. > I have a question about Mobile IPv6. > > In Mobile IPv6 Protocol, MN has the functions of forming CoA and sending BU. > I think, If AR(Access Router) can have these functions, there will be the > following advantages. > > (1) AR can form MN's new CoA and perform DAD before Handover. > (2) The delay to register with HA and CN is reduced, because the delay > between AR and MN is eliminated. > In case that the link between AR and MN is wireless, e.g. WCDMA, its > transmission delay will be about several ten msec( 40-50msec ). > If AR sends BU, this transmission delay is eliminated. > > Are there any problems on this idea? > Could you give me any comments? > > Best regards, > > K.Iida > > > > ********************************************** > $BHSED!!7r0lO:!!(B(Kenichiro Iida) > $B>>2 $B!!!!%b%P%$%k%3%_%e%K%1!<%7%g%s3+H/%;%s%?! $B!!!!4pCO6I%7%9%F%`3+H/It!!3+H/(B3$B2](B > $B")(B239-0847 $B2#?\2l;T8w$N5V(B5$BHV(B3$B9f(B > E-$B#m#a#i#l(B $B!'(B Kenichiro.Iida@yrp.mci.mei.co.jp > TEL $B!'(B 0468-40-5235$B!!!JFb@~(B $B!'(B7-350-5399$B!K(B > **********************************************$B!!(B > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 13:22: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 NAA12605 for ; Thu, 7 Mar 2002 13:22: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 KAA27278; Thu, 7 Mar 2002 10:22:00 -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 KAA22881; Thu, 7 Mar 2002 10:21: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 g27IL1KL009712 for ; Thu, 7 Mar 2002 10:21:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IKrwX009711 for mobile-ip-dist; Thu, 7 Mar 2002 10:20: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 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 g27IKmKL009704 for ; Thu, 7 Mar 2002 10:20:49 -0800 (PST) Received: from lillen (vpn-129-159-0-25.EMEA.Sun.COM [129.159.0.25]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g27IKhx08504; Thu, 7 Mar 2002 19:20:43 +0100 (MET) Date: Thu, 7 Mar 2002 19:15:37 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Rajeev Koodli In-Reply-To: "Your message with ID" <3C87968B.ABD4CEBC@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: > > If you take that into account you'll see that the unvHAO is actually less > > robust because a MN will send unvHAO which will be dropped during normal > > operation. Some error can be sent to the MN is this case but that is > > after the packets have been lost. > > I think that nonzero cache size will be a lot more robust than zero > cache size! I agree about that! But you didn't address my point that lack of robustness is caused by the cache being finite. > > I think an attacker can easily fill the unvHAO cache with garbage since > > there is no verification of the information that goes in there. > > Thus an attacker can send > > src=X HoA=::1 dst=cnn.com > > and increase "1" until the unvHAO is filled. > > But this sort of behavior would be traceable to the source of the > attack, and amounts to a temporary decrease in robustness at cnn.com. > I admit it's not perfect, but it is improveable by techniques such as > we have discussed, and it's a lot better than nothing. Yes, but presumably cnn.com would see lots of unvHAO entries (assuming triangular is as useful as it is claimed) and it has no way to tell good from bad. Sure, if the src is identical for many it would be a hint. But the attacker could easily pick source addresses from the /64 for its subnet. Of course, such an attacker could also use RR to fill the binding cache. *BUT* that wouldn't cause packet drops for others - it would just cause others to not be able to complete the RR/BU exchange. > > Also, on the right you claim that timing out a BCE will cause packet loss > > which isn't true. The MN knows the binding lifetime it its binding update list > > which tell the MN for how long time it can continue to send HAOs. > > This is also true, and we can hope that the mobile node will send Binding > Update packets before the cache times out. However, these Binding Update > packets can be lost, and typically are not expected to be acknowledged. > Furthermore, there are cases where clocks can be skewed. All in all, > I think that we can expect some timeouts to occur. If the packet flow continues then either the MN can do a BU or the CN can send a BR some number of seconds before the binding expires. In both cases should the MN discover that the binding did not get renewed it makes sense for the MN to revert to reverse tunneling. I don't see what clock skew has to do with this - there are no absolute times communicate in MIPv6. Relative times aren't effected by clock skew. You seem to assume that the MN would not ask for a BAck. I'm assuming that with strict HAO checks against be BCE it makes a lot of sense for the MN to always ask for a BAck. And even with unvHAO it makes sense for the MN to ask for a BAck since without it the CN might continue to route packets to an old CoA until the binding expires. > > The only case the strict HAO verification will drop packets (and send an > > error to inform the MN) is when it has had a fatal loss of state > > (i.e. crashed and rebooted). > > Not according to my understanding in the last paragraph. If you assume that MNs don't care about stale BCEs on the CNs (i.e. they don't care if they don't receive packets from that CN) than of course they don't care about robustness. My point is that with strict HAO checks an MN can get robustness. With unvHAO there will be packet loss when the unvHAO cache gets full. As simple as that. > > This is normally a rather rare event and when it happens it will > > disrupt the actual data traffic (TCP, RTP state being lost as well at the CN). > > This is quite different than dropping packets during normal operation when > > the unvHAO cache is full - whether due to high load or due to attacks. > > I don't think this is right. If we expect that the unvHAO entry is > temporary until the verifiable Binding Cache entry is set up, then > the scenario you describe is quite unlikely. I'm confused. You are assuming that the unvHAO cache will only/mostly be useful for the 1.5 rtts until RO is setup? That makes no sense to me due to the probability of the packet loss issue with unvHAO. > > We've talked about "do no harm" in the context of security. > > You don't seem to be talking about security here so am I a bit confused. > > I didn't think it was very confusing! But you are right, that this > effort to avoid harm is concerned with performance and robustness, > at no cost in security. Are you trying to put words in my mouth? I think there are huge security problems caused by unvHAO. Sigh. Erik > >> - Vulnerability == "way_small" Vulnerability == 0. > > > > "way_small" > "do no harm"? > > I don't think there is any realistic harm done here, and I do > think that there is performance and robustness gains to be had > that are worthwhile. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 13:25: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 NAA12854 for ; Thu, 7 Mar 2002 13:25:10 -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 LAA18431; Thu, 7 Mar 2002 11:25:10 -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 KAA24259; Thu, 7 Mar 2002 10:25: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 g27IONKL009767 for ; Thu, 7 Mar 2002 10:24:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IONwU009766 for mobile-ip-dist; Thu, 7 Mar 2002 10:24: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 g27IOKKL009759 for ; Thu, 7 Mar 2002 10:24:20 -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 KAA26075 for ; Thu, 7 Mar 2002 10:24:19 -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 LAA02878 for ; Thu, 7 Mar 2002 11:24: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 KAA29917; Thu, 7 Mar 2002 10:24:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g27IOHs24617; Thu, 7 Mar 2002 10:24:17 -0800 X-mProtect:  Thu, 7 Mar 2002 10:24:17 -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 smtpdXTo8xo; Thu, 07 Mar 2002 10:24:15 PST Message-ID: <3C87B04F.AA95ABBA@iprg.nokia.com> Date: Thu, 07 Mar 2002 10:24:15 -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: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommendation note 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: > > In our proposal, we have attempted to provide traceability and the > > possibility to do filtering (most likely at the CN's domain to weed out > > attacker's packets traced via the tag). I may not have seen the holes > > apparent to you. So, please explain any while keeping in mind that we > > are trying to stick with do no harm (i.e., not raise the bar). > > Rajeev, > > I'm trying to understand how such filtering would happen > in practise - how can the HA/MN get the CN's domain to install a filter > specifically for one MN? > I don't know of a good answer. However, installing the filter need not be specifically for one MN. You would do this to block a malicious node from potentially affecting many MNs. You would detect such a possibility however through at least one MN. > > Imagine a practical case where by PDA is being attacked using *.cnn.com > as the CNs. > Do I give cnn a call to have them install a filter for > src=X, HAO=me > for inbound packets? > > This is very different than handling DoS attacks today because a customer > can interact with their ISP (an entity with which the customer has a business > relationship) and that ISP can interact with their upsteam ISPs or peers > (with which the ISP has a business relationship). > how about, customer = an entity supporting HA/MN ? The customer has an ISP (or is an ISP himself/herself) who interacts with another ISP. The same case above holds. Correct me if I am missing something.. > > But there isn't a business relationship between me and all CNs in the world. > You are a customer to some ISP and the CN is a customer to some other (or same) ISP. Isn't this generally the case ? Regards, -Rajeev > > Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 13:29: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 NAA13131 for ; Thu, 7 Mar 2002 13:29:59 -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 LAA28249; Thu, 7 Mar 2002 11:29:59 -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 KAA26266; Thu, 7 Mar 2002 10:29: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 g27IT9KL009848 for ; Thu, 7 Mar 2002 10:29:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IT9Q4009847 for mobile-ip-dist; Thu, 7 Mar 2002 10:29: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 g27IT5KL009840 for ; Thu, 7 Mar 2002 10:29:05 -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 KAA16948 for ; Thu, 7 Mar 2002 10:29:04 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06134 for ; Thu, 7 Mar 2002 11:29:03 -0700 (MST) Received: from piuha.net ([62.248.153.185]) by fep02-app.kolumbus.fi with ESMTP id <20020307182902.ZBPV12987.fep02-app.kolumbus.fi@piuha.net>; Thu, 7 Mar 2002 20:29:02 +0200 Message-ID: <3C87B1BF.6020909@piuha.net> Date: Thu, 07 Mar 2002 20:30:23 +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: Basavaraj.Patil@nokia.com, Rajeev Koodli CC: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: Re: [mobile-ip] (CONCLUSION) Unverified HAO Processing - Recommendation note References: <697DAA22C5004B4596E033803A7CEF44A128EE@daebe007.NOE.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 Rajeev and Basavaraj, I have now read your proposal and would like to offer some comments on it. (I'm still reading the rest of the thread so I could learn something new later.) > There are two concerns regarding the unverified use of HAO. First, any > node (attacker) may use a CN as a reflector to send packets to one or > more victims without being traced, since the CN's response is sent to > the HoA with the CN's IP address as the source IP address. This is the > traceability problem. As a matter of comparison, if a such a DoS > attack were to happen today, the source IP address in the unsolicited > packet would be the (typically spoofed) IP address of the > sender. This is correct, but there's also a bit more to the traceability problem. Namely, mechanisms are being added to the Internet to allow for tracing packets regardless of possible forging of the source address. HAO makes one of the trace schemes, itrace, not work as the interesting leg of the packet's path will not generate traces to the victim. This is however fixable with what we called 3-way itrace somewhere in the DT notes. However, another (apparently a more popular) technique called IPPT however can't be fixed this way. > Second, as a response to prevent such attacks, source ingress > filtering is used to block certain packets. With HAO, such a mechanism > cannot readily be used. The solution proposed here requires a CN to > include the source IP address of the packet in a response message from > the CN. This allows the owner of the HoA to determine, from the ``tag'' > present in the packet, the true originator that caused the CN's > response. It thus provides traceability. Hmm... so we get traceability, but what about prevention a la ingress filtering? > 3. If packets arrive with erroneous tags, a Home Agent drops those > packets. It may optionally send an ICMP destination unreachable > message in which it includes the correct tag (i.e., the correct CoA > from its BC) that updates the unverified BCE. Meanwhile, any packet > from the genuine MN with an HAO would also correct the CN's > entry. On the other hand, the HA tunnels packets with correct tags > to the MN. Destination unreachable is ok, but the process for sending correct tags sounds dangerous. Could be used by bad guys as well. > - if an entity such as a firewall discards packets with the tag, > then the traffic from CN to GN would be ``disrupted''. However, > the tag disappears when the CN receives a packet from GN (without > HAO) or if the lifetime of the tag expires whichever is earlier. > > Only when the GN is a ``one-way listener'', and the firewall > is configured to discard such packets, is there a possibility > to disrupt the traffic up to a maximum of the lifetime of the > unverified BCE. For this reason, we suggest a relatively short > lifetime. So, if I know an address that is likely to be filtered (e.g. 10.x.x.x) and claim that as my CoA in a single packet to a CN with HoA=victim, then victim's unidirectional traffic will be lost for a while? > 4. CN IMPLEMENTATION > The state machine is summarized in the following table. > > State Event -> New state Action > > start non-HAO -> no state change - > start HAO pkt -> tag, start T1 > tag HAO pkt -> no state change, update T1 > tag T1 expires -> start, - > tag non-HAO -> no-tag, start T2, reset T1 > no-tag HAO -> no-tag, drop packet > no-tag T2 expires -> start, - > no-tag non-HAO -> no state change, - So, assuming this works well within an area where ingress filtering is used, what happens to other areas? For instance, if on this particular area (the place of the victim) we don't have ingress filtering, then he could guess that a mobile M is talking to correspondent C and hence C is at the "tag" state. Then the attacker could send a spoofed message with M as the source and with no HAO. Then C would move to no-tag state, and drop all M's traffic for T2 time. Note that without the tagging scheme, all the attacker could possibly do is to inject some extra packets, not start dropping real packets. Doesn't this violate the no-harm principle? Also, consider what the attacker has to do in order to inject the bad packet as above. He doesn't in fact have to even guess TCP sequence numbers or anything like that, because for the purposes of tag processing, it is enough to get one packet in, regardless of whether TCP throws it away immediately or not. In conclusion, I fear that while fixing a problem, we may be introducing serious other problems. > 5. SIMULTANEOUS USE OF HAO AND REVERSE TUNNELING > ================================================= > > A MN may wish to simultaneously use, for whatever reasons, both HAO > and reverse tunneling. If a MN needs to use reverse tunneling while it > is using HAO, it should use HAO on those packets that it reverse > tunnels. Not doing so _could_ make some of its HAO packets to be > dropped, i.e., those HAO packets that arrive when the CN is in > no-tagging state. The exact number of packets that might be dropped > depends on, among other things, the holding time in no-tagging state, > and the likelihood of MN generating packets with HAO while the CN is in > no-tagging state. Uh oh so we have an intermediate optimization (triangular routing) which drops packets... I'm not too comfortable with this. > 5. RECOMMENDATION > ================== > > It appears that with the proposed mechanism, the concerns raised > regarding the unverified HAO processing can be effectively > addressed. The traceability aspect wasn't addressed fully. We can now trace things when the source addresses are right (e.g. under ingress filtering) as the tag is carried along. However, we would also need to address the case where it is not, and would use something like itrace or ippt. The former appears to be fixable, but the latter is not. > While the proposed mechanism may not be perfect, it > offers disincentives for an attacker to do harm and provides > sufficient correcting ability for a genuine node so that any potential > disruption can be quickly repaired. Hmm... let's analyze this. The first issue that comes to my mind is attacker's who might be filling the unvBCE memory on purpose, in order to flush out necessary states related to the victim. The secod issue that almost by definition, this scheme can't provide an authenticated HoA in the tag option, not even in the RR sense of the word "authenticted". So, regardless of how well we plug the holes we notice, there is going to be other holes left that allow attackers to inject inappropriate tags to the traffic, possibly causing packets to be dropped at firewalls or the HA. > Recommendation R1 : We recommend that unverified HAO processing be > done according to the rules specified in Section 2. DISAGREE. I think there are holes in traceability, at least on this first read this appears to be introducing new holes, and the scheme is relatively complicated. Wouldn't it be simpler to just require RO from the CNs, if we are to require the CNs to hold state? Please note that *every* CN has to implement this. If you use the BCE implementation strategy, why wouldn't we at the same time bite the bullet and implement and use RO itself? However, I do have a constructive proposal on how we could go ahead and still try to get something like this in the standards assuming we *do* resolve the open issues somehow. I'd like to propose that the BR message that reports lack of memory for unvBCE would be used to signal the support for this feature. This way, we could go ahead with the base MIPv6 RFC with bidir and RO, and *if* we get these issues solved, we can introduce another RFC which specifies the following: 1) MNs can optimistically start to use triangular routing and unvHAOs 2) If they get a BR they will downgrade back to bidir and assume CN supports only the base RFC 3) If no BR, they proceed as planned Disclaimer: when I read the rest of the thread, I might change my mind about what I've said in this e-mail... Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 13: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 NAA14364 for ; Thu, 7 Mar 2002 13:48:51 -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 LAA00511; Thu, 7 Mar 2002 11:48: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 KAA04593; Thu, 7 Mar 2002 10:48: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 g27IlsKL009937 for ; Thu, 7 Mar 2002 10:47:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IlsEp009936 for mobile-ip-dist; Thu, 7 Mar 2002 10: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IloKL009929 for ; Thu, 7 Mar 2002 10:47:50 -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 KAA21736 for ; Thu, 7 Mar 2002 10:47:49 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16346 for ; Thu, 7 Mar 2002 11:47:48 -0700 (MST) Received: from piuha.net ([62.248.153.185]) by fep02-app.kolumbus.fi with ESMTP id <20020307184748.ZDRE12987.fep02-app.kolumbus.fi@piuha.net>; Thu, 7 Mar 2002 20:47:48 +0200 Message-ID: <3C87B625.9000706@piuha.net> Date: Thu, 07 Mar 2002 20:49:09 +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 CC: Rajeev Koodli , Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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: > When the CN receives a mix of packets with src=X,HAO=HoA and src=CoA,HAO=HoA > it will hopefully mark a mix of packets with tag=X and tag=CoA > (and we need to figure out to ensure that at least some packets have tag=X > for traceability). > > My point is that the tag value can't be use to filter out the bad > packets because there will not be any correlation between > the src of a packet received at the CN and the tag value of the response > to that packet when there are multiple packets in progress. This seems to be fundamental observation. *Any* non-socketApi solution necessarily has to make a random/heuristic assignment of the tags to the outgoing packets. If so, the solution can *not* be used to filter out bad guy's traffic as per the original requirement. The original requirement was to be able to see that address X somewhere in the net is attacking us, and placing a filter at the ISP router to block all packets with Src=X or Tag=X. However, if we can't guarantee the right packets are tagged, we'll be dropping some real packets and not all wrong packets. This isn't good. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 14:18: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 OAA16413 for ; Thu, 7 Mar 2002 14:18:59 -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 MAA03198; Thu, 7 Mar 2002 12:18:58 -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 LAA29885; Thu, 7 Mar 2002 11:18: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 g27JHpKL010100 for ; Thu, 7 Mar 2002 11:17:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27JHoxg010099 for mobile-ip-dist; Thu, 7 Mar 2002 11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JHlKL010092 for ; Thu, 7 Mar 2002 11:17: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 LAA13004 for ; Thu, 7 Mar 2002 11:17:47 -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 MAA22923 for ; Thu, 7 Mar 2002 12:17: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 LAA04600; Thu, 7 Mar 2002 11:17:47 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g27JHja02022; Thu, 7 Mar 2002 11:17:45 -0800 X-mProtect:  Thu, 7 Mar 2002 11:17: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 smtpdvCiVqa; Thu, 07 Mar 2002 11:17:42 PST Message-ID: <3C87BCD7.9E30BD5B@iprg.nokia.com> Date: Thu, 07 Mar 2002 11:17:43 -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] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 again Erik, Erik Nordmark wrote: >> I think that nonzero cache size will be a lot more robust than zero >> cache size! > > I agree about that! > > But you didn't address my point that lack of robustness is caused by the > cache being finite. The robustness problem will come when the cache is filled. The cache can be sized so that under normal operation it will rarely if ever be filled. I thought that was implicit in what I said. >> But this sort of behavior would be traceable to the source of the >> attack, and amounts to a temporary decrease in robustness at cnn.com. >> I admit it's not perfect, but it is improveable by techniques such as >> we have discussed, and it's a lot better than nothing. > > Yes, but presumably cnn.com would see lots of unvHAO entries (assuming > triangular is as useful as it is claimed) and it has no way to tell > good from bad. > Sure, if the src is identical for many it would be a hint. > But the attacker could easily pick source addresses from the /64 for its > subnet. If this gets to be a problem, then the implementation can count against prefixes instead of against 128-bit addresses. I think we are discussing a problem that is already unlikely, but if it exhibits some hint of likelihood, then at that time the engineering tradeoffs will become apparent. > Of course, such an attacker could also use RR to fill the binding cache. > *BUT* that wouldn't cause packet drops for others - it would just cause > others to not be able to complete the RR/BU exchange. This depends on the cache management strategy, and on the ability to match outgoing tags with incoming packets as we have discussed. The attacker is also traceable, so I don't see this as a serious threat. And, the downside is annoying, but temporary and nonfatal. If it's really important, though, we could have a fallback position by which mobile nodes that are frustrated with incomplete RR/BU exchanges, to use reverse tunneling. >> ........... these Binding Update >> packets can be lost, and typically are not expected to be acknowledged. >> Furthermore, there are cases where clocks can be skewed. All in all, >> I think that we can expect some timeouts to occur. > > If the packet flow continues then either the MN can do a BU or the CN can > send a BR some number of seconds before the binding expires. Yes, but I think your statement points out that we are facing a loss in responsiveness. I hope we can avoid this sort of annoyance, especially for interactive traffic. > In both cases should the MN discover that the binding did not get renewed > it makes sense for the MN to revert to reverse tunneling. > I don't see what clock skew has to do with this - there are no absolute > times communicate in MIPv6. Relative times aren't effected by clock skew. It could be that, under attack, reverting to reverse tunneling would be a useful strategy. Instead of "clock skew", it would more precisely be a problem only with skewed clock rates. > You seem to assume that the MN would not ask for a BAck. > I'm assuming that with strict HAO checks against be BCE it makes > a lot of sense for the MN to always ask for a BAck. This is introducing a need for a lot more signaling (approximately double what unacknowledged Binding Update would require). I had always thought it was a good feature of Mobile IPv6 that we should be able to avoid that. > And even with unvHAO it makes sense for the MN to ask for a BAck > since without it the CN might continue to route packets to an old CoA until > the binding expires. > > > > The only case the strict HAO verification will drop packets (and send an > > > error to inform the MN) is when it has had a fatal loss of state > > > (i.e. crashed and rebooted). > > > > Not according to my understanding in the last paragraph. > > If you assume that MNs don't care about stale BCEs on the CNs (i.e. they > don't care if they don't receive packets from that CN) than of course > they don't care about robustness. I am not at all making that assumption. Stale Binding Cache entries should be handled by handover techniques. I do think that mobile nodes should care about robustness and performance -- which is the main reason that I'm involved in this discussion. My statement in this quoted segment followed from my previous statement about the possibility for cache entries to be timed out or reclaimed. > My point is that with strict HAO checks an MN can get robustness. > With unvHAO there will be packet loss when the unvHAO cache gets full. > As simple as that. I also think we should expect most HAOs to be verifiable. I believe that we can get greater robustness by allowing a small percentage of HAOs to be acceptable, along the way towards establishing verifiability. > I'm confused. You are assuming that the unvHAO cache will only/mostly be useful > for the 1.5 rtts until RO is setup? That makes no sense to me due to the > probability of the packet loss issue with unvHAO. The probability of packet loss is zero, unless a node is under attack. The probability of attack is low, and the attacker is traceable. I am hoping that most HAOs will be verifiable, and I am proposing that we allow some of them to be acceptable, and tagged, prior to the moment when they are verifiable. >>> We've talked about "do no harm" in the context of security. >>> You don't seem to be talking about security here so am I a bit confused. >> >> I didn't think it was very confusing! But you are right, that this >> effort to avoid harm is concerned with performance and robustness, >> at no cost in security. > > Are you trying to put words in my mouth? Erik, I am not trying to subvert your message. The last clause is mine, and I _thought_ the previous clause was implied by your statement. You can tell me I was wrong about my inference, but please don't make out like I am arguing unethically. > I think there are huge security problems caused by unvHAO. I think the problems are really microscopic! And, that they are only evident under malicious attack, which is in addition benefitting from highly improbable and fortuitous chance occurrence. Most attackers would rather not go for a traceable attack which is unlikely to succeed anyway. I do not believe that protecting against such unlikely attacks is worthy cause for loss of performance and robustness. > Sigh. If this is an expression of frustration, then please try to view my message as an attempt to build a better system. I am not doing this to frustrate you. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 14:29: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 OAA17228 for ; Thu, 7 Mar 2002 14:29:40 -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 MAA20942; Thu, 7 Mar 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 LAA02621; Thu, 7 Mar 2002 11:29: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 g27JSVKL010215 for ; Thu, 7 Mar 2002 11:28:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27JSVrY010214 for mobile-ip-dist; Thu, 7 Mar 2002 11:28: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 g27JSSKL010207 for ; Thu, 7 Mar 2002 11:28:28 -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 LAA16990 for ; Thu, 7 Mar 2002 11:28:28 -0800 (PST) Received: from tahi-200.Connectathon.ORG ([130.128.68.200]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20402 for ; Thu, 7 Mar 2002 12:28:27 -0700 (MST) Received: from tahi-200.Connectathon.ORG (localhost [127.0.0.1]) by tahi-200.Connectathon.ORG (8.11.6/8.11.6) with SMTP id g27JSZG01008 for ; Fri, 8 Mar 2002 04:28:35 +0900 (JST) (envelope-from yukiyo_akisada@yokogawa.co.jp) Date: Fri, 8 Mar 2002 04:28:35 +0900 From: Yukiyo Akisada To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] about proxy DAD Message-Id: <20020308042835.359fdc71.yukiyo_akisada@yokogawa.co.jp> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.7.2 (GTK+ 1.2.10; i386-unknown-freebsd4.4) Mime-Version: 1.0 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. I have some quiestions about proxy DAD. When the MN sends BU (S bit is 0), should HA execute DAD for only MN's link-local home address? or both of link-local and global addess? And when the MN sends BU (S bit is 1), should HA execute DAD for only global address? or not? ID-15 chapter 9.1 says that - Finally, if the Duplicate Address Detection (D) bit is set in the Binding Update, this home agent MUST perform Duplicate Address Detection [27] on the mobile node's home link for the home address in this binding (before returning the Binding Acknowledgement). The address used for Duplicate Address Detection SHOULD be the mobile node's link-local address. and If the `S' bit field in the Binding Update is zero, The Home Agent creates or updates Binding Cache entries for each of possible several home addresses. The set of such home addresses is formed by replacing the routing prefix for the given home address with all other routing prefixes that are supported by the home agent processing the Binding Update. The Home Agent creates such a separate primary care-of address registration for each such home address. Note that the same considerations for Duplicate Address Detection apply for each affected home address. I'm little confusing about this. Regards. ---- Yukiyo Akisada @ TAHI Project From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 20:03: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 UAA05502 for ; Thu, 7 Mar 2002 20:03: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 RAA22883; Thu, 7 Mar 2002 17:03:21 -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 RAA10273; Thu, 7 Mar 2002 17:03: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 g28128KL010731 for ; Thu, 7 Mar 2002 17:02:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28127dt010730 for mobile-ip-dist; Thu, 7 Mar 2002 17:02: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 g28124KL010723 for ; Thu, 7 Mar 2002 17:02: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 RAA12783; Thu, 7 Mar 2002 17:02:06 -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 SAA20690; Thu, 7 Mar 2002 18:02: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 RAA26016; Thu, 7 Mar 2002 17:02:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g28123Y22987; Thu, 7 Mar 2002 17:02:03 -0800 X-mProtect:  Thu, 7 Mar 2002 17:02:03 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpde9Sqv8; Thu, 07 Mar 2002 17:02:01 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 RAA20134; Thu, 7 Mar 2002 17:02:02 -0800 (PST) Message-ID: <3C880D8A.5420AC59@iprg.nokia.com> Date: Thu, 07 Mar 2002 17:02:02 -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: "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 Some very brief notes on this thread I had no time following unfortunately until now.. - On robustness: both verified and unverified caches are in reality finite in size. Both would have a similar error mechanism anyway so there is hardly a difference in robustness in RO-BC or unverified cache filling up. With the latter you may lose some packets in transit, but also with the former, it is just a cache and may get destroyed before or without new BU reaching the CN. In a worst case a RO data packet may be on path and get dropped in such a gap. This should not be a real argument. - On traceability: support for traceability with current mechanisms as is cannot clearly be an assumption since a tag is a new construct. But we know traceability is possible due to the tag being an audit. It does not support all the ways tracing is done today but tracing in general can be supported given the right tool. - On filterability: in CN: possible, between CN and a HA maybe possible with exact tagging. Best effort tagging gives the chance for the attacker to exploit tags being responses to packets with different CoA due to asynchrony of L3 stack and the applications. This was considered a real issue by some, but to really consider whether this is beyond do no harm, here are some more thoughts - Injecting packets to unsecured payload traffic by sending spoofed packets along a legal stream really is possible even without mobility. One just spoofs CN address inserting it to source address and adds those to the legal stream if on path. Exact tagging is actually addressing the case when tagging should also consider that application data traffic is unsecured. Tagging can hardly fix that, and given the source IP can be spoofed without mobility, the comparison in the discussion so far has not been completely fair. The definition of do-no-harm is not clear from the discussion thread. I still suspect tagging does not go beyond this when comparing to this non-mobility case. - What a filtering firewall really does is to also block the legal CN in the above non-MIPv6 case. If tagging is there, any packet prompting filtering on the CN-HA path can then cause blocking of all packets going to the destination HoA. Useful packets are lost but so are in the above case. There are only differences in nuances, now the attacker does not have to change source address and a filter has a different but equally stateless rule that instead of the source address filters by the destination address, while the tag gives the traceability. One could claim there is a difference in the added ability to do off path attacks with tagging but unless we have globally deployed martian filtering (which we do not have), one can also mount the above type of source spoofing attacks with non-mobility packets even from off-path locations. As a conclusion, I can live with the HOA tagging being an option with a separate specification added later on, to expedite the base specification, but do not yet understand the security arguments against tagging. BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 21:29: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 VAA08188 for ; Thu, 7 Mar 2002 21:29:34 -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 TAA03732; Thu, 7 Mar 2002 19:29: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 SAA07921; Thu, 7 Mar 2002 18: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 g282RvKL010969 for ; Thu, 7 Mar 2002 18:27:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g282RvV8010968 for mobile-ip-dist; Thu, 7 Mar 2002 18:27: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 g282RrKL010961 for ; Thu, 7 Mar 2002 18:27: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 SAA07544 for ; Thu, 7 Mar 2002 18:27:54 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21607 for ; Thu, 7 Mar 2002 18:27:53 -0800 (PST) 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 g282RpZc010600 for ; Fri, 8 Mar 2002 03:27:51 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 08 03:26:35 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 03:18:00 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAA5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli Subject: RE: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note Date: Fri, 8 Mar 2002 02:42: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: Jari, > - Injecting packets to unsecured payload traffic by sending > spoofed packets along a legal stream really is possible > even without mobility. One just spoofs CN address inserting > it to source address and adds those to the legal stream if on > path. => Isn't 'on path' the keyword here ? Ignoring on path attackers (because you said they already exist), doesn't the inability of CNs to place filters allow for off-path attackers? I thought this was the main issue here, but I admit I haven't read every mail on this thread. Hesham Exact tagging is actually addressing the case when > tagging should also consider that application data traffic > is unsecured. Tagging can hardly fix that, and given the > source IP can be spoofed without mobility, the comparison > in the discussion so far has not been completely fair. > The definition of do-no-harm is not clear from the discussion > thread. I still suspect tagging does not go beyond this > when comparing to this non-mobility case. > > - What a filtering firewall really does is to also block the > legal CN in the above non-MIPv6 case. If tagging is > there, any packet prompting filtering on the CN-HA path > can then cause blocking of all packets going to the > destination HoA. Useful packets are lost but so are in > the above case. There are only differences in nuances, > now the attacker does not have to change source address > and a filter has a different but equally stateless rule > that instead of the source address filters by the > destination address, while the tag gives the traceability. > One could claim there is a difference in the added ability to > do off path attacks with tagging but unless we have globally > deployed martian filtering (which we do not have), one > can also mount the above type of source spoofing attacks with > non-mobility packets even from off-path locations. > > As a conclusion, I can live with the HOA tagging being an > option with a separate specification added later on, to > expedite the base specification, but do not yet understand > the security arguments against tagging. > > BR, > > -Jari > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 7 21:37: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 VAA09326 for ; Thu, 7 Mar 2002 21:37:37 -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 TAA15407; Thu, 7 Mar 2002 19:37: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 SAA02150; Thu, 7 Mar 2002 18:37: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 g282aEKL011058 for ; Thu, 7 Mar 2002 18:36:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g282aEVS011057 for mobile-ip-dist; Thu, 7 Mar 2002 18:36: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 g282a9KL011050 for ; Thu, 7 Mar 2002 18:36:10 -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 SAA14470 for ; Thu, 7 Mar 2002 18:36:10 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA05645 for ; Thu, 7 Mar 2002 19:36:09 -0700 (MST) Received: from docomocarl (dhcp104.docomolabs-usa.com [172.21.96.104]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g282a7e19647; Thu, 7 Mar 2002 18:36:08 -0800 (PST) Message-ID: <056f01c1c64a$2ace3080$686015ac@docomocarl> From: "Carl Williams" To: Cc: "Alper Yegin" , "James Kempf" , "Allison Mankin" , "Scott Bradner" , , "Aaron Falk" Subject: [mobile-ip] L2 Triggers Pre-BOF Announcement Date: Thu, 7 Mar 2002 18:37:18 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056C_01C1C607.1C0D9F10" 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_056C_01C1C607.1C0D9F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A L2 triggers pre-BOF will be held at the IETF on Monday nite at 10:00pm. We will meet at 10:00pm in front of the bulletin board near the IETF registration desk and=20 proceed to an empty conference room. Aaron Falk (falk@ISI.edu) and myself will co-chair the pre-BOF discussion on L2 triggers. Aaron is currently co-chair of the PILC working group and we will work together in faciliating a good discussion on L2 triggers in preparation for an official BOF in Japan. There have been several L2 related internet drafts both dealing with more wireless area. We would like to get some discussion about=20 how L2 triggers can be broadened out of being strictly a wireless related thing and be more general.=20 Please join us in this pre-BOF L2 triggers debate on Monday, March 18. Thanks Carl and Aaron Co-chairs of L2 Triggers Pre-BOF L2 Trigger Pre-BOF 10:00pm on March 18 (Monday evening) In front of IETF bulletin board (near IETF registration) ------=_NextPart_000_056C_01C1C607.1C0D9F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A L2 triggers pre-BOF will be held at = the=20 IETF
on Monday nite at 10:00pm.  We = will=20 meet
at 10:00pm in front of the bulletin = board=20 near
the IETF registration desk  and =
proceed to an empty conference = room.
 
Aaron Falk (falk@ISI.edu) and myself
will co-chair the pre-BOF discussion=20 on
L2 triggers.  Aaron is currently=20 co-chair
of the PILC working group and we = will
work together in faciliating a good=20 discussion
on L2 triggers in preparation = for
an official BOF in Japan.
 
There have been several L2 related=20 internet
drafts both dealing with more wireless=20 area.
We would like to get some discussion = about=20
how L2 triggers can be broadened out of = being
strictly a wireless related thing and be more general. =
 
Please join us in this pre-BOF L2 = triggers=20 debate
on Monday, March 18.
 
 
Thanks
 
Carl and Aaron
Co-chairs of L2 Triggers Pre-BOF
 
L2 Trigger Pre-BOF
10:00pm on March 18 (Monday evening)
In front of IETF bulletin board (near IETF=20 registration)
 
------=_NextPart_000_056C_01C1C607.1C0D9F10-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 02:22: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 CAA24002 for ; Fri, 8 Mar 2002 02:22:08 -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 XAA14373; Thu, 7 Mar 2002 23:22:06 -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 XAA14601; Thu, 7 Mar 2002 23:21: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 g287KwKL011426 for ; Thu, 7 Mar 2002 23:20:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g287Kweo011425 for mobile-ip-dist; Thu, 7 Mar 2002 23:20: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 g287KtKL011418 for ; Thu, 7 Mar 2002 23:20:55 -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 XAA26162 for ; Thu, 7 Mar 2002 23:20:56 -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 XAA16921 for ; Thu, 7 Mar 2002 23:20: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 XAA10813 for ; Thu, 7 Mar 2002 23:20:55 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g287Ks130944 for ; Thu, 7 Mar 2002 23:20:54 -0800 X-mProtect:  Thu, 7 Mar 2002 23:20:54 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdaYIrRo; Thu, 07 Mar 2002 23:20:52 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 XAA20605 for ; Thu, 7 Mar 2002 23:20:52 -0800 (PST) Message-ID: <3C886654.EE25A4C@iprg.nokia.com> Date: Thu, 07 Mar 2002 23:20:52 -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] CLARIFICATION: Unverified HAO Processing - Recommendation note References: <4DA6EA82906FD511BE2F00508BCF053802C6AAA5@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: > > Jari, > > > - Injecting packets to unsecured payload traffic by sending > > spoofed packets along a legal stream really is possible > > even without mobility. One just spoofs CN address inserting > > it to source address and adds those to the legal stream if on > > path. > > => Isn't 'on path' the keyword here ? > Ignoring on path attackers (because you said > they already exist), doesn't the inability > of CNs to place filters allow for off-path > attackers? I thought this was the main > issue here, but I admit I haven't read every > mail on this thread. Actually, CN having filters by the tagging schemes would be quite feasible, but the reordering of packets vs tags makes precise filtering (filter exactly attacker packets only) harder on other nodes between CN and HA. I was questioning is this different from a non-mobility case with spoofed CN address in attacker's packet. And also, questioning the more harm argument, comparing to non-mobility case, there could be similar off-path attacks (attacker just inserting an arbitrary spoofed address to IPhdr source) if/since there can be places/paths where we do not have Martian filtering (ingress filtering from addresses coming from topologically "wrong" directions) verifiably on every path an attacker could use. > Hesham BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 03:35: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 DAA25675 for ; Fri, 8 Mar 2002 03:35:33 -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 AAA23384; Fri, 8 Mar 2002 00:35:32 -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 AAA04973; Fri, 8 Mar 2002 00:35: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 g288WFKL011676 for ; Fri, 8 Mar 2002 00:32:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g288WF36011675 for mobile-ip-dist; Fri, 8 Mar 2002 00:32: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g288WCKL011668 for ; Fri, 8 Mar 2002 00:32:12 -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 AAA26490 for ; Fri, 8 Mar 2002 00:32:11 -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 BAA02193 for ; Fri, 8 Mar 2002 01:32:10 -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 AAA13011 for ; Fri, 8 Mar 2002 00:32:10 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g288W9m13072 for ; Fri, 8 Mar 2002 00:32:09 -0800 X-mProtect:  Fri, 8 Mar 2002 00:32:09 -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 smtpdKR8WXC; Fri, 08 Mar 2002 00:32:06 PST Message-ID: <3C8876A0.DAEB74CE@iprg.nokia.com> Date: Fri, 08 Mar 2002 00:30: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 Working Group Subject: [mobile-ip] Text and proposal for piggybacking 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, This text results from collaboration with Francis Dupont and Jari Malinen, who did most of the work. Together, we hope it will represent a successful effort to find the serviceable consensus that enables use of IPsec even with restrictive interpretation about application of IPsec policy to final headers only. Regards, Charlie P. ======================================================================= X.Y Piggybacking with IPsec This section describes when it is possible to piggyback mobility options (BU/BACk and RR messages) while using IPsec and what an implementation needs to do in both the sender and the receiver. Two new header types are needed: one extension header for piggybacking, and one final header type used with IPsec. Since the extension header with payload is not to be protected by IPsec, and the final header type is considered as transport, IPsec does not have to be changed at all in any node, peer or intermediate. Since these two headers are identical except for their type number, the effect on mobility implementation is minimal. Interoperation in any case is secured by making piggybacking a negotiable option. If node (HA, MN, or CN) can send and receive piggybacked packets, it SHOULD initiate or respond in piggybacking negotiation by setting the piggybacking flag in the mobility signaling as enabled. Also, if the peer in the negotiation does not enable its flag, or the node does not receive such a message, the node MUST NOT piggyback. If IPsec is not used, an implementation can have a policy which by default allows piggybacking, by means of static configuration. Then the node can follow this static configuration and it SHOULD enable its own piggybacking flag in the case the configuration is set. If there is any non-IPsec reason why the node cannot piggyback, this policy can be disabled by a management interface to the policy. In order to piggyback payload and mobility messages when IPsec is in use, we have cases 1-4 in Table 1. Assuming the current IPsec selectors [RFC 2401] and two new extension headers for mobility signals, the node having IPsec policies (resulting in an AH or ESP header) can piggyback in cases 1 and 2, that is, when mobility signaling does not have an IPsec policy. Table 1. Piggybacking with IPsec IPsec policy for IPsec policy Mobility Message for Payload Can piggyback 1. no no yes 2. no yes yes 3. yes no no 4. yes yes no In order for the mobility signaling to enforce this, the mobility implementation of a sender needs to know whether mobility signaling has a non-default policy. It can do this by constructing a signaling packet, making the header type final and causing a kernel IPsec policy lookup exactly like current kernel IPsec does this for any packet. If no policy exists, the final header type MAY be changed to the non-final extension, indicating that this signal can be piggybacked. If a policy was found, the final header type is used. A receiver does not need to have any knowledge of mobility in its IPsec processing. The header type hard-codes whether a policy even can exist, so if the header is final and no policy, or a wrong policy exists, the packet will be rejected anyway by IPsec. If the header is a non-final extension header, the header type hard codes that this signal cannot have an IPsec policy. Whether the receiver accepts the extension signal depends on policy of the non-IPsec protection. These policies or their interaction with IPsec (re: bidding down or bidding aside prevention) cannot be enforced by unmodified IPsec mechanisms. So even with the non-final extension, mobility does not have to be IPsec aware and vice versa. Piggybacking is not possible on case 3, due to processing difficulties at both the sender and the receiver. The scan for transport protocol field as described in RFC 2401 seems to disallow this mode. For case 4, conflicting IPsec policies would make it impossible to piggyback. Putting the above together, the sender MAY piggyback for the cases 1 and 2 in Table 1 and MUST NOT piggyback for cases 3 and 4. Equivalently, piggybacking is possible if and only if there is no IPsec policy for protection of the fields of the mobility signaling header. X.Z Which Mobility Signals to Piggyback An implementation sends piggyback when its negotiation result with the peer allows and if it makes sense for the mobility signal in question. Mobility signals include BR/BU/BAck and the RR messages. Piggybacking of BR/BU/BAck messages between the MN and HA is very rare. It can be done only when the payload belongs to a session between the MN and HA. For piggybacking between MN and CN, Table 2 describes when a mobility signal can be piggybacked. Table 2: Mobility Signals and Piggybacking (adapted from Design Team's writeup with small changes) Message Sndr Rcvr Pig Binding Request CN MN Yes Binding Update MN CN Yes Binding Acknowledgment CN MN Yes RR 1a MN CN Yes* RR 1b MN CN Yes* RR 2a CN MN Yes? RR 2b CN MN No A (*) indicates that piggybacking would be sometimes possible (details in the DT writeup). A (?) - cant it be piggybacked?? not sure. didnt quite understand what the DT was trying to say about a 'rogue HA'. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 03:51: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 DAA26012 for ; Fri, 8 Mar 2002 03:51:40 -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 BAA28106; Fri, 8 Mar 2002 01:51: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 AAA06837; Fri, 8 Mar 2002 00:51: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 g288oQKL011815 for ; Fri, 8 Mar 2002 00:50:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g288oQcb011814 for mobile-ip-dist; Fri, 8 Mar 2002 00:50: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 g288oNKL011807 for ; Fri, 8 Mar 2002 00:50:23 -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 AAA29557; Fri, 8 Mar 2002 00:50:08 -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 BAA27573; Fri, 8 Mar 2002 01:50: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 AAA13443; Fri, 8 Mar 2002 00:50:07 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g288o7g23872; Fri, 8 Mar 2002 00:50:07 -0800 X-mProtect:  Fri, 8 Mar 2002 00:50:07 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdrShY0G; Fri, 08 Mar 2002 00:50: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 AAA20700; Fri, 8 Mar 2002 00:50:05 -0800 (PST) Message-ID: <3C887B3D.C0CE4A67@iprg.nokia.com> Date: Fri, 08 Mar 2002 00:50: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 CC: "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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 think there are huge security problems caused by unvHAO. Since in today's discussion this was not exactly stated, and I assume by unvHAO you here also include unvHAO when the tagging method is used, I'd like to hear more of these particular problems. Even if best effort tagging is used, the only concrete security issue in the best effort tagging proposal that I heard, was for this limited case: - with tags and response packets being out of sync, right packets may get wrong tags and vice versa making tag-based filtering drop wrong packets and pass right packets. But: any filter in and after CN can still drop both, based on the destination address, for example, if we drop both right and wrong packets to this HoA. Also, given the timer range behavior with the unverified HAO cache, and unpredictability of the reflecting application, attack packets can be entered only momentarily, which makes it hard to find those moments due to randomized timeout ranges. Could you help me to see where the added harm is? It is unclear to me how the above issue effectively differs from the case non-mobility attack packets have a spoofed source address and get to be filtered along with victim's traffic from the same source address? These can be launched on-path or even off-path and here the effect does not seem to essentially differ from the problem you stated for best effort tagging, a loss of valid packets in an intermediate filter (in HA domain's firewall, for example). BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 04:18:11 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 EAA26634 for ; Fri, 8 Mar 2002 04:18: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 BAA02305; Fri, 8 Mar 2002 01:18:09 -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 BAA28960; Fri, 8 Mar 2002 01:18: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 g289GhKL012006 for ; Fri, 8 Mar 2002 01:16:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g289GgRV012005 for mobile-ip-dist; Fri, 8 Mar 2002 01:16: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 g289GdKL011998 for ; Fri, 8 Mar 2002 01:16:39 -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 BAA04823 for ; Fri, 8 Mar 2002 01:16:39 -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 BAA18184 for ; Fri, 8 Mar 2002 01:16:39 -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 BAA14524 for ; Fri, 8 Mar 2002 01:16:39 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g289Gck06092 for ; Fri, 8 Mar 2002 01:16:38 -0800 X-mProtect:  Fri, 8 Mar 2002 01:16:38 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdgbBQvS; Fri, 08 Mar 2002 01:16:36 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 BAA20738 for ; Fri, 8 Mar 2002 01:16:37 -0800 (PST) Message-ID: <3C888175.77514682@iprg.nokia.com> Date: Fri, 08 Mar 2002 01:16:37 -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] Text and proposal for piggybacking References: <3C8876A0.DAEB74CE@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 Hello, A correction: paragraph 5: - s/two new extension headers/two new headers/ - disclaimer: this text tries mostly reflect others' ideas on a possible simple compromise proposal where minimal change is needed (one negotiation signaling bit and one extra header type). Maybe one line of code is needed to hard-code the new transport number in the 2401 transport scan and an extra pointer to a protocol switch receiving a second header type to the mobility code of the first header type. An implementation not supporting these naturally zeroes its negotiation bit disallowing these for a complying peer. A non-compliant packet gets rejected if IPsec does not recognize the new transport due to finding an unknown protocol type not in its transport policies. - Ext. header placement could be after the destination option, final at the end, both immutable, and no more than one of them should exist in a packet. BR, -Jari > Hello folks, > > This text results from collaboration with Francis Dupont and Jari > Malinen, > who did most of the work. Together, we hope it will represent a > successful > effort to find the serviceable consensus that enables use of IPsec even > with restrictive interpretation about application of IPsec policy to > final > headers only. > > Regards, > Charlie P. > > ======================================================================= > > X.Y Piggybacking with IPsec > > This section describes when it is possible to piggyback mobility > options (BU/BACk and RR messages) while using IPsec and what an > implementation needs to do in both the sender and the receiver. > > Two new header types are needed: one extension header for > piggybacking, and one final header type used with IPsec. > Since the extension header with payload is not to be protected by > IPsec, > and the final header type is considered as transport, IPsec does not > have to be changed at all in any node, peer or intermediate. > Since these two headers are identical except for their type > number, the effect on mobility implementation is minimal. > > Interoperation in any case is secured by making piggybacking > a negotiable option. If node (HA, MN, or CN) can send and receive > piggybacked packets, it SHOULD initiate or respond in piggybacking > negotiation by setting the piggybacking flag in the mobility > signaling as enabled. Also, if the peer in the negotiation does > not enable its flag, or the node does not receive such a message, > the node MUST NOT piggyback. > > If IPsec is not used, an implementation can have a policy which > by default allows piggybacking, by means of static configuration. > Then the node can follow this static configuration and it SHOULD > enable its own piggybacking flag in the case the configuration is > set. If there is any non-IPsec reason why the node cannot piggyback, > this policy can be disabled by a management interface to the policy. > > In order to piggyback payload and mobility messages when IPsec > is in use, we have cases 1-4 in Table 1. Assuming the current > IPsec selectors [RFC 2401] and two new extension headers for > mobility signals, the node having IPsec policies (resulting in > an AH or ESP header) can piggyback in cases 1 and 2, that is, > when mobility signaling does not have an IPsec policy. > > Table 1. Piggybacking with IPsec > > IPsec policy for IPsec policy > Mobility Message for Payload Can piggyback > 1. no no yes > 2. no yes yes > 3. yes no no > 4. yes yes no > > In order for the mobility signaling to enforce this, the > mobility implementation of a sender needs to know whether mobility > signaling has a non-default policy. It can do this by constructing a > signaling packet, making the header type final and causing > a kernel IPsec policy lookup exactly like current kernel > IPsec does this for any packet. If no policy exists, the > final header type MAY be changed to the non-final extension, > indicating that this signal can be piggybacked. If a policy > was found, the final header type is used. > > A receiver does not need to have any knowledge of mobility > in its IPsec processing. The header type hard-codes > whether a policy even can exist, so if the header is final > and no policy, or a wrong policy exists, the packet will > be rejected anyway by IPsec. If the header is a non-final > extension header, the header type hard codes that > this signal cannot have an IPsec policy. Whether the > receiver accepts the extension signal depends on policy of the > non-IPsec protection. These policies or their interaction > with IPsec (re: bidding down or bidding aside prevention) > cannot be enforced by unmodified IPsec mechanisms. So > even with the non-final extension, mobility does not have > to be IPsec aware and vice versa. > > Piggybacking is not possible on case 3, due to processing > difficulties at both the sender and the receiver. The scan > for transport protocol field as described in RFC 2401 seems > to disallow this mode. For case 4, conflicting IPsec > policies would make it impossible to piggyback. > > Putting the above together, the sender MAY piggyback for the > cases 1 and 2 in Table 1 and MUST NOT piggyback for cases > 3 and 4. Equivalently, piggybacking is possible if and > only if there is no IPsec policy for protection of the > fields of the mobility signaling header. > > X.Z Which Mobility Signals to Piggyback > > An implementation sends piggyback when its negotiation > result with the peer allows and if it makes sense for > the mobility signal in question. > > Mobility signals include BR/BU/BAck and the RR messages. > Piggybacking of BR/BU/BAck messages between the MN and HA is very > rare. It can be done only when the payload belongs to a session > between the MN and HA. For piggybacking between MN and CN, > Table 2 describes when a mobility signal can be piggybacked. > > Table 2: Mobility Signals and Piggybacking (adapted from > Design Team's writeup with small changes) > > Message Sndr Rcvr Pig > > Binding Request CN MN Yes > Binding Update MN CN Yes > Binding Acknowledgment CN MN Yes > RR 1a MN CN Yes* > RR 1b MN CN Yes* > RR 2a CN MN Yes? > RR 2b CN MN No > > A (*) indicates that piggybacking would be sometimes possible > (details in the DT writeup). > > A (?) - cant it be piggybacked?? not sure. didnt quite understand > what the DT was trying to say about a 'rogue HA'. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 06:01: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 GAA28476 for ; Fri, 8 Mar 2002 06:01: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 DAA19140; Fri, 8 Mar 2002 03:01:29 -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 DAA02416; Fri, 8 Mar 2002 03:01: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 g28B0ZKL012169 for ; Fri, 8 Mar 2002 03:00:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28B0ZWB012168 for mobile-ip-dist; Fri, 8 Mar 2002 03:00: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 g28B0WKL012161 for ; Fri, 8 Mar 2002 03:00: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 DAA22523 for ; Fri, 8 Mar 2002 03:00:30 -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 EAA26055 for ; Fri, 8 Mar 2002 04:00:29 -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 g28B0TB14513 for ; Fri, 8 Mar 2002 12:00:29 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 11:36:51 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 11:36:51 +0100 Message-ID: From: "Karen E Nielsen (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Text and proposal for piggybacking Date: Fri, 8 Mar 2002 11:36:46 +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, > X.Z Which Mobility Signals to Piggyback > > An implementation sends piggyback when its negotiation > result with the peer allows and if it makes sense for > the mobility signal in question. > > Mobility signals include BR/BU/BAck and the RR messages. > Piggybacking of BR/BU/BAck messages between the MN and HA is very > rare. It can be done only when the payload belongs to a session > between the MN and HA. For piggybacking between MN and CN, > Table 2 describes when a mobility signal can be piggybacked. > > Table 2: Mobility Signals and Piggybacking (adapted from > Design Team's writeup with small changes) > > Message Sndr Rcvr Pig > > Binding Request CN MN Yes > Binding Update MN CN Yes > Binding Acknowledgment CN MN Yes > RR 1a MN CN Yes* > RR 1b MN CN Yes* > RR 2a CN MN Yes? > RR 2b CN MN No > > A (*) indicates that piggybacking would be sometimes possible > (details in the DT writeup). > > A (?) - cant it be piggybacked?? not sure. didnt quite understand > what the DT was trying to say about a 'rogue HA'. > I would like to stress that if, as recommended by the DT, the HA-MN tunnel should be encrypted for the RR messages and only for those, then the IPSEC selector must be able to detect these messages and hence RR 1a and RR 2a becomes definitive NO piggybacking (i.e. final protocol elements) - although no authentication is needed for the RR messages them selves. BR, Karen From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 06:57: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 GAA29540 for ; Fri, 8 Mar 2002 06:57:58 -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 EAA00063; Fri, 8 Mar 2002 04:57:55 -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 DAA03251; Fri, 8 Mar 2002 03:57: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 g28BuqKL012353 for ; Fri, 8 Mar 2002 03:56:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28BuqtQ012352 for mobile-ip-dist; Fri, 8 Mar 2002 03:56: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28BumKL012345 for ; Fri, 8 Mar 2002 03:56:48 -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 DAA03025 for ; Fri, 8 Mar 2002 03:56:48 -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 DAA18282 for ; Fri, 8 Mar 2002 03:56:46 -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 GAA29329; Fri, 8 Mar 2002 06:56:44 -0500 (EST) Message-Id: <200203081156.GAA29329@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-lmm-requirements-01.txt Date: Fri, 08 Mar 2002 06:56: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. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Localized Mobility Management Requirements for IPv6 Author(s) : C. Williams Filename : draft-ietf-mobileip-lmm-requirements-01.txt Pages : 13 Date : 07-Mar-02 This document describes requirements for Localized Mobility Management (LMM) for Mobile IPv6. These requirements are intended to guide the design of a protocol specification for LMMv6. Localized Mobility Management, in general introduces Local Mobility Agent functionality for proxying a Regional care of address that remains the same while the mobile node moves within a Local Mobility Domain, which reduces the binding update signaling latency and the signaling load outside the Local Mobility Domain. By its very nature LMM also serves as a mechanism to hide the Mobile Node's location from observers outside the administration domain (Local Mobility Domain). The identified requirements listed are essential for localized mobility management functionality. They are intended to be used as a guide for analysis on the observed benefits over the identified requirements for architecting and deploying LMM schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-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-ietf-mobileip-lmm-requirements-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-ietf-mobileip-lmm-requirements-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: <20020307115936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-lmm-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-lmm-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307115936.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 06:58: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 GAA29564 for ; Fri, 8 Mar 2002 06:58: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 EAA12820; Fri, 8 Mar 2002 04:58:03 -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 DAA03336; Fri, 8 Mar 2002 03:57: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 g28BukKL012343 for ; Fri, 8 Mar 2002 03:56:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28BukZQ012342 for mobile-ip-dist; Fri, 8 Mar 2002 03:56: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28BugKL012333 for ; Fri, 8 Mar 2002 03:56:42 -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 DAA02997 for ; Fri, 8 Mar 2002 03:56:42 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00566 for ; Fri, 8 Mar 2002 03:56:41 -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 GAA29317; Fri, 8 Mar 2002 06:56:39 -0500 (EST) Message-Id: <200203081156.GAA29317@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-aaa-key-09.txt Date: Fri, 08 Mar 2002 06:56:39 -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 : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, E. Gustafsson Filename : draft-ietf-mobileip-aaa-key-09.txt Pages : 25 Date : 07-Mar-02 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to create such security information at the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-09.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-aaa-key-09.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-aaa-key-09.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: <20020307115922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307115922.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 06:58: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 GAA29583 for ; Fri, 8 Mar 2002 06:58:07 -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 EAA12794; Fri, 8 Mar 2002 04:58: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 DAA03283; Fri, 8 Mar 2002 03:57: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 g28BuxKL012365 for ; Fri, 8 Mar 2002 03:56:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28BuxNQ012362 for mobile-ip-dist; Fri, 8 Mar 2002 03:56: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 g28BurKL012355 for ; Fri, 8 Mar 2002 03:56: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 DAA12283 for ; Fri, 8 Mar 2002 03:56:52 -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 DAA18311 for ; Fri, 8 Mar 2002 03:56:51 -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 GAA29344; Fri, 8 Mar 2002 06:56:49 -0500 (EST) Message-Id: <200203081156.GAA29344@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-rfc3012bis-01.txt Date: Fri, 08 Mar 2002 06:56:49 -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 : Mobile IPv4 Challenge/Response Extensions Author(s) : C. Perkins, E. Gustafsson Filename : draft-ietf-mobileip-rfc3012bis-01.txt Pages : 18 Date : 07-Mar-02 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-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: <20020307115951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc3012bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc3012bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307115951.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 06:58: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 GAA29638 for ; Fri, 8 Mar 2002 06:58: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 EAA12940; Fri, 8 Mar 2002 04:58: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 DAA03441; Fri, 8 Mar 2002 03:58: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 g28Bv6KL012373 for ; Fri, 8 Mar 2002 03:57:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28Bv6WC012372 for mobile-ip-dist; Fri, 8 Mar 2002 03:57: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 g28BuwKL012363 for ; Fri, 8 Mar 2002 03:56:59 -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 DAA12302 for ; Fri, 8 Mar 2002 03:56:58 -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 DAA18335 for ; Fri, 8 Mar 2002 03:56:56 -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 GAA29356; Fri, 8 Mar 2002 06:56:54 -0500 (EST) Message-Id: <200203081156.GAA29356@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-reg-tunnel-06.txt Date: Fri, 08 Mar 2002 06:56:54 -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 : Mobile IPv4 Regional Registration Author(s) : E. Gustafsson, A. Jonsson, C. Perkins Filename : draft-ietf-mobileip-reg-tunnel-06.txt Pages : 38 Date : 07-Mar-02 Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a new kind of 'regional' registration, i.e., registration local to the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-reg-tunnel-06.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-reg-tunnel-06.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-reg-tunnel-06.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: <20020307120006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-reg-tunnel-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-reg-tunnel-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020307120006.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 09:06: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 JAA05508 for ; Fri, 8 Mar 2002 09:06: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 HAA26670; Fri, 8 Mar 2002 07:06: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 GAA28527; Fri, 8 Mar 2002 06:06: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 g28E5sKL012776 for ; Fri, 8 Mar 2002 06:05:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28E5sxl012775 for mobile-ip-dist; Fri, 8 Mar 2002 06:05: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 g28E5pKL012768 for ; Fri, 8 Mar 2002 06:05:51 -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 GAA27566 for ; Fri, 8 Mar 2002 06:05:52 -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 HAA12233 for ; Fri, 8 Mar 2002 07:05:51 -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 g28E5nL22463 for ; Fri, 8 Mar 2002 08:05:49 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 08:05:53 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCA8F@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-01.txt Date: Fri, 8 Mar 2002 08:05:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C6AA.5B4F05D0" Sender: owner-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_01C1C6AA.5B4F05D0 Content-Type: text/plain; charset="iso-8859-1" Hi; I thought the authors for the RFC3012-bis are C. Perkins and P. Calhoun. Regards; Ahmad Muhanna -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, March 08, 2002 5:57 AM Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-01.txt 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 : Mobile IPv4 Challenge/Response Extensions Author(s) : C. Perkins, E. Gustafsson Filename : draft-ietf-mobileip-rfc3012bis-01.txt Pages : 18 Date : 07-Mar-02 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-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_001_01C1C6AA.5B4F05D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] I-D = ACTION:draft-ietf-mobileip-rfc3012bis-01.txt

Hi;
I thought the authors for the RFC3012-bis are C. = Perkins and P. Calhoun.

Regards;

Ahmad Muhanna

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Friday, March 08, 2002 5:57 AM
Cc: mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] I-D = ACTION:draft-ietf-mobileip-rfc3012bis-01.txt


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           : = Mobile IPv4 Challenge/Response Extensions
        Author(s)       : C. Perkins, E. = Gustafsson
        Filename        : = draft-ietf-mobileip-rfc3012bis-01.txt
        Pages           : = 18
        Date    =         : 07-Mar-02
       =20
Mobile IP, as originally specified, defines an = authentication
extension (the Mobile-Foreign Authentication = extension) by
which a mobile node can authenticate itself to a = foreign agent.
Unfortunately, this extension does not provide = ironclad replay
protection for the foreign agent, and does not allow = for the use
of existing techniques (such as CHAP) for = authenticating portable
computer devices.  In this specification, we = define extensions for
the Mobile IP Agent Advertisements and the = Registration Request
that allow a foreign agent to use a = challenge/response mechanism to
authenticate the mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mobilei= p-rfc3012bis-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-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-01.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

------_=_NextPart_001_01C1C6AA.5B4F05D0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 10:08: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 KAA08781 for ; Fri, 8 Mar 2002 10:07: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 IAA01514; Fri, 8 Mar 2002 08:06:55 -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 HAA18798; Fri, 8 Mar 2002 07:06: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 g28F4nKL012914 for ; Fri, 8 Mar 2002 07:04:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28F4nG4012913 for mobile-ip-dist; Fri, 8 Mar 2002 07:04: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 g28F4jKL012906 for ; Fri, 8 Mar 2002 07:04:45 -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 HAA05157 for ; Fri, 8 Mar 2002 07:03: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 HAA22818 for ; Fri, 8 Mar 2002 07:03: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 HAA27225; Fri, 8 Mar 2002 07:02:15 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g28F10j19865; Fri, 8 Mar 2002 07:01:00 -0800 X-mProtect:  Fri, 8 Mar 2002 07:01:00 -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 smtpdbjpO3t; Fri, 08 Mar 2002 07:00:58 PST Message-ID: <3C88D1C2.2FA6CBB6@iprg.nokia.com> Date: Fri, 08 Mar 2002 06:59: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: Mobile IP Working Group CC: Ahmad Muhanna , Pat Calhoun Subject: [Fwd: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-01.txt] 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, The authorship on the Internet Draft is correct, regardless of what this announcement indicates. Regards, Charlie P. -------- Original Message -------- Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-01.txt Date: Fri, 8 Mar 2002 08:05:52 -0600 From: "Ahmad Muhanna" Reply-To: mobile-ip@sunroof.eng.sun.com To: "'mobile-ip@sunroof.eng.sun.com'" Hi; I thought the authors for the RFC3012-bis are C. Perkins and P. Calhoun. Regards; Ahmad Muhanna -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, March 08, 2002 5:57 AM Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-01.txt 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 : Mobile IPv4 Challenge/Response Extensions Author(s) : C. Perkins, E. Gustafsson Filename : draft-ietf-mobileip-rfc3012bis-01.txt Pages : 18 Date : 07-Mar-02 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-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-ietf-mobileip-rfc3012bis-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. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 11:07: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 LAA12323 for ; Fri, 8 Mar 2002 11:07: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 JAA11521; Fri, 8 Mar 2002 09:07: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 IAA25257; Fri, 8 Mar 2002 08:07: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 g28G6hKL013077 for ; Fri, 8 Mar 2002 08:06:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28G6h30013076 for mobile-ip-dist; Fri, 8 Mar 2002 08:06: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 g28G6eKL013069 for ; Fri, 8 Mar 2002 08:06: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 IAA25028 for ; Fri, 8 Mar 2002 08:06:39 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10895 for ; Fri, 8 Mar 2002 09:06:38 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g28G61313581 for ; Fri, 8 Mar 2002 18:06:01 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 8 Mar 2002 18:06:36 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 18:06:36 +0200 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:06:14 -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] Conclusion and Recommendation for unverified HAO Processing Date: Fri, 8 Mar 2002 10:06:14 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1295F@daebe007.NOE.Nokia.com> Thread-Topic: Conclusion and Recommendation for unverified HAO Processing Thread-Index: AcHGuywc14r/HzKnEdaxqQAAhj/HZA== To: X-OriginalArrivalTime: 08 Mar 2002 16:06:14.0559 (UTC) FILETIME=[2C2FAAF0:01C1C6BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g28G6eKL013070 Sender: owner-mobile-ip@sunroof.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 unverified home address option processing proposal has been discussed on the mailing list over the last few days. The conclusion is that while the proposed tagging mechanism provides traceability, filtering when tagging is used is not yet clearly understood. Hence the recommendation in order to make progress is as follows: The base Mobile IPv6 specification will take the following approach: - CNs must not process packets with Unverified HAO - A CN must send an error response to a MN sending packets with unverified HAO , indicating its inability to process such packets by sending an error message specified in the base draft. * This error mechanism should be extensible so that different types of error notification can be added e.g. when unvHAO support is specified. - With future extensions and specification, MNs may optimistically send packets with unverified HAO to a CN, but on receiving an error response, MNs must resort to bidirectional tunnelling to send packets to the CN. With this approach triangle routing is not completely eliminated from Mobile IPv6. It leaves the door open for a future specification that can specify the rules for a CN to process packets with unverified HAO. When such a specification is available and standardised by the Mobile IP WG: - CNs must/should process packets with unverified HAO (under the rules defined) - MNs that send packets with unverified HAO to a CN will not receive an error response from such CNs -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 11:14: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 LAA12747 for ; Fri, 8 Mar 2002 11:14: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 IAA16525; Fri, 8 Mar 2002 08:14: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 IAA27630; Fri, 8 Mar 2002 08:14: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 g28GDhKL013168 for ; Fri, 8 Mar 2002 08:13:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28GDhY2013167 for mobile-ip-dist; Fri, 8 Mar 2002 08:13: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 g28GDeKL013160 for ; Fri, 8 Mar 2002 08:13: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 IAA29520 for ; Fri, 8 Mar 2002 08:13:40 -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 IAA03333 for ; Fri, 8 Mar 2002 08:13:38 -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 g28GDbB20150 for ; Fri, 8 Mar 2002 17:13:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 17:12:53 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 17:03:04 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAA8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note Date: Fri, 8 Mar 2002 17:02: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: > And also, questioning the more harm argument, > comparing to non-mobility case, there could be similar > off-path attacks (attacker just inserting an arbitrary > spoofed address to IPhdr source) if/since there can be > places/paths where we do not have Martian filtering > (ingress filtering from addresses coming from > topologically "wrong" directions) verifiably on > every path an attacker could use. => Well, the 'do no harm' argument is based on certain assumptions (existing preventative mechanisms today). when comparing two solutions we have to keep the assumptions fixed. In the statement above you are changing these assumptions by saying that 'ingress filtering may not be available' and based on that you claim that off-path attacks are possible today. Which seems to me like changing the original problem being solved. Am I missing something? Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 11:56: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 LAA16328 for ; Fri, 8 Mar 2002 11:56: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 JAA06917; Fri, 8 Mar 2002 09:56: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 IAA10238; Fri, 8 Mar 2002 08:55: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 g28GspKL013283 for ; Fri, 8 Mar 2002 08:54:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28GspU1013282 for mobile-ip-dist; Fri, 8 Mar 2002 08:54: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 g28GslKL013275 for ; Fri, 8 Mar 2002 08:54: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 IAA24774 for ; Fri, 8 Mar 2002 08:54:47 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02403 for ; Fri, 8 Mar 2002 08:54:46 -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 g28GsjZc016396 for ; Fri, 8 Mar 2002 17:54:45 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 17:54:42 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 17:54:42 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAAC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'manet@ietf.org'" , ipng@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MONET BOF Date: Fri, 8 Mar 2002 17:50: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: Hi all, Sorry if you receive multiple copies of this. This is an announcement of the MONET BOF. All the necessary information can be found at: http://www.ietf.org/ietf/02mar/monet.txt. We look forward to your participation. Thierry Ernst Hesham Soliman From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 13:26: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 NAA22352 for ; Fri, 8 Mar 2002 13:25: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 KAA19044; Fri, 8 Mar 2002 10:25: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 KAA09592; Fri, 8 Mar 2002 10:25: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 g28IOQKL013434 for ; Fri, 8 Mar 2002 10:24:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28IOQEa013433 for mobile-ip-dist; Fri, 8 Mar 2002 10:24: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 g28IONKL013426 for ; Fri, 8 Mar 2002 10:24:23 -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 KAA18991 for ; Fri, 8 Mar 2002 10:24:22 -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 LAA15438 for ; Fri, 8 Mar 2002 11:24: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 KAA08211 for ; Fri, 8 Mar 2002 10:24:20 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g28IOJH12294 for ; Fri, 8 Mar 2002 10:24:19 -0800 X-mProtect:  Fri, 8 Mar 2002 10:24:19 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdfZ65Rg; Fri, 08 Mar 2002 10:24: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 KAA21560 for ; Fri, 8 Mar 2002 10:24:18 -0800 (PST) Message-ID: <3C8901D2.C92552C@iprg.nokia.com> Date: Fri, 08 Mar 2002 10:24:18 -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] CLARIFICATION: Unverified HAO Processing - Recommendation note References: <4DA6EA82906FD511BE2F00508BCF053802C6AAA8@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: > > > And also, questioning the more harm argument, > > comparing to non-mobility case, there could be similar > > off-path attacks (attacker just inserting an arbitrary > > spoofed address to IPhdr source) if/since there can be > > places/paths where we do not have Martian filtering > > (ingress filtering from addresses coming from > > topologically "wrong" directions) verifiably on > > every path an attacker could use. > > => Well, the 'do no harm' argument is based on certain > assumptions (existing preventative mechanisms > today). when comparing two solutions we have to keep > the assumptions fixed. In the statement above you > are changing these assumptions by saying that > 'ingress filtering may not be available' and based > on that you claim that off-path attacks are possible > today. Which seems to me like changing the original > problem being solved. Am I missing something? If any path has filtering not available/enabled, off path attacks can be possible. But this is beside the point, changing assumptions would mean dismissing the need for the firewalls to block HAO-reflected traffic. The issue was about the difference in filtering effect when using a rule resulting in both attacker's and victim's packets getting dropped. With non-mobility packets having source spoofed address this clearly can happen in some cases. The case for best-effort tagging-based filtering is also an extreme one (cf. earlier mail). The do-no-harm argument is whether tagging-based filtering is significantly worse from the level of security provided by ingress filtering in a firewall for non-mobility packets. Best effort tagging provides an alternative source of information for filtering which is not exact but the level of precision in non-mobility filtering is not exact either, hence a need for clarification what is significantly worse with this particular issue. > Hesham BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 14:05: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 OAA25441 for ; Fri, 8 Mar 2002 14:04: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 LAA27349; Fri, 8 Mar 2002 11:04: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 LAA23559; Fri, 8 Mar 2002 11:04: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 g28J3YKL013647 for ; Fri, 8 Mar 2002 11:03:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28J3Y8r013646 for mobile-ip-dist; Fri, 8 Mar 2002 11:03: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28J3UKL013639 for ; Fri, 8 Mar 2002 11:03:30 -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 LAA00958 for ; Fri, 8 Mar 2002 11:03:29 -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 MAA26173 for ; Fri, 8 Mar 2002 12:03:28 -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 LAA10549; Fri, 8 Mar 2002 11:02:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g28J2r112933; Fri, 8 Mar 2002 11:02:53 -0800 X-mProtect:  Fri, 8 Mar 2002 11:02:53 -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 smtpdKLJMHt; Fri, 08 Mar 2002 11:02:51 PST Message-ID: <3C890ADB.10A23CAD@iprg.nokia.com> Date: Fri, 08 Mar 2002 11:02:52 -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: Internet Drafts , "Pat R. Calhoun" Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-09.txt References: <200203081156.GAA29317@ietf.org> 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 with rfc3012bis, the authorship on this should be myself and Pat Calhoun, not Eva Gustafsson. I don't know why this happened, because it was correctly attributed in my note to the Internet Drafts folks, and it's correct in the draft. Regards, Charlie P. Internet-Drafts@ietf.org wrote: > > 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 : AAA Registration Keys for Mobile IP > Author(s) : C. Perkins, E. Gustafsson > Filename : draft-ietf-mobileip-aaa-key-09.txt > Pages : 25 > Date : 07-Mar-02 > > AAA servers, such as RADIUS and DIAMETER, are in use within the > Internet today to provide authentication and authorization services > for dial-up computers. Mobile IP requires strong authentication > between the mobile node and its home agent. When the mobile node > shares a security association with its home AAA server, however, it > is possible to use that security association to create derivative > security associations between the mobile node and its home agent, > and again between the mobile node and the foreign agent currently > offering connectivity to the mobile node. This document specifies > extensions to the Mobile IP Registration Reply packet that can be > used to create such security information at the mobile node. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-09.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-aaa-key-09.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-aaa-key-09.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. > > -------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20020307115922.I-D@ietf.org> From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 8 19:34: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 TAA13427 for ; Fri, 8 Mar 2002 19:34:49 -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 QAA25714; Fri, 8 Mar 2002 16:34:46 -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 QAA01906; Fri, 8 Mar 2002 16:34: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 g290XaKL014042 for ; Fri, 8 Mar 2002 16:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g290Xa5K014041 for mobile-ip-dist; Fri, 8 Mar 2002 16:33: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 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 g290XYKL014034 for ; Fri, 8 Mar 2002 16:33:35 -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 TAA06452 for ; Fri, 8 Mar 2002 19:33:35 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA11711 for mobile-ip@sunroof.eng.sun.com; Fri, 8 Mar 2002 19:34:26 -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 g27J8wKL010038 for ; Thu, 7 Mar 2002 11:08:58 -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 LAA09997 for ; Thu, 7 Mar 2002 11:08:58 -0800 (PST) Received: from tahi-200.Connectathon.ORG ([130.128.68.200]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18459 for ; Thu, 7 Mar 2002 12:08:53 -0700 (MST) Received: from tahi-200.Connectathon.ORG (localhost [127.0.0.1]) by tahi-200.Connectathon.ORG (8.11.6/8.11.6) with SMTP id g27J91G00987 for ; Fri, 8 Mar 2002 04:09:01 +0900 (JST) (envelope-from Yukiyo.Akisada@jp.yokogawa.com) Date: Fri, 8 Mar 2002 04:09:01 +0900 From: Yukiyo Akisada To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] about proxy DAD Message-Id: <20020308040901.37b62f17.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.7.2 (GTK+ 1.2.10; i386-unknown-freebsd4.4) Mime-Version: 1.0 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. I have some quiestions about proxy DAD. When the MN sends BU (S bit is 0), should HA execute DAD for only MN's link-local home address? or both of link-local and global addess? And when the MN sends BU (S bit is 1), should HA execute DAD for only global address? or not? ID-15 chapter 9.1 says that - Finally, if the Duplicate Address Detection (D) bit is set in the Binding Update, this home agent MUST perform Duplicate Address Detection [27] on the mobile node's home link for the home address in this binding (before returning the Binding Acknowledgement). The address used for Duplicate Address Detection SHOULD be the mobile node's link-local address. and If the `S' bit field in the Binding Update is zero, The Home Agent creates or updates Binding Cache entries for each of possible several home addresses. The set of such home addresses is formed by replacing the routing prefix for the given home address with all other routing prefixes that are supported by the home agent processing the Binding Update. The Home Agent creates such a separate primary care-of address registration for each such home address. Note that the same considerations for Duplicate Address Detection apply for each affected home address. I'm little confusing about this. Regards. ---- Yukiyo Akisada @ TAHI Project From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 03:51: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 DAA01838 for ; Mon, 11 Mar 2002 03:51: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 AAA14454; Mon, 11 Mar 2002 00:51: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 AAA05229; Mon, 11 Mar 2002 00:50: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 g2B8nXKL016817 for ; Mon, 11 Mar 2002 00:49:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2B8nX6M016816 for mobile-ip-dist; Mon, 11 Mar 2002 00:49: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 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 g2B8nTKL016809 for ; Mon, 11 Mar 2002 00:49:29 -0800 (PST) Received: from lillen (vpn-129-159-0-19.EMEA.Sun.COM [129.159.0.19]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2B8nEx27263; Mon, 11 Mar 2002 09:49:14 +0100 (MET) Date: Mon, 11 Mar 2002 09:43:59 +0100 (CET) From: Erik Nordmark Subject: Re: CLARIFICATION: [mobile-ip] Unverified HAO Processing - Recommendation note To: rajeev@iprg.nokia.com Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C87B04F.AA95ABBA@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: > how about, > > customer = an entity supporting HA/MN ? The customer has an ISP (or is an > ISP himself/herself) who interacts with another ISP. The same case above > holds. Correct me if I am missing something.. > > > > > But there isn't a business relationship between me and all CNs in the world. > > > > You are a customer to some ISP and the CN is a customer to some other > (or same) ISP. Isn't this generally the case ? Rajeev, My point, which I don't seem to be able to communicate clearly, is that during todays DoS and DDoS attacks the actions taken to do manual traceback and filtering can follow the business relationships one "hop" at a time. Customer asks its ISP. That ISP asks its upstream ISPs. An ISP asks its transit provider. I seem to be saying that there is a transitive closure of business relationships and I agree that such a transitive closure exists and would encompass mosts IP nodes in the Internet. But I don't see how the transitive closure helps - each "hop" along the path today requires people evaluating the legitimacy of requests to traceback and/or filter before they pass it along to the next "hop" is the chain of relationships. Is that more clear? If not perhaps we should talk about this on the phone. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 04:35:12 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 EAA02625 for ; Mon, 11 Mar 2002 04:35:11 -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 CAA07591; Mon, 11 Mar 2002 02:35: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 BAA08794; Mon, 11 Mar 2002 01:35: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 g2B9Y8KL016969 for ; Mon, 11 Mar 2002 01:34:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2B9Y8Zf016968 for mobile-ip-dist; Mon, 11 Mar 2002 01:34: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 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 g2B9Y4KL016961 for ; Mon, 11 Mar 2002 01:34:04 -0800 (PST) Received: from lillen (vpn-129-159-0-19.EMEA.Sun.COM [129.159.0.19]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2B9Xtx01203; Mon, 11 Mar 2002 10:33:58 +0100 (MET) Date: Mon, 11 Mar 2002 10:28:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C87BCD7.9E30BD5B@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: Charlie, A few comments. > It could be that, under attack, reverting to reverse tunneling > would be a useful strategy. Instead of "clock skew", it would more > precisely be a problem only with skewed clock rates. I think the term is "clock drift". The protocol can easily be designed to handle a maximum difference in drift. For instance, if we assume that the drift difference will be less that 4% (around 1 hour per day - I assume most systems have much less) then the MN just needs to time out its notion of the CN having a BCE in .96 times the actual lifetime value passed in the protocol. Protocols like DHCP effectively already do this - make sure the address is refreshed quite a while before the lifetime says it will expire. So this is a no-brainer. > This is introducing a need for a lot more signaling (approximately > double what unacknowledged Binding Update would require). I had > always thought it was a good feature of Mobile IPv6 that we should > be able to avoid that. Without a BAck the RR scheme has 5 packets. With a BAck 6. Hardly twice as much. And if we need a BAck to make the protocol both secure and robust against packet loss, what option do we have? > The probability of packet loss is zero, unless a node is under > attack. The probability of attack is low, and the attacker is > traceable. I am hoping that most HAOs will be verifiable, and I > am proposing that we allow some of them to be acceptable, and > tagged, prior to the moment when they are verifiable. Assuming an infinite size unvHAO cache this is true. I don't think computers/devices can be built so that they will never run out of a particular resource unless they live in a completely predictable environment. Connecting to the network makes the environment no longer completely predictable. Thus CNs will run out of unvHAO space even during non-attack scenarios. Carefully engineering of the CN will presumably limit the cases during which this happens, but it be a non-zero probability event. Thus I agree with your claim above. Also, since we'd like the protocol to behave reasonably even during attack it would seem prudent to think about the added loss caused by the unvHAO cache being full. > >> I didn't think it was very confusing! But you are right, that this > >> effort to avoid harm is concerned with performance and robustness, > >> at no cost in security. > > > > Are you trying to put words in my mouth? > > Erik, I am not trying to subvert your message. The last clause is mine, > and I _thought_ the previous clause was implied by your statement. > You can tell me I was wrong about my inference, but please don't > make out like I am arguing unethically. I didn't say there was anything unethical. I pointed out that by you stating "but you are right, ..." you seem to say that I had said "at no cost in security" which I never said and never intended to say. This space is full of traceoffs between security, robustness, and performance. Thus I think that all three need to be taken into account. Your statement seemed to imply that I didn't think security mattered here which is what made be react. > > I think there are huge security problems caused by unvHAO. > > I think the problems are really microscopic! Time to agree that we disagree and move on. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 04:45: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 EAA02746 for ; Mon, 11 Mar 2002 04:45:04 -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 BAA24085; Mon, 11 Mar 2002 01:45:05 -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 BAA10341; Mon, 11 Mar 2002 01:44: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 g2B9iFKL017061 for ; Mon, 11 Mar 2002 01:44:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2B9iEkV017060 for mobile-ip-dist; Mon, 11 Mar 2002 01:44: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 g2B9iAKL017053 for ; Mon, 11 Mar 2002 01:44:11 -0800 (PST) Received: from lillen (vpn-129-159-0-19.EMEA.Sun.COM [129.159.0.19]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2B9i6x02137; Mon, 11 Mar 2002 10:44:07 +0100 (MET) Date: Mon, 11 Mar 2002 10:38:49 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: "Jari T. Malinen" Cc: mobile-ip@sunroof.eng.sun.com, "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli In-Reply-To: "Your message with ID" <3C880D8A.5420AC59@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, > - On robustness: both verified and unverified caches are in reality > finite in size. Both would have a similar error mechanism > anyway so there is hardly a difference in robustness in > RO-BC or unverified cache filling up. With the latter you > may lose some packets in transit, but also with the former, > it is just a cache and may get destroyed before or without > new BU reaching the CN. In a worst case a RO data packet may > be on path and get dropped in such a gap. This should not > be a real argument. The above should not be a real argument :-) :-) Seriously, I think there is a big difference between the case when the CN reboots and losses all state (including transport and application state) i.e. looses the BCE state compared to the unvHAO idea of effectively doing "send and prey" that an unvHAO entry can be created on the CN. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 04:53: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 EAA02845 for ; Mon, 11 Mar 2002 04:53: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 BAA25475; Mon, 11 Mar 2002 01:53: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 BAA11389; Mon, 11 Mar 2002 01:53: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 g2B9qfKL017140 for ; Mon, 11 Mar 2002 01:52:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2B9qf1j017139 for mobile-ip-dist; Mon, 11 Mar 2002 01:52: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 g2B9qcKL017132 for ; Mon, 11 Mar 2002 01:52:38 -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 BAA14785 for ; Mon, 11 Mar 2002 01:52:39 -0800 (PST) Received: from 3gpp2.net ([128.121.13.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18860 for ; Mon, 11 Mar 2002 01:52:38 -0800 (PST) Received: from dell8100rjm ([61.214.229.150]) by 3gpp2.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 11 Mar 2002 04:50:03 -0500 From: "Robert J Marks" To: Subject: [mobile-ip] rfc 3220: exactly one "authorization enabling extension" Date: Mon, 11 Mar 2002 03:52:19 -0600 Organization: Marks Mobile Consulting Message-ID: <000501c1c8e2$70441a40$a9f20a0a@dell8100rjm> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C1C8B0.25A9AA40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 11 Mar 2002 09:50:03.0453 (UTC) FILETIME=[1DFF76D0:01C1C8E2] Sender: owner-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_0006_01C1C8B0.25A9AA40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RFC 3220 states in section 3.5.2 that "Exactly one authorization-enabling extension MUST be present in all Registration Requests, ..." Although this appears to prohibit a Registration Request that contains both a Mobile-Home Authentication Extension and a MN-AAA Authentication Extension, perhaps there is a way to allow both to be present. Perhaps RFC 3220 meant that: 1. When there is only one of the two in the Registration Request, then the extension that is present is the authorization-enabling extension. 2. When both are present, then the Mobile-Home Authentication extension is the authorization-enabling extension, and the MN-AAA Authentication extension is not considered authorization-enabling. Can this work? Bob ------=_NextPart_000_0006_01C1C8B0.25A9AA40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
RFC 3220=20 states in section 3.5.2 that "Exactly one=20 authorization-enabling
extension=20 MUST be present in all Registration = Requests, ..."
Although=20 this appears to prohibit a Registration Request that=20 contains
both a=20 Mobile-Home Authentication Extension and a MN-AAA=20 Authentication
Extension, perhaps there is a way to = allow both to=20 be present.
 
Perhaps RFC=20 3220 meant that:
1. When there is only one of the = two in the=20 Registration Request, then
   the extension that is = present is the=20 authorization-enabling extension.
2. When both=20 are present, then the Mobile-Home Authentication = extension
  =20 is the authorization-enabling extension, and the MN-AAA=20 Authentication
  =20 extension is not considered authorization-enabling.
 
Can this=20 work?
 
Bob
 
------=_NextPart_000_0006_01C1C8B0.25A9AA40-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 05:00: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 FAA02970 for ; Mon, 11 Mar 2002 05:00:13 -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 CAA26848; Mon, 11 Mar 2002 02:00: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 CAA12329; Mon, 11 Mar 2002 02:00: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 g2B9xLKL017207 for ; Mon, 11 Mar 2002 01:59:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2B9xL3n017206 for mobile-ip-dist; Mon, 11 Mar 2002 01:59: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 g2B9xHKL017199 for ; Mon, 11 Mar 2002 01:59:17 -0800 (PST) Received: from lillen (vpn-129-159-0-19.EMEA.Sun.COM [129.159.0.19]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2B9xDx03620; Mon, 11 Mar 2002 10:59:13 +0100 (MET) Date: Mon, 11 Mar 2002 10:53:56 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli In-Reply-To: "Your message with ID" <3C887B3D.C0CE4A67@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: > > > I think there are huge security problems caused by unvHAO. > > Since in today's discussion this was not exactly stated, > and I assume by unvHAO you here also include unvHAO when > the tagging method is used, I'd like to hear more of these > particular problems. Even if best effort tagging is used, > the only concrete security issue in the best effort > tagging proposal that I heard, was for this limited > case: Jari, sorry for being inexact - the unvHAO name has been used for the proposal to do best effort tagging but I realize this isn't necessarily the only case. So my statement applies to unvHAO handling using best-effort tagging. Using exact tagging (where every "response packet" is tagged with the IP source address in the corresponding "request packet") seems to avoid these security issues at the expensive of additional implementation complexity which needs to cross the API and effect UDP applications. I think I've expressed my security concerns several times on the list already. Do I need to repeat them? > - with tags and response packets being out of sync, right > packets may get wrong tags and vice versa making tag-based > filtering drop wrong packets and pass right packets. > > But: any filter in and after CN can still drop both, > based on the destination address, for example, if > we drop both right and wrong packets to this HoA. Yes, but that will then effect the legimate traffic. The goal of handling DoS attacks is to maximize the number of bad packets being filtered while minimizing the effect on legitimate traffic. With reflection it isn't always possible to avoid effect on legitimate packets as Vern's paper (in DT writeups) point out. But what you propose above makes MIPv6 cause additional causes where filtering can not be very exact. > Also, given the timer range behavior with the unverified > HAO cache, and unpredictability of the reflecting > application, attack packets can be entered only > momentarily, which makes it hard to find those > moments due to randomized timeout ranges. Huh? Are you talking about the case when one entitity (attacker or good guy) is using HAO and the other isn't? Or the case when both are using HAO? The latter is the place with the most problems. > Could you help me to see where the added harm is? > It is unclear to me how the above issue effectively > differs from the case non-mobility attack packets have > a spoofed source address and get to be filtered along > with victim's traffic from the same source address? Think of case with some ingress filtering (but never perfect) that will prevent arbitrary source address spoofing. Add attackers doing DoS and the need to filter those out close to where the pain is being felt (and the CN might not feel any pain from such an attack). Erik > These can be launched on-path or even off-path and > here the effect does not seem to essentially differ from > the problem you stated for best effort tagging, a loss of > valid packets in an intermediate filter (in HA domain's > firewall, for example). > > BR, > > -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 06:42: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 GAA05208 for ; Mon, 11 Mar 2002 06:41: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 EAA09623; Mon, 11 Mar 2002 04:41: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 DAA21684; Mon, 11 Mar 2002 03:41: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 g2BBedKL017448 for ; Mon, 11 Mar 2002 03:40:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BBedbi017447 for mobile-ip-dist; Mon, 11 Mar 2002 03:40: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 g2BBeZKL017440 for ; Mon, 11 Mar 2002 03:40:36 -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 DAA06361 for ; Mon, 11 Mar 2002 03:40:35 -0800 (PST) Received: from mx03.melco.co.jp (mx.melco.co.jp [192.218.140.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20629 for ; Mon, 11 Mar 2002 04:40:33 -0700 (MST) Received: by mx03.melco.co.jp (mx03) id UAA25880; Mon, 11 Mar 2002 20:40:31 +0900 (JST) Received: by mr02.melco.co.jp (mr02) id UAA08395; Mon, 11 Mar 2002 20:40:30 +0900 (JST) Received: from elmail by elgw.isl.melco.co.jp (8.8.8/3.6W) id UAA08790; Mon, 11 Mar 2002 20:40:30 +0900 (JST) Received: from kshtishi (axe.isl.melco.co.jp [10.74.8.166]) by elmail.isl.melco.co.jp (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001)) with SMTP id <0GST00CP44FHGC@elmail.isl.melco.co.jp>; Mon, 11 Mar 2002 20:40:29 +0900 (JST) Date: Mon, 11 Mar 2002 20:39:52 +0900 From: Koichi Ishibashi Subject: [mobile-ip] Behavior of a mobility agent in order to manage the flow To: mobile-ip@sunroof.eng.sun.com Cc: Koichi Ishibashi Message-id: <009901c1c8f1$75728ec0$a6084a0a@isl.melco.co.jp> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: 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 all, We wrote a draft about behavior of a mobility agent in order to apply different handoff mechanisms to individual flows, a few months ago. http://www.ietf.org/internet-drafts/draft-ishi-mobileip-behavior-ma-00.txt . We have received few comments. However, we'd like to start a discussion of the subject. Our draft aims at bringing up a problem that a mobility agent should apply different handoff mechanisms to individual flows according to an implicit or explicit configuration. Mobile IP is known to a protocol that deals solely with terminal mobility. In Mobile IP and its proposed extensions, when a mobile node, that has multiple connections (flows) simultaneously, moves between networks, a handoff mechanism is applied to the terminal$B!G(Bs movement. Even if each connection (flow) may request its own distinctive QoS, all connections (flows) will go through same interruption of services and jitters due to the handoffs. So we propose that a mobility agent should apply different handoff mechanisms to each connection (flow) according to the requested QoS. We are assuming that it will be necessary to support a QoS mechanism and mobility agents should support the QoS mechanism in a future mobile network. And we think we need to clarify behavior of the mobility agent when it supports more than one handoff mechanism in order to assure a QoS attribute when the mobile node moves. We look forward to receiving your comments. And if I miss something, please forgive my ignorance and let me know. Ishibashi From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 07:18: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 HAA05807 for ; Mon, 11 Mar 2002 07:18:27 -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 FAA03984; Mon, 11 Mar 2002 05:18: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 EAA12939; Mon, 11 Mar 2002 04:18: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 g2BCHZKL017696 for ; Mon, 11 Mar 2002 04:17:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BCHZAi017695 for mobile-ip-dist; Mon, 11 Mar 2002 04:17: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 g2BCHWKL017688 for ; Mon, 11 Mar 2002 04:17:32 -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 EAA10726 for ; Mon, 11 Mar 2002 04:17:31 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22789 for ; Mon, 11 Mar 2002 05:17:31 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id CC69B2E54; Mon, 11 Mar 2002 07:17:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Mar 2002 07:17:30 -0500 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] CLARIFICATION: Unverified HAO Processing - Recommendation note Date: Mon, 11 Mar 2002 07:17:30 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520848@tayexc13.americas.cpqcorp.net> Thread-Topic: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note Thread-Index: AcHI4aHW/CsGecECRNuevjHDsh6TPQAFKkjQ From: "Bound, Jim" To: , "Jari T. Malinen" Cc: "Charles E. Perkins" , "Rajeev Koodli" X-OriginalArrivalTime: 11 Mar 2002 12:17:30.0735 (UTC) FILETIME=[B7638FF0:01C1C8F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2BCHWKL017689 Sender: owner-mobile-ip@sunroof.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, Come on I don't think your being "fair" we both ship web servers that deal with 10 million hits in a very short time any CN that is supporting serious Mobile IPv6 is not going to run into this caching problem as the norm. Thats an absurd and sophist argument philosophically (Plato's sophism). It is not a technical argument but a technical assumption. I don't agree with either. Also the servers that do OLTP is even more intense than the web server case. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, March 11, 2002 4:39 AM > To: Jari T. Malinen > Cc: mobile-ip@sunroof.eng.sun.com; Charles E. Perkins; Erik Nordmark; > Rajeev Koodli > Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - > Recommendation note > > > Jari, > > > - On robustness: both verified and unverified caches are in reality > > finite in size. Both would have a similar error mechanism > > anyway so there is hardly a difference in robustness in > > RO-BC or unverified cache filling up. With the latter you > > may lose some packets in transit, but also with the former, > > it is just a cache and may get destroyed before or without > > new BU reaching the CN. In a worst case a RO data packet may > > be on path and get dropped in such a gap. This should not > > be a real argument. > > The above should not be a real argument :-) :-) > > Seriously, > I think there is a big difference between the case when the CN reboots > and losses all state (including transport and application > state) i.e. looses > the BCE state compared to the unvHAO idea of effectively > doing "send and prey" that an unvHAO entry can be created on the CN. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 17:03: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 RAA26877 for ; Mon, 11 Mar 2002 17:03: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 PAA16209; Mon, 11 Mar 2002 15:03: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 OAA25789; Mon, 11 Mar 2002 14:02: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 g2BM1mKL018958 for ; Mon, 11 Mar 2002 14:01:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BM1mRU018957 for mobile-ip-dist; Mon, 11 Mar 2002 14:01: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 g2BM1iKL018950 for ; Mon, 11 Mar 2002 14:01:44 -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 OAA00582 for ; Mon, 11 Mar 2002 14:01:39 -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 OAA04973 for ; Mon, 11 Mar 2002 14:01:39 -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 OAA05897; Mon, 11 Mar 2002 14:01:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2BM1Yp26041; Mon, 11 Mar 2002 14:01:34 -0800 X-mProtect:  Mon, 11 Mar 2002 14:01:34 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdXW3MNh; Mon, 11 Mar 2002 14:01:32 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 OAA29331; Mon, 11 Mar 2002 14:01:32 -0800 (PST) Message-ID: <3C8D293B.AC985172@iprg.nokia.com> Date: Mon, 11 Mar 2002 14:01:31 -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, "Charles E. Perkins" , Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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: > > Jari, > > > - On robustness: both verified and unverified caches are in reality > > finite in size. Both would have a similar error mechanism > > anyway so there is hardly a difference in robustness in > > RO-BC or unverified cache filling up. With the latter you > > may lose some packets in transit, but also with the former, > > it is just a cache and may get destroyed before or without > > new BU reaching the CN. In a worst case a RO data packet may > > be on path and get dropped in such a gap. This should not > > be a real argument. > > The above should not be a real argument :-) :-) > > Seriously, > I think there is a big difference between the case when the CN reboots > and losses all state (including transport and application state) i.e. looses > the BCE state compared to the unvHAO idea of effectively > doing "send and prey" that an unvHAO entry can be created on the CN. Now honestly, if one compares the cases of a node quickly establishing RR-verified cache entries and unvHOA entries, both can be done rather rapidly and for different addresses. Both caches can be filled and both caches should be of limited size. If one does not have an explicit limitation with RR-verified cache, it usually causes reservation of space from heap and is in a way worse because it can disturb other operation by making (k)mallocs fail for other uses. Having a restricted size also for RR-verified cache is _better_ than not having one. The UnvHAO space even had a rate limiting functionality specified unlike the verified BC. I still do not see any relevant difference in the memory filling behavior, hence on robustness. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 11 20:25: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 UAA01469 for ; Mon, 11 Mar 2002 20:25: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 SAA21264; Mon, 11 Mar 2002 18:25: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 RAA13988; Mon, 11 Mar 2002 17:25: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 g2C1OKKL019318 for ; Mon, 11 Mar 2002 17:24:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2C1OKCT019317 for mobile-ip-dist; Mon, 11 Mar 2002 17:24: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C1OHKL019310 for ; Mon, 11 Mar 2002 17:24:17 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07832 for ; Mon, 11 Mar 2002 17:24:18 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04061 for ; Mon, 11 Mar 2002 17:24: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 RAA19681; Mon, 11 Mar 2002 17:24:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2C1O9M30081; Mon, 11 Mar 2002 17:24:09 -0800 X-mProtect:  Mon, 11 Mar 2002 17:24:09 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdE6F1tV; Mon, 11 Mar 2002 17:24:07 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 RAA29533; Mon, 11 Mar 2002 17:24:07 -0800 (PST) Message-ID: <3C8D58B7.A9E0A735@iprg.nokia.com> Date: Mon, 11 Mar 2002 17:24:07 -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: "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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, > > Erik Nordmark wrote: > > > > > I think there are huge security problems caused by unvHAO. > So my statement applies to unvHAO handling using best-effort > tagging. Using exact tagging (where every "response packet" is > tagged with the IP source address in the corresponding "request > packet") seems to avoid these security issues at the expensive > of additional implementation complexity which needs to cross > the API and effect UDP applications. Since we are here considering unsecured applications, and to understand do-no-harm, the comparison should be done against what one can do with non-HAO packets. In unsecured packets, putting the spoofed HoA to the source address causes the same effect. Ingress filtering from the attacker to CN can be used for both, from CN to victim GN or HA, with non-mobility packets we have imperfect source based filtering, or with tagging, imperfect source+destination or tag based filtering. > I think I've expressed my security concerns several times > on the list already. Do I need to repeat them? I have tried to read through and found two, buffer behavior, non-exactness of tagging, and I am trying to see the added harm in them. Am I missing some others? > > - with tags and response packets being out of sync, right > > packets may get wrong tags and vice versa making tag-based > > filtering drop wrong packets and pass right packets. > > > > But: any filter in and after CN can still drop both, > > based on the destination address, for example, if > > we drop both right and wrong packets to this HoA. > > Yes, but that will then effect the legimate traffic. > The goal of handling DoS attacks is to maximize the number of > bad packets being filtered while minimizing the effect on > legitimate traffic. > With reflection it isn't always possible to avoid effect on legitimate > packets as Vern's paper (in DT writeups) point out. > But what you propose above makes MIPv6 cause additional causes where > filtering can not be very exact. Similarity to the non-mobility source-spoofed packets is striking, so that one cannot help asking, is this just having actually the same cause non-mobility packets already provide. Granted, a new rule to a firewall is needed to do something based on destination address (HA/GN) and source address (CN), or with the risk of mis-tagging, the tag itself. > > Also, given the timer range behavior with the unverified > > HAO cache, and unpredictability of the reflecting > > application, attack packets can be entered only > > momentarily, which makes it hard to find those > > moments due to randomized timeout ranges. > > Huh? > Are you talking about the case when one entitity > (attacker or good guy) is using HAO and the other isn't? With ongoing sessions for this case there is "inertia" which causes the non-HAO guy to keep the session easier. Mis-tagging requires switching between the good guy and bad guy and that takes time. During this time responses most likely are already gone, because switching takes a small timeout. During this timeout the responses to requests have gone to their right addresses and there is only a small probability for mis-tagging. If timeouts are made to follow responsiveness of the overall system, the probability can most likely be kept close to zero. Granted if the responses become slow, packets get dropped, but that may happen even for UDP applications if the load is bad enough. > Or the case when both are using HAO? The latter is the > place with the most problems. This is the case when MN and A compete for the HAO and MN must be able to move quicker from CoA to another. But here, too, if one uses rate-limiting of a small timeout (one of the two timers in the solution) to rate-limit how quickly changes are accepted and the legitimate MN also uses the same rate-limiting (plus a small delta), the bad guy must hit half of the delta to get in. So both CN and MN having rate limiting with obeying the faster timer, they can make it so that this timer gives CN stack the time not to mix the packets. With extensions such as BET, such a rate limiting may be already occurring naturally in MN. Attacker must pace his attacks really precisely to hit the occasion to cause alteration back and forth for the mis-tagging to happen. The small guard time allows for a relatively frequent mobility while it gives time for CN not to mis-order outgoing packets. If the guard time is larger than RTT variation, and variation of CN packet reordering probability, the hole for the attacker is near zero. t0 ---- guard_t - mn_t The attacker must hit between guard_t and rate limiting mn_t (when next packet after new CoA from the good MN arrives). Then it must again wait to let mn take its turn and again the same. Otherwise mis-tagging does not happen (only one guy causes the traffic and that is both traceable and filterable based on tags). > > Could you help me to see where the added harm is? > > It is unclear to me how the above issue effectively > > differs from the case non-mobility attack packets have > > a spoofed source address and get to be filtered along > > with victim's traffic from the same source address? > > Think of case with some ingress filtering (but never perfect) that > will prevent arbitrary source address spoofing. > Add attackers doing DoS and the need to filter those out > close to where the pain is being felt (and the CN might not feel > any pain from such an attack). CN source spoofing can be done at will at any time, and also off-path if there is no source-based (ingress and martian) filtering everywhere, even the best effort tagging limits the chances of mis-tagging to very small. To summarize: the differences are so minimal that I have not understood the more harm argument here. It would be even fair to call source spoofing much easier than causing mis-tagging. And even with mis-tagging one would have the same granularity of filtering as with source spoofing prevention. Both victim's and attacker's packets from/to one address get dropped at worst. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 12 07:06: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 HAA19770 for ; Tue, 12 Mar 2002 07:06:18 -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 FAA27855; Tue, 12 Mar 2002 05:06:13 -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 EAA16673; Tue, 12 Mar 2002 04:06: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 g2CC5FKL020397 for ; Tue, 12 Mar 2002 04:05:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CC5FoD020396 for mobile-ip-dist; Tue, 12 Mar 2002 04:05: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 g2CC5BKL020389 for ; Tue, 12 Mar 2002 04:05:11 -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 EAA16549 for ; Tue, 12 Mar 2002 04:05:11 -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 FAA27527 for ; Tue, 12 Mar 2002 05:05:10 -0700 (MST) Received: from ban by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian)) id 16kl1h-00086d-00 for ; Tue, 12 Mar 2002 14:05:09 +0200 Date: Tue, 12 Mar 2002 14:05:09 +0200 From: Bjorn Andersson To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] non-skippable extensions in MIPv4 Message-ID: <20020312120509.GA29841@lifix.fi> Mail-Followup-To: Bjorn Andersson , mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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: RFC3220 mandates that messages containing non-skippable extensions MUST be silently discarded. I would like to propose that if a registration request contains a non-skippable extension, then mobility agents should reply with an error code that gives an indication of the problem. The error reply should also be able to contain an extension that would give a more specific inidication of the problem, e.g. the position of the rejected extension and/or the extension type number. Currently, when registrations are silently discared, the MN has no chance of knowing whether the message was discarded due to a non-skippable extension or if it was lost in the Internet (and thus should be resent). Is there any reason for not replying with an error code? Opinions? 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 Mar 12 09:04: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 JAA22071 for ; Tue, 12 Mar 2002 09:04:12 -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 HAA27213; Tue, 12 Mar 2002 07:04: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 GAA06915; Tue, 12 Mar 2002 06:03: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 g2CE3BKL020672 for ; Tue, 12 Mar 2002 06:03:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CE3BTW020671 for mobile-ip-dist; Tue, 12 Mar 2002 06:03: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 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 g2CE37KL020664 for ; Tue, 12 Mar 2002 06:03:08 -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 g2CE34x11022; Tue, 12 Mar 2002 15:03:04 +0100 (MET) Date: Tue, 12 Mar 2002 14:57:47 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note To: "Jari T. Malinen" Cc: mobile-ip@sunroof.eng.sun.com, "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli In-Reply-To: "Your message with ID" <3C8D58B7.A9E0A735@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: > Since we are here considering unsecured applications, and to > understand do-no-harm, the comparison should be done against > what one can do with non-HAO packets. In unsecured packets, > putting the spoofed HoA to the source address causes the same > effect. Ingress filtering from the attacker to CN can be used > for both, from CN to victim GN or HA, with non-mobility packets > we have imperfect source based filtering, or with tagging, > imperfect source+destination or tag based filtering. How can today's ingress filtering (that looks at only the IP source address field) be able to filter out packets between the attacker and the CN? Those packets would have an IP source address that is topologically correct for the attacker. > > Are you talking about the case when one entitity > > (attacker or good guy) is using HAO and the other isn't? > > With ongoing sessions for this case there is "inertia" > which causes the non-HAO guy to keep the session easier. > Mis-tagging requires switching between the good guy and > bad guy and that takes time. During this time responses > most likely are already gone, because switching takes a > small timeout. During this timeout the responses to requests > have gone to their right addresses and there is only a > small probability for mis-tagging. If timeouts are made to > follow responsiveness of the overall system, the probability > can most likely be kept close to zero. Granted if the > responses become slow, packets get dropped, but that > may happen even for UDP applications if the load is > bad enough. You didn't answer my above question of what case you are talking about. Which case should I assume you were talking about? In the case of one entity using HAO and the other is not the timer mechanism effectively gives preference to not using HAO. So this seems to be workable. > > Or the case when both are using HAO? The latter is the > > place with the most problems. > > This is the case when MN and A compete for the HAO and > MN must be able to move quicker from CoA to another. > But here, too, if one uses rate-limiting of a small > timeout (one of the two timers in the solution) to > rate-limit how quickly changes are accepted and the > legitimate MN also uses the same rate-limiting (plus > a small delta), the bad guy must hit half of the delta > to get in. So both CN and MN having rate limiting with > obeying the faster timer, they can make it so that this > timer gives CN stack the time not to mix the packets. Are you referring to a modification to the unvHAO proposal that was sent to the list? I don't find references to the above in that proposal. Is the rate limiting you are proposing here a limit on the rate at which the recorded tag value can change? Or something else? Will the CN verify the source address in the received packets against the recorded rate-limited change tag value? [As you can tell I have no idea what change you are proposing to the unvHAO proposal.] > With extensions such as BET, such a rate limiting > may be already occurring naturally in MN. > Attacker must pace his attacks really precisely > to hit the occasion to cause alteration back and > forth for the mis-tagging to happen. The small > guard time allows for a relatively frequent mobility > while it gives time for CN not to mis-order outgoing > packets. If the guard time is larger than RTT variation, > and variation of CN packet reordering probability, > the hole for the attacker is near zero. > > t0 ---- guard_t - mn_t > > The attacker must hit between guard_t and rate limiting > mn_t (when next packet after new CoA from the good MN > arrives). Then it must again wait to let mn take its > turn and again the same. Otherwise mis-tagging does > not happen (only one guy causes the traffic and that > is both traceable and filterable based on tags). Will the CN discard packets that have the wrong source address? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 12 10:00: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 KAA23866 for ; Tue, 12 Mar 2002 10:00: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 IAA01129; Tue, 12 Mar 2002 08:00: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 GAA07804; Tue, 12 Mar 2002 06:59: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 g2CEwkKL020908 for ; Tue, 12 Mar 2002 06:58:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CEwjYf020907 for mobile-ip-dist; Tue, 12 Mar 2002 06:58: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 g2CEwgKL020900 for ; Tue, 12 Mar 2002 06:58: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 GAA20921 for ; Tue, 12 Mar 2002 06:58:42 -0800 (PST) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28174 for ; Tue, 12 Mar 2002 07:58:41 -0700 (MST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Mar 2002 09:57:41 -0500 Message-ID: From: "Shahrier, Sharif M." To: seamoby@ietf.org, "'mobile-ip@sunroof.eng.sun.com'" Cc: "Shahrier, Sharif M." Subject: [mobile-ip] [Seamoby] IEEE Std 802.11 Date: Tue, 12 Mar 2002 09:57:36 -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: Hello, I submitted this e-mail as a request to find out if anyone was working with IEEE Std 802.11 Wireless LAN. I am currently working on this, and at this time interested in the MAC-layer. Partcularly, the media access functions DCF and PCF, and enhancements thereof. Thus, I was wondering if anyone else was also working on this, perhaps implementation and modeling work, and simulation. Later, I also have plans to look at IP-layer enhancements such as transporting MAC frames from one ESS to another across multiple Aps. If anyone is involved in these topics, and would like some discussions, perhaps you can drop me an e-mail. Also, please let me know if you plan to be in Minneapolis, I am going to be there next week. Thank you very much. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 12 14:13: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 OAA02086 for ; Tue, 12 Mar 2002 14:13:25 -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 MAA07759; Tue, 12 Mar 2002 12:13: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 LAA01770; Tue, 12 Mar 2002 11:13: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 g2CJCGKL021634 for ; Tue, 12 Mar 2002 11:12:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CJCGMf021633 for mobile-ip-dist; Tue, 12 Mar 2002 11:12: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CJCDKL021626 for ; Tue, 12 Mar 2002 11:12:13 -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 LAA19222 for ; Tue, 12 Mar 2002 11:12:11 -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 MAA07138 for ; Tue, 12 Mar 2002 12:12:11 -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 LAA00781 for ; Tue, 12 Mar 2002 11:12:10 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2CJC7v24554 for ; Tue, 12 Mar 2002 11:12:07 -0800 X-mProtect:  Tue, 12 Mar 2002 11:12:07 -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 smtpd68WjCr; Tue, 12 Mar 2002 11:12:06 PST Message-ID: <3C8E5305.E5E486FE@iprg.nokia.com> Date: Tue, 12 Mar 2002 11:12:05 -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] [Mobile IP] MN performing Address resolution on returning home. 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, Looks like nobody responded to your mail. Check out this mail that I had sent in August 2001 http://www.atm.tut.fi/list-archive/mobile-ip/msg00400.html. It works. Vijay Srinivasan wrote: > > 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 Tue Mar 12 15: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 PAA06846 for ; Tue, 12 Mar 2002 15:55: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 MAA04951; Tue, 12 Mar 2002 12:55:12 -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 MAA10205; Tue, 12 Mar 2002 12: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 g2CKqvKL021888 for ; Tue, 12 Mar 2002 12:52:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CKqvM8021887 for mobile-ip-dist; Tue, 12 Mar 2002 12:52: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 g2CKqsKL021880 for ; Tue, 12 Mar 2002 12:52: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 MAA03897 for ; Tue, 12 Mar 2002 12:52:55 -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 NAA07180 for ; Tue, 12 Mar 2002 13:52: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 MAA09767; Tue, 12 Mar 2002 12:52:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2CKqrS28927; Tue, 12 Mar 2002 12:52:53 -0800 X-mProtect:  Tue, 12 Mar 2002 12:52:53 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.98, claiming to be "jmalinen.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7gXyIa; Tue, 12 Mar 2002 12:52: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 MAA31061; Tue, 12 Mar 2002 12:52:51 -0800 (PST) Message-ID: <3C8E6AA3.6AF76842@iprg.nokia.com> Date: Tue, 12 Mar 2002 12:52: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: "Charles E. Perkins" , Erik Nordmark , Rajeev Koodli Subject: Re: [mobile-ip] CLARIFICATION: Unverified HAO Processing - Recommendation note 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, > > > Since we are here considering unsecured applications, and to > > understand do-no-harm, the comparison should be done against > > what one can do with non-HAO packets. In unsecured packets, > > putting the spoofed HoA to the source address causes the same > > effect. Ingress filtering from the attacker to CN can be used > > for both, from CN to victim GN or HA, with non-mobility packets > > we have imperfect source based filtering, or with tagging, > > imperfect source+destination or tag based filtering. > > How can today's ingress filtering (that looks at only the IP > source address field) be able to filter out packets between the > attacker and the CN? Those packets would have an IP source > address that is topologically correct for the attacker. If we still discuss the HAO reflection (right?), first, there needs to be a method by which we can detect attacking packets by content to be able to filter them anywhere. If we consider the attacker-CN leg, which is before the reflection, these are still originated directly by the attacker, not yet by the reflecting CN. Hence, the source address is directly that of the attacker and normal ingress filtering should apply as long as the attack can be detected there by packet content (by TCP SYN in packets, for example). > > > Are you talking about the case when one entitity > > > (attacker or good guy) is using HAO and the other isn't? > > > > With ongoing sessions for this case there is "inertia" > > which causes the non-HAO guy to keep the session easier. > > Mis-tagging requires switching between the good guy and > > bad guy and that takes time. During this time responses > > most likely are already gone, because switching takes a > > small timeout. During this timeout the responses to requests > > have gone to their right addresses and there is only a > > small probability for mis-tagging. If timeouts are made to > > follow responsiveness of the overall system, the probability > > can most likely be kept close to zero. Granted if the > > responses become slow, packets get dropped, but that > > may happen even for UDP applications if the load is > > bad enough. > > You didn't answer my above question of what case you are > talking about. Which case should I assume you were talking about? Oops, grouping of your question did not make it explicit, yes, the case above is that of either party not tagging. > In the case of one entity using HAO and the other is not the timer > mechanism effectively gives preference to not using HAO. > So this seems to be workable. > > > > Or the case when both are using HAO? The latter is the > > > place with the most problems. > > > > This is the case when MN and A compete for the HAO and > > MN must be able to move quicker from CoA to another. > > But here, too, if one uses rate-limiting of a small > > timeout (one of the two timers in the solution) to > > rate-limit how quickly changes are accepted and the > > legitimate MN also uses the same rate-limiting (plus > > a small delta), the bad guy must hit half of the delta > > to get in. So both CN and MN having rate limiting with > > obeying the faster timer, they can make it so that this > > timer gives CN stack the time not to mix the packets. > > Are you referring to a modification to the unvHAO proposal > that was sent to the list? I don't find references to the > above in that proposal. > > Is the rate limiting you are proposing here a limit on the rate > at which the recorded tag value can change? Or something else? > Will the CN verify the source address in the received packets > against the recorded rate-limited change tag value? > [As you can tell I have no idea what change you are proposing to > the unvHAO proposal.] Let me just defer answers to all these to a revised text. This would actually make the issues more traceable than from this thread. > > With extensions such as BET, such a rate limiting > > may be already occurring naturally in MN. > > Attacker must pace his attacks really precisely > > to hit the occasion to cause alteration back and > > forth for the mis-tagging to happen. The small > > guard time allows for a relatively frequent mobility > > while it gives time for CN not to mis-order outgoing > > packets. If the guard time is larger than RTT variation, > > and variation of CN packet reordering probability, > > the hole for the attacker is near zero. > > > > t0 ---- guard_t - mn_t > > > > The attacker must hit between guard_t and rate limiting > > mn_t (when next packet after new CoA from the good MN > > arrives). Then it must again wait to let mn take its > > turn and again the same. Otherwise mis-tagging does > > not happen (only one guy causes the traffic and that > > is both traceable and filterable based on tags). > > Will the CN discard packets that have the wrong source address? Not necessarily. If MN and CN have roughly similar idea of minimal timing, there can be a very short period during which CN can discard or defer reception of such packets, depending on whether zero loss in all circumstances vs. more decreased probability for attacks is desired. Timing uses a gap that occurs only when MN changes CoA. Let us come back to that in a revised writeup later.. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 12 19:18: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 TAA13048 for ; Tue, 12 Mar 2002 19:18:19 -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 RAA19525; Tue, 12 Mar 2002 17:18: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 QAA29571; Tue, 12 Mar 2002 16:18: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 g2D0GeKL022114 for ; Tue, 12 Mar 2002 16:16:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D0GdTe022113 for mobile-ip-dist; Tue, 12 Mar 2002 16:16: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 g2D0GaKL022106 for ; Tue, 12 Mar 2002 16:16:36 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14439 for ; Tue, 12 Mar 2002 16:16: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 mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28182 for ; Tue, 12 Mar 2002 16:16:36 -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 g2D0Inx29458 for ; Tue, 12 Mar 2002 18:18:49 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 12 Mar 2002 18:16:35 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Mar 2002 18:16:11 -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 Security Issues (Update on issues Closed and Open) Date: Tue, 12 Mar 2002 18:16:11 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4409691C@daebe007.NOE.Nokia.com> Thread-Topic: MIPv6 Security Issues (Update on issues Closed and Open) Thread-Index: AcHKJEgHMjllnjXdEdaxrQAAhj/HZA== To: X-OriginalArrivalTime: 13 Mar 2002 00:16:11.0163 (UTC) FILETIME=[479476B0:01C1CA24] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2D0GbKL022107 Sender: owner-mobile-ip@sunroof.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, This is an update on the status of issues that were still open as per the staus update email sent on Feb 22nd: There were three open issues: 1. Piggybacking [Closed] 2. Home Address destination option processing [Closed] (Discussed on the list as Unverified HAO Processing) 3. The bit mechanism to turn on/off RR [Open] Issues 1 and 2 are now closed. Resolutions on these issues are as follows: 1. Piggybacking =============== As per the DT recommendations [Sent Feb 25th] on which are: R1. A Separate protocol 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. 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 and guidelines for supporting piggybacking in the presence of IPsec. 2. Unverified HAO Processing ============================ As per the conclusions/recommendation [Sent March 8th]: The base Mobile IPv6 specification will take the following approach: - CNs must not process packets with Unverified HAO - A CN must send an error response to a MN sending packets with unverified HAO , indicating its inability to process such packets by sending an error message specified in the base draft. * This error mechanism should be extensible so that different types of error notification can be added e.g. when unvHAO support is specified. - With future extensions and specification, MNs may optimistically send packets with unverified HAO to a CN, but on receiving an error response, MNs must resort to bidirectional tunnelling to send packets to the CN. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 12 21:54: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 VAA16817 for ; Tue, 12 Mar 2002 21:54: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 TAA01882; Tue, 12 Mar 2002 19:54: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 SAA29582; Tue, 12 Mar 2002 18:53: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 g2D2qrKL022366 for ; Tue, 12 Mar 2002 18:52:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D2qrJK022365 for mobile-ip-dist; Tue, 12 Mar 2002 18:52: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 g2D2qnKL022358 for ; Tue, 12 Mar 2002 18:52: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 SAA29510 for ; Tue, 12 Mar 2002 18:52:50 -0800 (PST) Received: from ep_mailout2 ([203.254.224.25]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12982 for ; Tue, 12 Mar 2002 18:52:49 -0800 (PST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GSW0010155MA3@mailout2.samsung.com> for mobile-ip@sunroof.eng.sun.com; Wed, 13 Mar 2002 11:48:58 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GSW0014P55L4J@mailout2.samsung.com> for mobile-ip@sunroof.eng.sun.com (ORCPT mobile-ip@sunroof.eng.sun.com); Wed, 13 Mar 2002 11:48:58 +0900 (KST) Received: from STJIMMY ([165.213.142.135]) by mmp1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GSW0061H563X2@mmp1.samsung.com> for mobile-ip@sunroof.eng.sun.com (ORCPT mobile-ip@sunroof.eng.sun.com); Wed, 13 Mar 2002 11:49:16 +0900 (KST) Date: Wed, 13 Mar 2002 11:52:46 +0900 From: "Jimmy H. Dho" Subject: Re: [mobile-ip] [Seamoby] IEEE Std 802.11 To: mobile-ip@sunroof.eng.sun.com Message-id: <001601c1ca3a$27a12270$0100a8c0@STJIMMY> Organization: Telecommunication R&D Center, Samsung Electronics Co., Ltd. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-mobile-ip@sunroof.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, Sharif My name is Jimmy H. Dho, just call me Jimmy, and am working for Samsung Electronics Co., Ltd. First of all, I am so happy to meet a person of the same mind. I am especially interested in the relationship between IAPP (802.11f) and Mobile IP. I am also going to Minneapolis. See you at there! Best Regards, Jimmy H. Dho Principal Standards Engineer Global Standards Strategy Team Telecommunication R&D Center Samsung Electronics Co., Ltd. Tel.) +82 - 31 - 279 - 5121 E-mail) jimmy_dho@samsung.com From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 02:38: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 CAA29670 for ; Wed, 13 Mar 2002 02:38:00 -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 AAA10990; Wed, 13 Mar 2002 00:37:59 -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 XAA02951; Tue, 12 Mar 2002 23:37: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 g2D7anKL022656 for ; Tue, 12 Mar 2002 23:36:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D7anY2022655 for mobile-ip-dist; Tue, 12 Mar 2002 23:36: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 g2D7akKL022648 for ; Tue, 12 Mar 2002 23:36:46 -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 XAA03045 for ; Tue, 12 Mar 2002 23:36:45 -0800 (PST) Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11924 for ; Wed, 13 Mar 2002 00:36:43 -0700 (MST) Received: by neogw.osaka.iij.ad.jp; id QAA05846; Wed, 13 Mar 2002 16:36:42 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma005842; Wed, 13 Mar 02 16:36:18 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id g2D7Zf201735 for ; Wed, 13 Mar 2002 16:35:41 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Wed, 13 Mar 2002 16:35:41 +0900 Message-ID: <86elio7wdu.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] some questions about MIPv6 spec User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") 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 all, I have two questions about MIPv6 spec. I know the spec will soon be revised. But, since there have been no discussions/clarifications in the mailing list about the following topics before, let me ask them. 1. The meaning of the 'routing prefixes' 2. The cases that we cannot use the HAO. 1. The meaning of the 'routing prefixes' In section 9.1 'Primary Care-of Address Registration', there are following sentences. If the `S' bit field in the Binding Update is zero, The Home Agent creates or updates Binding Cache entries for each of possible several home addresses. The set of such home addresses is formed by replacing the routing prefix for the given home address with all other routing prefixes that are supported by the home agent processing the Binding Update. The Home Agent creates such a separate primary care-of address registration for each such home address. When `S' bit is zero, the HA creates the BCEs for the MN with all 'routing prefixes' it has. But I couldn't find the definition of the 'routing prefix'. What is the definition? a) The prefixes advertised by the routers on the home network. (In this case, all the addresses derived from the prefixes must be the home addresses.) b) The prefixes advertised by the home agents on the home network. (In this case, all the addresses derived from the prefixes advertised by the home agents must be the home addresses) c) administratively selected prefixes to be the home prefix. d) other. 2. The cases that we cannot use the HAO. In section 10.1 'Sending Packets While Away from Home', the spec says that the MN SHOULD use the HAO to provide the transparent access to transport-level connections. The exception is short term communications. In short term communications, we MAY use COA. However, I think using the HAO is harmful in some cases (at lease one case. I will explain bellow) and must be noted in the spec as 'MUST NOT use HAO in some cases'. Suppose the MN is foreign. +--+ +--+ |MN|P:A |CN|Q:B MN: a mobile node (P is home prefix) ++-+Q:A(COA) +-++ CN: a CN that do not accept BU. | | --+----------------+-- Q::/64(or whatever) In the above network, MN will learn the CN's lladdr for the address Q::B by ND mechanism like bellow. Neighbor Linklayer Address Q::B (MAC addr of the CN) Some time after, the MN may send a NS to check the reachability of the Q::B. In this case the dest address of the NS is Q::B and the source address will be the home address because of the source address selection algorithm. Since the HAO is transparent to transport-layer (such as ICMPv6), the CN will create the ND entry for P:A. Neighbor Linklayer Address P::A (MAC addr of the MN) After the creation of the P:A entry, the CN sends packets to the MN directly because the CN has a ND entry for P:A instead of sending to the home agent of the MN. Do the other protocols have same problem? Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 09:48: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 JAA06943 for ; Wed, 13 Mar 2002 09:48: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 GAA14226; Wed, 13 Mar 2002 06:48: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 GAA06812; Wed, 13 Mar 2002 06:47: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 g2DEkYKL023379 for ; Wed, 13 Mar 2002 06:46:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DEkY7V023378 for mobile-ip-dist; Wed, 13 Mar 2002 06:46: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DEkVKL023371 for ; Wed, 13 Mar 2002 06:46:31 -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 GAA22953 for ; Wed, 13 Mar 2002 06:46:31 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19011 for ; Wed, 13 Mar 2002 07:46:29 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Mar 2002 09:45:11 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] AAA keys security review Date: Wed, 13 Mar 2002 09:45:10 -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: Hi folks, I asked Luis Sanchez (chair of ipsp WG) to review this doc for us and he did. We're very grateful. Here's the note he sent with his review embedded. Please note, this was done on version -08 before Charlie produced version -09. Phil ------------------------------ Hi Phil, Enclose you will find a security review of draft-ietf-mobileip-aaa-key-08.txt. The findings have input from the following individuals listed in alphabetical order: - S. Bitan - S. Kent - H. Orman Any mistakes are solely mine. Thanks! Luis ------------------------------------------- General Observation: Overall the document is in reasonable shape. I would merge this document with draft-ietf-mobileip-gen-key-01.txt. The document should however, undergo editorial review. One major concern is the lack of a succinct security goal statement. Such statement would be beneficial to the reader and would avoid confusion "why isn't this protected, why is this protected, should this be protected, etc." In the IPsec context, security associations are simplex and uniquely identified by the triple (IP address, SPI, protocol). It is not clear if there is a 1to1 mapping between IPsec security associations and the "security associations" between mobile nodes and AAA servers. Perhaps this is discussed in some other document. **Recommendation: Add text to explain the nature of the AAA server to Mobile Node security association. - The mobile node calculates a key by hashing a concatenation of bits that include the AAA-key. How does the mobile get this key? Does it arrive on the wire? If it arrives on the wire it better be encrypted as a result of using yet some other protocol exchange to provide: peer authentication, data integrity and confidentiality. Are we assuming a security association using IKE between the MN and its home AAA server and that is how this AAA-key is generated? Otherwise, if pre-configured (manually? )how is this different from pre-configuring an MN-HA key. I might be asking the obvious here by not understanding the protocol exchanges. **Recommendation: Add text to explain how the AAA-Key is generated and configured in the MN and other peers. - For key derivation, the document recommends using one of the algorithms listed in the following table Algorithm Identifier Name Reference --------------------- ------------------ ------------ 1 MD5/prefix+suffix RFC 2002 [11] 2 HMAC MD5 RFC 2104 [6] 3 SHA-1 FIPS 180-1 [10] Back in 1996 Bellare, Canetti and Krawczyk published a paper on crypto discussing how a keyed hash function used in append/pre-append mode is more susceptible to the "divide and conquer" attack, although impractical, than a keyed-hashed function using a keyed-IV instead. They also proved that cryptographically HMAC is as strong as the hash function used with it. One can no make such a statement of a keyed-hash function used in prefix+suffix mode. As such, IPsec dropped RFC1828 and adopted HMAC-MD5 and HMAC-SHA1 the latter one truncated to 90bits. Another potential problem with MD5/prefix+suffix could come in if the nonsecret component of the key is variable length. In that case, if you were using MD5(secret, nonsecret) = newkey, then someone might be able to see newkey and later observe an exchange where nonsecret' = nonsecret|1. Then the key would be MD5(newkey, 1) = newkey'. You have to analyze the protocol very carefully to assure that this doesn't happen, but if you use HMAC, you don't have to worry about it. **Recommendation: Advise reader to derive keys using: key = HMAC-MD5(AAA-key, {Key Material | node-addres}) or HMAC-SHA1. Do not recommend using MD5/prefix+suffix or just SHA-1. - The AAA key need to be chosen at random (or using a cryptographically strong pseudo-random generator seeded with a random seed), and periodically refreshed. The document makes reference to RFC1750 and this is appropriate however, it does not mention refreshing. It is not clear that we can recommended a specific frequency for key changes as the attacks refered to above may seem practically infeasible. However, periodic key refreshment is a fundamental security practice that helps against potential weaknesses of the function and keys, and limits the damage of an exposed key. **Recommendation: Add a statement to indicate that both the Mobile Node and the AAA server MUST refresh their shared AAA-key. This could be done via the AAA protocol or some other out-of-band mechanism. For in-band refreshing the new key MUST be encrypted, authenticated and its integrity MUST be protected while on transit. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 10:55: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 KAA08871 for ; Wed, 13 Mar 2002 10:55:41 -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 IAA08650; Wed, 13 Mar 2002 08:55: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 HAA22901; Wed, 13 Mar 2002 07: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 g2DFsaKL023672 for ; Wed, 13 Mar 2002 07:54:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DFsaTB023671 for mobile-ip-dist; Wed, 13 Mar 2002 07:54: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 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 g2DFsVKL023664 for ; Wed, 13 Mar 2002 07:54:32 -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 g2DFsQx08807; Wed, 13 Mar 2002 16:54:26 +0100 (MET) Date: Wed, 13 Mar 2002 07:53:41 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Text and proposal for piggybacking To: charliep@iprg.nokia.com Cc: Mobile IP Working Group In-Reply-To: "Your message with ID" <3C8876A0.DAEB74CE@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: > Two new header types are needed: one extension header for > piggybacking, and one final header type used with IPsec. I didn't see a clear explanation in the writeup when each of the two types would be used. Is it for different cases in Table 1? Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 12:30:35 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 MAA12196 for ; Wed, 13 Mar 2002 12:30:34 -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 KAA29080; Wed, 13 Mar 2002 10:30: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 JAA14432; Wed, 13 Mar 2002 09:30: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 g2DHTLKL023869 for ; Wed, 13 Mar 2002 09:29:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DHTLb0023868 for mobile-ip-dist; Wed, 13 Mar 2002 09:29: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 g2DHTIKL023861 for ; Wed, 13 Mar 2002 09:29: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 JAA01170 for ; Wed, 13 Mar 2002 09:29:19 -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 JAA26531 for ; Wed, 13 Mar 2002 09:29:18 -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 JAA03077; Wed, 13 Mar 2002 09:29:14 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2DHTCO08908; Wed, 13 Mar 2002 09:29:12 -0800 X-mProtect:  Wed, 13 Mar 2002 09:29:12 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxesIqh; Wed, 13 Mar 2002 09:25:27 PST Message-ID: <3C8F8B86.F7942BB8@iprg.nokia.com> Date: Wed, 13 Mar 2002 09:25:26 -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: Phil Roberts , "Pat R. Calhoun" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] AAA keys security review 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 Phil, The relevant material from gen-key has been merged into version ...-09 I can carry out the other two recommendations in a newly revised draft produced after the upcoming IETF. However, I should think that these are relatively small things, and should not require a new working group last call. In other words, either version ...-09 or the newly revised document could conceivably go directly for IESG consideration. I can describe the nature of the (mobile node<-->AAA) security association, but I would appreciate any help that someone might offer (including, as always, actual text). What do you think? Regards, Charlie P. Phil Roberts wrote: > > Hi folks, > > I asked Luis Sanchez (chair of ipsp WG) to review this doc for us and he > did. We're very > grateful. Here's the note he sent with his review embedded. Please note, > this was done on > version -08 before Charlie produced version -09. > > Phil > ------------------------------ > > Hi Phil, > > Enclose you will find a security review of > draft-ietf-mobileip-aaa-key-08.txt. The findings have input from the > following individuals listed in alphabetical order: > > - S. Bitan > - S. Kent > - H. Orman > > Any mistakes are solely mine. Thanks! > > Luis > > ------------------------------------------- > > General Observation: Overall the document is in reasonable shape. I > would merge this document with draft-ietf-mobileip-gen-key-01.txt. The > document should however, undergo editorial review. One major concern is > the lack of a succinct security goal statement. Such statement would be > beneficial to the reader and would avoid confusion "why isn't this > protected, why is this protected, should this be protected, etc." > > In the IPsec context, security associations are simplex and uniquely > identified by the triple (IP address, SPI, protocol). It is not clear if > there is a 1to1 mapping between IPsec security associations and the > "security associations" between mobile nodes and AAA servers. Perhaps > this is discussed in some other document. > > **Recommendation: Add text to explain the nature of the AAA server to > Mobile Node security association. > > - The mobile node calculates a key by hashing a concatenation of bits > that include the AAA-key. How does the mobile get this key? Does it > arrive on the wire? If it arrives on the wire it better be encrypted as > a result of using yet some other protocol exchange to provide: peer > authentication, data integrity and confidentiality. Are we assuming a > security association using IKE between the MN and its home AAA server > and that is how this AAA-key is generated? Otherwise, if pre-configured > (manually? )how is this different from pre-configuring an MN-HA key. I > might be asking the obvious here by not understanding the protocol > exchanges. > > **Recommendation: Add text to explain how the AAA-Key is generated and > configured in the MN and other peers. > > - For key derivation, the document recommends using one of the > algorithms listed in the following table > > Algorithm Identifier Name Reference > --------------------- ------------------ ------------ > 1 MD5/prefix+suffix RFC 2002 [11] > 2 HMAC MD5 RFC 2104 [6] > 3 SHA-1 FIPS 180-1 [10] > > Back in 1996 Bellare, Canetti and Krawczyk published a paper on crypto > discussing how a keyed hash function used in append/pre-append mode is > more susceptible to the "divide and conquer" attack, although > impractical, than a keyed-hashed function using a keyed-IV instead. They > also proved that cryptographically HMAC is as strong as the hash > function used with it. One can no make such a statement of a keyed-hash > function used in prefix+suffix mode. As such, IPsec dropped RFC1828 and > adopted HMAC-MD5 and HMAC-SHA1 the latter one truncated to 90bits. > Another potential problem with MD5/prefix+suffix could come in if the > nonsecret component of the key is variable length. In that case, if you > were using MD5(secret, nonsecret) = newkey, then someone might be able > to see newkey and later observe an exchange where nonsecret' = > nonsecret|1. Then the key would be MD5(newkey, 1) = newkey'. You have > to analyze the protocol very carefully to assure that this doesn't > happen, but if you use HMAC, you don't have to worry about it. > > **Recommendation: Advise reader to derive keys using: key = > HMAC-MD5(AAA-key, {Key Material | node-addres}) > > or HMAC-SHA1. Do not recommend using MD5/prefix+suffix or just SHA-1. > > - The AAA key need to be chosen at random (or using a cryptographically > strong pseudo-random generator seeded with a random seed), and > periodically refreshed. The document makes reference to RFC1750 and > this is appropriate however, it does not mention refreshing. It is not > clear that we can recommended a specific frequency for key changes as > the attacks refered to above may seem practically infeasible. However, > periodic key refreshment is a fundamental security practice that helps > against potential weaknesses of the function and keys, and limits the > damage of an exposed key. > > **Recommendation: Add a statement to indicate that both the Mobile Node > and the AAA server MUST refresh their shared AAA-key. This could be done > via the AAA protocol or some other out-of-band mechanism. For in-band > refreshing the new key MUST be encrypted, authenticated and its > integrity MUST be protected while on transit. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 13:26: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 NAA14201 for ; Wed, 13 Mar 2002 13:26:52 -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 LAA02532; Wed, 13 Mar 2002 11:26: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 KAA23027; Wed, 13 Mar 2002 10:26: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 g2DIPcKL024078 for ; Wed, 13 Mar 2002 10:25:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DIPcw5024077 for mobile-ip-dist; Wed, 13 Mar 2002 10:25: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 g2DIPZKL024070 for ; Wed, 13 Mar 2002 10:25: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 KAA17666 for ; Wed, 13 Mar 2002 10:25:35 -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 LAA01945 for ; Wed, 13 Mar 2002 11:25:34 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Mar 2002 13:01:38 -0500 Message-ID: From: Phil Roberts To: "'Charles E. Perkins'" , Phil Roberts , "Pat R. Calhoun" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] AAA keys security review Date: Wed, 13 Mar 2002 13:01:38 -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'm inclined to agree unless there are surprise comments from the IESG review. We'll have to make sure there is a clear recommendation to use HMAC-MD5 (I haven't looked at the text for -09 either ....). > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Wednesday, March 13, 2002 12:25 PM > To: Phil Roberts; Pat R. Calhoun > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] AAA keys security review > > > > Hello Phil, > > The relevant material from gen-key has been merged into > version ...-09 I can carry out the other two recommendations > in a newly revised draft produced after the upcoming IETF. > However, I should think that these are relatively small > things, and should not require a new working group last call. > In other words, either version ...-09 or the newly revised > document could conceivably go directly for IESG consideration. > > I can describe the nature of the (mobile node<-->AAA) > security association, but I would appreciate any help that > someone might offer (including, as always, actual text). > > What do you think? > > Regards, > Charlie P. > > > > Phil Roberts wrote: > > > > Hi folks, > > > > I asked Luis Sanchez (chair of ipsp WG) to review this > doc for us > > and he did. We're very grateful. Here's the note he sent with his > > review embedded. Please note, this was done on > > version -08 before Charlie produced version -09. > > > > Phil > > ------------------------------ > > > > Hi Phil, > > > > Enclose you will find a security review of > > draft-ietf-mobileip-aaa-key-08.txt. The findings have input > from the > > following individuals listed in alphabetical order: > > > > - S. Bitan > > - S. Kent > > - H. Orman > > > > Any mistakes are solely mine. Thanks! > > > > Luis > > > > ------------------------------------------- > > > > General Observation: Overall the document is in reasonable shape. I > > would merge this document with draft-ietf-mobileip-gen-key-01.txt. > > The document should however, undergo editorial review. One major > > concern is the lack of a succinct security goal statement. Such > > statement would be beneficial to the reader and would avoid > confusion > > "why isn't this protected, why is this protected, should this be > > protected, etc." > > > > In the IPsec context, security associations are simplex and > uniquely > > identified by the triple (IP address, SPI, protocol). It is > not clear > > if there is a 1to1 mapping between IPsec security > associations and the > > "security associations" between mobile nodes and AAA > servers. Perhaps > > this is discussed in some other document. > > > > **Recommendation: Add text to explain the nature of the AAA > server to > > Mobile Node security association. > > > > - The mobile node calculates a key by hashing a > concatenation of bits > > that include the AAA-key. How does the mobile get this key? Does it > > arrive on the wire? If it arrives on the wire it better be > encrypted > > as a result of using yet some other protocol exchange to > provide: peer > > authentication, data integrity and confidentiality. Are we > assuming a > > security association using IKE between the MN and its home > AAA server > > and that is how this AAA-key is generated? Otherwise, if > > pre-configured (manually? )how is this different from > pre-configuring > > an MN-HA key. I might be asking the obvious here by not > understanding > > the protocol exchanges. > > > > **Recommendation: Add text to explain how the AAA-Key is > generated and > > configured in the MN and other peers. > > > > - For key derivation, the document recommends using one of the > > algorithms listed in the following table > > > > Algorithm Identifier Name Reference > > --------------------- ------------------ ------------ > > 1 MD5/prefix+suffix RFC 2002 [11] > > 2 HMAC MD5 RFC 2104 [6] > > 3 SHA-1 FIPS 180-1 [10] > > > > Back in 1996 Bellare, Canetti and Krawczyk published a > paper on crypto > > discussing how a keyed hash function used in > append/pre-append mode is > > more susceptible to the "divide and conquer" attack, although > > impractical, than a keyed-hashed function using a keyed-IV instead. > > They also proved that cryptographically HMAC is as strong > as the hash > > function used with it. One can no make such a statement of a > > keyed-hash function used in prefix+suffix mode. As such, > IPsec dropped > > RFC1828 and adopted HMAC-MD5 and HMAC-SHA1 the latter one > truncated to > > 90bits. Another potential problem with MD5/prefix+suffix > could come in > > if the nonsecret component of the key is variable length. In that > > case, if you were using MD5(secret, nonsecret) = newkey, > then someone > > might be able to see newkey and later observe an exchange where > > nonsecret' = > > nonsecret|1. Then the key would be MD5(newkey, 1) = > newkey'. You have > > to analyze the protocol very carefully to assure that this doesn't > > happen, but if you use HMAC, you don't have to worry about it. > > > > **Recommendation: Advise reader to derive keys using: key = > > HMAC-MD5(AAA-key, {Key Material | node-addres}) > > > > or HMAC-SHA1. Do not recommend using MD5/prefix+suffix or > just SHA-1. > > > > - The AAA key need to be chosen at random (or using a > > cryptographically strong pseudo-random generator seeded > with a random > > seed), and periodically refreshed. The document makes reference to > > RFC1750 and this is appropriate however, it does not mention > > refreshing. It is not clear that we can recommended a specific > > frequency for key changes as the attacks refered to above may seem > > practically infeasible. However, periodic key refreshment is a > > fundamental security practice that helps against potential > weaknesses > > of the function and keys, and limits the damage of an exposed key. > > > > **Recommendation: Add a statement to indicate that both the Mobile > > Node and the AAA server MUST refresh their shared AAA-key. > This could > > be done via the AAA protocol or some other out-of-band > mechanism. For > > in-band refreshing the new key MUST be encrypted, authenticated and > > its integrity MUST be protected while on transit. > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 16:23: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 QAA19935 for ; Wed, 13 Mar 2002 16:23:54 -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 OAA08791; Wed, 13 Mar 2002 14: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 NAA22386; Wed, 13 Mar 2002 13:23: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 g2DLLnKL024532 for ; Wed, 13 Mar 2002 13:21:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DLLn7s024531 for mobile-ip-dist; Wed, 13 Mar 2002 13:21: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 g2DLLjKL024524 for ; Wed, 13 Mar 2002 13:21: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 NAA21634 for ; Wed, 13 Mar 2002 13:21:47 -0800 (PST) From: David_Harrison@NAI.com Received: from RelayDAL.nai.com (relaydal.nai.com [161.69.213.5]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25080 for ; Wed, 13 Mar 2002 13:21:44 -0800 (PST) Received: from txwsout1.nai.com (txwsout1.nai.com [161.69.96.120]) by RelayDAL.nai.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g2DLLBm26154 for ; Wed, 13 Mar 2002 15:21:11 -0600 (CST) Received: FROM tx-ex-bridge1.nai.com BY txwsout1.nai.com ; Wed Mar 13 15:23:11 2002 -0600 Received: by TX-EX-BRIDGE1 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 15:23:08 -0600 Message-ID: <99120312047FD41183AA009027AA616003CD9498@SNC-5-91.nai.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] draft-ietf-mobileip-3gwireless-ext-XX (R-P Interface) Date: Wed, 13 Mar 2002 15:21:55 -0600 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: Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network Can someone please direct me to the current incarnation of this spec? It disappeared from the IETF MIP page and I don't know where it is. Thanks... Dave Harrison Senior Software Engineer Sniffer Technologies, Network Associates Inc. Voice: (408) 346-5685 Email: David_Harrison@nai.com From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 16:27: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 QAA20046 for ; Wed, 13 Mar 2002 16:27:35 -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 OAA27658; Wed, 13 Mar 2002 14: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 NAA23734; Wed, 13 Mar 2002 13: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 g2DLQlKL024611 for ; Wed, 13 Mar 2002 13:26:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DLQlPB024610 for mobile-ip-dist; Wed, 13 Mar 2002 13:26: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 g2DLQiKL024603 for ; Wed, 13 Mar 2002 13:26: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 NAA00612 for ; Wed, 13 Mar 2002 13:26:41 -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 NAA21571 for ; Wed, 13 Mar 2002 13:26:40 -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 g2DLSsx03486 for ; Wed, 13 Mar 2002 15:28:54 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 13 Mar 2002 15:26:39 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 13 Mar 2002 15:26:16 -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] draft-ietf-mobileip-3gwireless-ext-XX (R-P Interface) Date: Wed, 13 Mar 2002 15:26:15 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A129D6@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] draft-ietf-mobileip-3gwireless-ext-XX (R-P Interface) Thread-Index: AcHK1VvqtKqXZlLTQ9yY6uU00y7EcgAAB4Yg To: Cc: X-OriginalArrivalTime: 13 Mar 2002 21:26:16.0131 (UTC) FILETIME=[B547C930:01C1CAD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2DLQiKL024604 Sender: owner-mobile-ip@sunroof.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 The draft has been deprecated as WG document and hence does not show up on the Mobile IP page. However it is still available in the drafts repository. http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-06.txt > > Mobile IP Based Micro Mobility Management Protocol in > The Third Generation Wireless Network > > > > Can someone please direct me to the current incarnation of > this spec? It > disappeared from the IETF MIP > page and I don't know where it is. > > Thanks... > > Dave Harrison > Senior Software Engineer > Sniffer Technologies, Network Associates Inc. > Voice: (408) 346-5685 > Email: David_Harrison@nai.com > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 16:44: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 QAA20637 for ; Wed, 13 Mar 2002 16:44:12 -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 OAA05194; Wed, 13 Mar 2002 14:44:13 -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 NAA29285; Wed, 13 Mar 2002 13:44: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 g2DLhHKL024827 for ; Wed, 13 Mar 2002 13:43:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DLhH1v024826 for mobile-ip-dist; Wed, 13 Mar 2002 13:43: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 g2DLhDKL024819 for ; Wed, 13 Mar 2002 13:43:13 -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 NAA29061 for ; Wed, 13 Mar 2002 13:43:14 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04699 for ; Wed, 13 Mar 2002 14:43:14 -0700 (MST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2DLhDK12625; Wed, 13 Mar 2002 16:43:13 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA00631; Wed, 13 Mar 2002 15:41:23 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id PAA11615; Wed, 13 Mar 2002 15:41:23 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15503.51075.186243.225001@nwsgpb.ih.lucent.com> Date: Wed, 13 Mar 2002 15:41:23 -0600 (CST) From: Pete McCann To: mobile-ip@sunroof.eng.sun.com Cc: Subject: RE: [mobile-ip] draft-ietf-mobileip-3gwireless-ext-XX (R-P Interface) In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A129D6@daebe007.NOE.Nokia.com> References: <697DAA22C5004B4596E033803A7CEF44A129D6@daebe007.NOE.Nokia.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.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 While the 3gwireless draft superficially resembles Mobile IP in some respects, it actually just pertains to an interface between cdma2000 PCFs and PDSNs, and doesn't really have anything to do with Mobile IP proper. It uses a different UDP port number for its messages. Some of the extension type codes were assigned unilaterally (without consulting IANA). It was rightly removed from the Mobile IP working group home page. The controlling document for the R-P interface is the Inter-Operability Specification, produced by the TSG-A working group of 3GPP2. You can find the latest published version (4.1) at: ftp://ftp.3gpp2.org/TSGA/Working/Standards/A.S0001-A-(IOS-V4.1-(IS-2001-A))/ Versions 4.2 and 4.3 are also available on the ftp site, but are still works-in-progress. -Pete Basavaraj.Patil@nokia.com writes: > The draft has been deprecated as WG document and hence does not > show up on the Mobile IP page. However it is still available in the drafts > repository. > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-3gwireless-ext-06.txt > > > > > > Mobile IP Based Micro Mobility Management Protocol in > > The Third Generation Wireless Network > > > > > > > > Can someone please direct me to the current incarnation of > > this spec? It > > disappeared from the IETF MIP > > page and I don't know where it is. > > > > Thanks... > > > > Dave Harrison > > Senior Software Engineer > > Sniffer Technologies, Network Associates Inc. > > Voice: (408) 346-5685 > > Email: David_Harrison@nai.com > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 17:20: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 RAA21977 for ; Wed, 13 Mar 2002 17:19:59 -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 PAA20758; Wed, 13 Mar 2002 15:20: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 OAA11932; Wed, 13 Mar 2002 14:19: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 g2DMIwKL024968 for ; Wed, 13 Mar 2002 14:18:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DMIwSJ024967 for mobile-ip-dist; Wed, 13 Mar 2002 14: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 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 g2DMIrKL024960 for ; Wed, 13 Mar 2002 14:18:54 -0800 (PST) Received: from lillen (vpn-129-156-96-60.EMEA.Sun.COM [129.156.96.60]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2DMIqx09493 for ; Wed, 13 Mar 2002 23:18:52 +0100 (MET) Date: Wed, 13 Mar 2002 14:18:06 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] some questions about MIPv6 spec To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <86elio7wdu.wl@keiichi01.osaka.iij.ad.jp> 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 meaning of the 'routing prefixes' > > In section 9.1 'Primary Care-of Address Registration', there are > following sentences. > > If the `S' bit field in the Binding Update is zero, The Home Agent > creates or updates Binding Cache entries for each of possible > several home addresses. The set of such home addresses is formed > by replacing the routing prefix for the given home address with > all other routing prefixes that are supported by the home agent > processing the Binding Update. The Home Agent creates such a > separate primary care-of address registration for each such home > address. > > When `S' bit is zero, the HA creates the BCEs for the MN with all > 'routing prefixes' it has. But I couldn't find the definition of the > 'routing prefix'. > > What is the definition? I suspect it would be more clear if it said that the HA performs all the functions of RFC 2462 on behalf of the mobile node. That spec has the details of how the addresses are formed from the prefixes advertised in router advertisements. > 2. The cases that we cannot use the HAO. > > In section 10.1 'Sending Packets While Away from Home', the spec says > that the MN SHOULD use the HAO to provide the transparent access to > transport-level connections. The exception is short term > communications. In short term communications, we MAY use COA. > > However, I think using the HAO is harmful in some cases (at lease one > case. I will explain bellow) and must be noted in the spec as 'MUST > NOT use HAO in some cases'. > > Suppose the MN is foreign. > > +--+ +--+ > |MN|P:A |CN|Q:B MN: a mobile node (P is home prefix) > ++-+Q:A(COA) +-++ CN: a CN that do not accept BU. > | | > --+----------------+-- Q::/64(or whatever) > > In the above network, MN will learn the CN's lladdr for the address > Q::B by ND mechanism like bellow. > > Neighbor Linklayer Address > Q::B (MAC addr of the CN) > > Some time after, the MN may send a NS to check the reachability of the > Q::B. In this case the dest address of the NS is Q::B and the source > address will be the home address because of the source address > selection algorithm. Why will the source address be the home address? > Since the HAO is transparent to transport-layer > (such as ICMPv6), the CN will create the ND entry for P:A. > > Neighbor Linklayer Address > P::A (MAC addr of the MN) > > After the creation of the P:A entry, the CN sends packets to the MN > directly because the CN has a ND entry for P:A instead of sending to > the home agent of the MN. > > Do the other protocols have same problem? Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 20:59: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 UAA27080 for ; Wed, 13 Mar 2002 20:59: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 SAA13375; Wed, 13 Mar 2002 18:59: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 RAA29416; Wed, 13 Mar 2002 17:59: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 g2E1wkKL025374 for ; Wed, 13 Mar 2002 17:58:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E1wknH025373 for mobile-ip-dist; Wed, 13 Mar 2002 17:58: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E1wgKL025366 for ; Wed, 13 Mar 2002 17:58:42 -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 RAA02170 for ; Wed, 13 Mar 2002 17:58:43 -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 SAA21791 for ; Wed, 13 Mar 2002 18:58: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 RAA14983 for ; Wed, 13 Mar 2002 17:58:42 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2E1wfo19127; Wed, 13 Mar 2002 17:58:41 -0800 X-mProtect:  Wed, 13 Mar 2002 17:58:41 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.98, claiming to be "jmalinen.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7sKbAE; Wed, 13 Mar 2002 17:58:40 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 RAA33081; Wed, 13 Mar 2002 17:58:40 -0800 (PST) Message-ID: <3C9003D0.1C85D8B5@iprg.nokia.com> Date: Wed, 13 Mar 2002 17:58:40 -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: charliep@iprg.nokia.com Subject: Re: [mobile-ip] Text and proposal for piggybacking 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, > > > Two new header types are needed: one extension header for > > piggybacking, and one final header type used with IPsec. > > I didn't see a clear explanation in the writeup when each > of the two types would be used. Is it for different cases > in Table 1? In the writeup, mobility signaling for cases 1 and 2 use the extension header, cases 3 and 4 use the final header. > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 22:11: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 WAA29004 for ; Wed, 13 Mar 2002 22:11: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 UAA07648; Wed, 13 Mar 2002 20:11: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 TAA25783; Wed, 13 Mar 2002 19:10: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 g2E39nKL025573 for ; Wed, 13 Mar 2002 19:09:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E39nJa025572 for mobile-ip-dist; Wed, 13 Mar 2002 19:09: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 g2E39kKL025565 for ; Wed, 13 Mar 2002 19:09:46 -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 TAA23043 for ; Wed, 13 Mar 2002 19:09:44 -0800 (PST) Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08175 for ; Wed, 13 Mar 2002 19:09:43 -0800 (PST) Received: by neogw.osaka.iij.ad.jp; id MAA11003; Thu, 14 Mar 2002 12:09:42 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma010993; Thu, 14 Mar 02 12:09:31 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id g2E394000320 for ; Thu, 14 Mar 2002 12:09:05 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Thu, 14 Mar 2002 12:09:04 +0900 Message-ID: <86adtbyhf3.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some questions about MIPv6 spec In-Reply-To: References: <86elio7wdu.wl@keiichi01.osaka.iij.ad.jp> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") 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: > > > Neighbor Linklayer Address > > Q::B (MAC addr of the CN) > > > > Some time after, the MN may send a NS to check the reachability of the > > Q::B. In this case the dest address of the NS is Q::B and the source > > address will be the home address because of the source address > > selection algorithm. > > Why will the source address be the home address? When a node confirm the reachability of the Q::B (a global address in this case), the node will sent a NS packet to the address (Q::B). The source address of the NS packet will be the home address of the sending MN because of the latter half of the rule 4 of draft-ietf-ipngwg-default-addr-select. Rule 4: Prefer home addresses. If Source(DA) is simultaneously a home address and care-of address and Source(DB) is not, then sort DA before DB. Similarly, if Source(DB) is simultaneously a home address and care-of address and Source(DA) is not, then sort DB before DA. If Source(DA) is just a home address and Source(DB) is just a care- of address, then sort DA before DB. Similarly, if Source(DA) is just a care-of address and Source(DB) is just a home address, then sort DB before DA. Did I misread? Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 13 23: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 XAA01801 for ; Wed, 13 Mar 2002 23:44:00 -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 VAA05728; Wed, 13 Mar 2002 21:43: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 UAA06660; Wed, 13 Mar 2002 20:42: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 g2E4fjKL025758 for ; Wed, 13 Mar 2002 20:41:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E4fj1V025757 for mobile-ip-dist; Wed, 13 Mar 2002 20: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E4fgKL025750 for ; Wed, 13 Mar 2002 20:41:42 -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 UAA26376 for ; Wed, 13 Mar 2002 20:41:44 -0800 (PST) Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29445 for ; Wed, 13 Mar 2002 21:41:43 -0700 (MST) Received: by neogw.osaka.iij.ad.jp; id NAA15954; Thu, 14 Mar 2002 13:41:42 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma015845; Thu, 14 Mar 02 13:41:17 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id g2E4eo000400 for ; Thu, 14 Mar 2002 13:40:50 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Thu, 14 Mar 2002 13:40:50 +0900 Message-ID: <864rjjyd65.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] some questions about MIPv6 spec In-Reply-To: References: <86elio7wdu.wl@keiichi01.osaka.iij.ad.jp> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") 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, Erik Nordmark wrote: > > > 1. The meaning of the 'routing prefixes' > > > > In section 9.1 'Primary Care-of Address Registration', there are > > following sentences. > > > > If the `S' bit field in the Binding Update is zero, The Home Agent > > creates or updates Binding Cache entries for each of possible > > several home addresses. The set of such home addresses is formed > > by replacing the routing prefix for the given home address with > > all other routing prefixes that are supported by the home agent > > processing the Binding Update. The Home Agent creates such a > > separate primary care-of address registration for each such home > > address. > > > > When `S' bit is zero, the HA creates the BCEs for the MN with all > > 'routing prefixes' it has. But I couldn't find the definition of the > > 'routing prefix'. > > > > What is the definition? > > I suspect it would be more clear if it said that the HA performs all > the functions of RFC 2462 on behalf of the mobile node. > That spec has the details of how the addresses are formed from > the prefixes advertised in router advertisements. OK. Then, a HA must create all BCEs for all addresses which are supposed to be assigned to a MN when it is on its home network. I think I now have a clear definition. Thank you. --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 09:07: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 JAA17272 for ; Thu, 14 Mar 2002 09:07:08 -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 GAA09760; Thu, 14 Mar 2002 06:06: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 GAA08354; Thu, 14 Mar 2002 06:06: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 g2EE5QKL026509 for ; Thu, 14 Mar 2002 06:05:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EE5QeO026508 for mobile-ip-dist; Thu, 14 Mar 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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EE5NKL026501 for ; Thu, 14 Mar 2002 06:05:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08134 for ; Thu, 14 Mar 2002 06:05:20 -0800 (PST) From: petteri.poyhonen@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24387 for ; Thu, 14 Mar 2002 06:05:22 -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 g2EE61i08500 for ; Thu, 14 Mar 2002 16:06:01 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 14 Mar 2002 16:05:18 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 16:05:18 +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: [mobile-ip] New proposed sub-option (Alternate Tunnel End Point Address) Date: Thu, 14 Mar 2002 16:05:18 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F911757033D13@esebe004.NOE.Nokia.com> Thread-Topic: New proposed sub-option (Alternate Tunnel End Point Address) Thread-Index: AcHLXtq/ipx/YDchEdamLAAIx1uc+A== To: Cc: X-OriginalArrivalTime: 14 Mar 2002 14:05:18.0503 (UTC) FILETIME=[45B7E370:01C1CB61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2EE5NKL026502 Sender: owner-mobile-ip@sunroof.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 all I would like to propose a new type of sub-option to be used with Binding Acknowledgement messages. Main motivation: In ForCES framework, it would be reasonable to use a different IPv6 addresses for a signaling end point (home agent address known by MN) and for a tunnel end point (separation of control and forwarding planes). This would also be useful in case of virtual home link. The usage of this sub-option could be configurable in home agent, and it should not have any major impacts to the current implementations. However for the separation to work when needed, this sub-option would be mandatory to implement in MN. Home agent's support for this option is not mandatory. It is home agent's decision when to use this sub-option if it supports it. The usage of this sub-option should not create any new security vulnerabilities because Auth sub-option is used in all BAs with this sub-option. Proposed additional chapter to the draft: 5.7. Alternate Tunnel End Point Address Alternate Tunnel End Point Address (alignment requirement: 8n+6) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Tunnel End Point Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Alternate Tunnel End Point Address sub-option is valid only in Binding Acknowledgement destination options. The Alternate Tunnel End Point Address field contains an address to use as the source address when tunneling packets from home agent to MN, and as the destination address when tunneling packets from MN to home agent. This sub-option is optional, and if home agent's own address is used as a tunnel end point address, this sub-option SHOULD NOT be used. This sub-option MUST be honored by an MN when present. Authentication data sub-option MUST be present in the same Binding Acknowledgement. Home link renumbering will trigger home agent to sent Mobile Prefix Advertisement with Binding Request destination option to MN. At the end of this message exchange, home agent will sent Binding Acknowledgement back to MN using Alternate Tunnel End Point Address sub-option for new tunnel end point address. At any time, home agent may notify MN about new tunnel end point address by adding Alternate Tunnel End Point Address sub-option to the Binding Acknowledgement. Rgs, Petteri Pöyhönen From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 16:26:11 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 QAA01461 for ; Thu, 14 Mar 2002 16:26:11 -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 NAA23340; Thu, 14 Mar 2002 13:25: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 NAA15278; Thu, 14 Mar 2002 13:24: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 g2ELNjKL027406 for ; Thu, 14 Mar 2002 13:23:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ELNjOt027405 for mobile-ip-dist; Thu, 14 Mar 2002 13: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ELNgKL027398 for ; Thu, 14 Mar 2002 13:23:42 -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 NAA14778 for ; Thu, 14 Mar 2002 13:23:45 -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 OAA18482 for ; Thu, 14 Mar 2002 14:23:44 -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 NAA04872 for ; Thu, 14 Mar 2002 13:23:43 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2ELNh424202 for ; Thu, 14 Mar 2002 13:23:43 -0800 X-mProtect:  Thu, 14 Mar 2002 13:23:43 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCBfI8P; Thu, 14 Mar 2002 13:23:41 PST Message-ID: <3C9114DD.AD29B895@iprg.nokia.com> Date: Thu, 14 Mar 2002 13:23:41 -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] about proxy DAD References: <20020308042835.359fdc71.yukiyo_akisada@yokogawa.co.jp> 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 Yukiyo, Whatever the 'S' bit is set to, the conservative approach for the home agent would be to perform DAD for both the home address and link local address of the mobile node. But as RFC 2462 says, DAD can be skipped for the home address if stateless configuration is used and the interface id is going to be the same for the home address and the link local address. And when you chose to skip, it can be skipped for both cases ('S' bit set to 0/1). Vijay Yukiyo Akisada wrote: > > Hi, all. > > I have some quiestions about proxy DAD. > > When the MN sends BU (S bit is 0), > should HA execute DAD for only MN's link-local home address? > or both of link-local and global addess? > > And when the MN sends BU (S bit is 1), > should HA execute DAD for only global address? > or not? > > ID-15 chapter 9.1 says that > > - Finally, if the Duplicate Address Detection (D) bit is set in > the Binding Update, this home agent MUST perform Duplicate > Address Detection [27] on the mobile node's home link for the > home address in this binding (before returning the Binding > Acknowledgement). The address used for Duplicate Address > Detection SHOULD be the mobile node's link-local address. > > and > > If the `S' bit field in the Binding Update is zero, The Home Agent > creates or updates Binding Cache entries for each of possible > several home addresses. The set of such home addresses is formed > by replacing the routing prefix for the given home address with > all other routing prefixes that are supported by the home agent > processing the Binding Update. The Home Agent creates such a > separate primary care-of address registration for each such home > address. Note that the same considerations for Duplicate Address > Detection apply for each affected home address. > > I'm little confusing about this. > > Regards. > > ---- > Yukiyo Akisada @ TAHI Project From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 18:20:24 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 SAA04175 for ; Thu, 14 Mar 2002 18:20:23 -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 QAA12939; Thu, 14 Mar 2002 16:19:59 -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 PAA29118; Thu, 14 Mar 2002 15:18: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 g2ENHbKL027732 for ; Thu, 14 Mar 2002 15:17:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ENHaN2027731 for mobile-ip-dist; Thu, 14 Mar 2002 15:17: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 g2ENHXKL027724 for ; Thu, 14 Mar 2002 15:17: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 PAA28680 for ; Thu, 14 Mar 2002 15:17:35 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05931 for ; Thu, 14 Mar 2002 16:17:34 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2ENHYI11997 for ; Thu, 14 Mar 2002 15:17:34 -0800 (PST) Message-ID: <096901c1cbae$325bf580$7e6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Thu, 14 Mar 2002 15:15:57 -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'm reading through Section 10.10 in the MIPv6 spec, and there is a description how to establish forwarding from previous care of address by sending a BU to a "home agent on the previous link". In Section 10.5, it describes how an AR advertises a global unicast address for use as a local "home agent." I'm wondering about the security implications of this. One of the nice security aspects of IPv6 router discovery is that the hosts don't learn anything other than a link local address for the routers. This helps prevent attackers from outside the local network hacking into routers. I would expect that a router might have a site local address for network management purposes, but a global address? And is it such a good idea to expose that address to hosts? Do people think this option will be widely deployed? Also, given that it is deployed, what should the security requirements be on sending a BU to this local "home agent"? Should they be the same as for a CN, namely default RR and something stronger when we figure out what? Or as for sending a BU to the home network home agent, namely based on an IPsec SA? I haven't seen any discussion of this, so maybe it isn't particularly important, but it struck me as curious. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 19:05: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 TAA05342 for ; Thu, 14 Mar 2002 19:05: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 RAA18252; Thu, 14 Mar 2002 17:05:18 -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 QAA13979; Thu, 14 Mar 2002 16:03: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 g2F02vKL027821 for ; Thu, 14 Mar 2002 16:02:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F02uPc027820 for mobile-ip-dist; Thu, 14 Mar 2002 16:02: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F02rKL027813 for ; Thu, 14 Mar 2002 16:02:53 -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 QAA13668 for ; Thu, 14 Mar 2002 16:02:56 -0800 (PST) Received: from web10708.mail.yahoo.com (web10708.mail.yahoo.com [216.136.130.216]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA17261 for ; Thu, 14 Mar 2002 17:02:55 -0700 (MST) Message-ID: <20020315000254.87264.qmail@web10708.mail.yahoo.com> Received: from [165.213.0.2] by web10708.mail.yahoo.com via HTTP; Thu, 14 Mar 2002 16:02:54 PST Date: Thu, 14 Mar 2002 16:02:54 -0800 (PST) From: Suvidh Mathur Subject: Re: [mobile-ip] about proxy DAD To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3C9114DD.AD29B895@iprg.nokia.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, In continuation of Yukio's mail, I also have a small doubt regarding the scenario when S bit is set to zero. The draft says "The set of such home > addresses is formed by replacing the routing prefix for the given home address with all other routing prefixes that are supported by the home agent processing the Binding Update". What does supported by HA mean? Does it mean for all prefixes advertised by the HA, or does it mean for all addresses advertised on the home link (including prefixes advertised by other routers on the home link) regards, suvidh --- Vijay Devarapalli wrote: > hi Yukiyo, > > Whatever the 'S' bit is set to, the conservative > approach > for the home agent would be to perform DAD for both > the > home address and link local address of the mobile > node. > > But as RFC 2462 says, DAD can be skipped for the > home > address if stateless configuration is used and the > interface id is going to be the same for the home > address > and the link local address. And when you chose to > skip, > it can be skipped for both cases ('S' bit set to > 0/1). > > Vijay > > > Yukiyo Akisada wrote: > > > > Hi, all. > > > > I have some quiestions about proxy DAD. > > > > When the MN sends BU (S bit is 0), > > should HA execute DAD for only MN's link-local > home address? > > or both of link-local and global addess? > > > > And when the MN sends BU (S bit is 1), > > should HA execute DAD for only global address? > > or not? > > > > ID-15 chapter 9.1 says that > > > > - Finally, if the Duplicate Address Detection > (D) bit is set in > > the Binding Update, this home agent MUST > perform Duplicate > > Address Detection [27] on the mobile node's > home link for the > > home address in this binding (before > returning the Binding > > Acknowledgement). The address used for > Duplicate Address > > Detection SHOULD be the mobile node's > link-local address. > > > > and > > > > If the `S' bit field in the Binding Update is > zero, The Home Agent > > creates or updates Binding Cache entries for > each of possible > > several home addresses. The set of such home > addresses is formed > > by replacing the routing prefix for the given > home address with > > all other routing prefixes that are supported > by the home agent > > processing the Binding Update. The Home Agent > creates such a > > separate primary care-of address registration > for each such home > > address. Note that the same considerations for > Duplicate Address > > Detection apply for each affected home address. > > > > I'm little confusing about this. > > > > Regards. > > > > ---- > > Yukiyo Akisada @ TAHI Project __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 19:11: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 TAA05482 for ; Thu, 14 Mar 2002 19:11: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 QAA24359; Thu, 14 Mar 2002 16:10: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 QAA16712; Thu, 14 Mar 2002 16: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 g2F09mKL027888 for ; Thu, 14 Mar 2002 16:09:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F09mj5027887 for mobile-ip-dist; Thu, 14 Mar 2002 16:09: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 g2F09jKL027880 for ; Thu, 14 Mar 2002 16:09:45 -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 QAA18541 for ; Thu, 14 Mar 2002 16:09:47 -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 RAA20217 for ; Thu, 14 Mar 2002 17:09:46 -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 QAA14679 for ; Thu, 14 Mar 2002 16:09:46 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2F09jM15081 for ; Thu, 14 Mar 2002 16:09:45 -0800 X-mProtect:  Thu, 14 Mar 2002 16:09:45 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxx1fFc; Thu, 14 Mar 2002 16:09:44 PST Message-ID: <3C913BC8.BC9A5879@iprg.nokia.com> Date: Thu, 14 Mar 2002 16:09:44 -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] about proxy DAD References: <20020315000254.87264.qmail@web10708.mail.yahoo.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, Suvidh Mathur wrote: > > Hi, > > In continuation of Yukio's mail, I also have a small > doubt regarding the scenario when S bit is set to > zero. The draft says "The set of such home > > addresses is formed by replacing the routing prefix > for the given home address with all other routing > prefixes that are supported by the home agent > processing the Binding Update". > What does supported by HA mean? Does it mean for all > prefixes advertised by the HA, or does it mean for all > addresses advertised on the home link (including > prefixes advertised by other routers on the home link) By all routers on the home link. The important part here is the 'home link'. It *does not* mean all the routers in the home domain/network/whatever. Vijay > > regards, > suvidh > > --- Vijay Devarapalli wrote: > > hi Yukiyo, > > > > Whatever the 'S' bit is set to, the conservative > > approach > > for the home agent would be to perform DAD for both > > the > > home address and link local address of the mobile > > node. > > > > But as RFC 2462 says, DAD can be skipped for the > > home > > address if stateless configuration is used and the > > interface id is going to be the same for the home > > address > > and the link local address. And when you chose to > > skip, > > it can be skipped for both cases ('S' bit set to > > 0/1). > > > > Vijay > > > > > > Yukiyo Akisada wrote: > > > > > > Hi, all. > > > > > > I have some quiestions about proxy DAD. > > > > > > When the MN sends BU (S bit is 0), > > > should HA execute DAD for only MN's link-local > > home address? > > > or both of link-local and global addess? > > > > > > And when the MN sends BU (S bit is 1), > > > should HA execute DAD for only global address? > > > or not? > > > > > > ID-15 chapter 9.1 says that > > > > > > - Finally, if the Duplicate Address Detection > > (D) bit is set in > > > the Binding Update, this home agent MUST > > perform Duplicate > > > Address Detection [27] on the mobile node's > > home link for the > > > home address in this binding (before > > returning the Binding > > > Acknowledgement). The address used for > > Duplicate Address > > > Detection SHOULD be the mobile node's > > link-local address. > > > > > > and > > > > > > If the `S' bit field in the Binding Update is > > zero, The Home Agent > > > creates or updates Binding Cache entries for > > each of possible > > > several home addresses. The set of such home > > addresses is formed > > > by replacing the routing prefix for the given > > home address with > > > all other routing prefixes that are supported > > by the home agent > > > processing the Binding Update. The Home Agent > > creates such a > > > separate primary care-of address registration > > for each such home > > > address. Note that the same considerations for > > Duplicate Address > > > Detection apply for each affected home address. > > > > > > I'm little confusing about this. > > > > > > Regards. > > > > > > ---- > > > Yukiyo Akisada @ TAHI Project > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 21:02:24 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 VAA07757 for ; Thu, 14 Mar 2002 21:02:23 -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 TAA16854; Thu, 14 Mar 2002 19:01: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 SAA00696; Thu, 14 Mar 2002 18:01: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 g2F20CKL028205 for ; Thu, 14 Mar 2002 18:00:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F20BcC028204 for mobile-ip-dist; Thu, 14 Mar 2002 18:00: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F208KL028197 for ; Thu, 14 Mar 2002 18:00:08 -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 SAA00427 for ; Thu, 14 Mar 2002 18:00:10 -0800 (PST) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01543 for ; Thu, 14 Mar 2002 19:00:08 -0700 (MST) Received: from bahamas.64translator.com (itgw [10.21.254.82]) by mail.64translator.com (8.11.6/8.11.6) with ESMTP id g2F207X24815 for ; Fri, 15 Mar 2002 11:00:07 +0900 (JST) Received: from odin.akisada.jp (dhcp161.64translator.com [10.21.32.161]) by bahamas.64translator.com (8.11.4/8.11.4) with SMTP id g2F206H18403 for ; Fri, 15 Mar 2002 11:00:06 +0900 (JST) Date: Fri, 15 Mar 2002 11:00:05 +0900 From: Yukiyo Akisada To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] about proxy DAD Message-Id: <20020315110005.3287a2ec.yukiyo_akisada@yokogawa.co.jp> In-Reply-To: <3C9114DD.AD29B895@iprg.nokia.com> References: <20020308042835.359fdc71.yukiyo_akisada@yokogawa.co.jp> <3C9114DD.AD29B895@iprg.nokia.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 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. On Thu, 14 Mar 2002 13:23:41 -0800 Vijay Devarapalli wrote: > But as RFC 2462 says, DAD can be skipped for the home > address if stateless configuration is used and the > interface id is going to be the same for the home address > and the link local address. And when you chose to skip, > it can be skipped for both cases ('S' bit set to 0/1). I can find this sentence in RFC2462. Now, I'm clear. Thanks. ---------------------------------------- Yokogawa Electric Corporation ---------------------------------------- Yukiyo AKisada @ TAHI Project e-mail: Yukiyo.Akisada@jp.yokogawa.com ---------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 14 22:21: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 WAA10160 for ; Thu, 14 Mar 2002 22:21: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 UAA06635; Thu, 14 Mar 2002 20:20: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 TAA12461; Thu, 14 Mar 2002 19: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 g2F3JYKL028491 for ; Thu, 14 Mar 2002 19:19:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F3JY4S028490 for mobile-ip-dist; Thu, 14 Mar 2002 19:19: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 jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F3JVKL028483 for ; Thu, 14 Mar 2002 19:19:31 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g2F3JXXO990411; Thu, 14 Mar 2002 19:19:33 -0800 (PST) Message-Id: <200203150319.g2F3JXXO990411@jurassic.eng.sun.com> Date: Thu, 14 Mar 2002 19:21:43 -0800 (PST) From: Samita Chakrabarti Subject: [mobile-ip] A guideline draft fro LPAS (extension to RFC3024) To: mobile-ip@sunroof.eng.sun.com Cc: samita@eng.sun.com, gab@sun.com, yokota@kddilabs.jp MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Hover_of_Trout_134_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --Hover_of_Trout_134_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: esG+FsylBSEwWvGrW+rtpA== A few IETFs ago it was decided at the working group to produce a draft clarifying limited private address support ( manadatory part if you support reverse tunneling) described in the appendix of RFC3024. Gabriel Montenegro, Hidetoshi Yokota and myself submitted a draft explaining the LPAS scenarios and guidlines for implementations. For some reason the announcement did not go out on the list. But it's available in the draft directory as draft-chakrabarti-mobileip-privaddr-00.txt Please provide your comments. Thanks, -Samita --Hover_of_Trout_134_000 Content-Type: TEXT/plain; name="draft-chakrabarti-mobileip-privaddr-00.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-chakrabarti-mobileip-privaddr-00.txt Content-MD5: JzlImgEijdslZ6kEdOEdFw== INTERNET DRAFT Samita Chakrabarti Category: Informational Gabriel Montenegro Title: draft-chakrabarti-mobileip-privaddr-00.txt Sun Microsystems, Inc. Date: February 2002 Hidetoshi Yokota KDDI R&D Laboratories, Inc. Limited Private Address Support: An addendum to Reverse Tunneling for Mobile IP (RFC3024) Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 2000. All Rights Reserved. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 1] INTERNET DRAFT February 2002 Abstract Reverse Tunneling for Mobile IP [1] defines limited private address support for mobile nodes and mobile agents. This document provides information and guidance to the users on the requirements and desc- ribes implementation issues regarding Limited Private Address Support for Mobile IP [2]. This document's purpose is to clarify Mobile IPv4 temporary deployment scenarios within an operator's environment where private IPv4 addresses are required for the mobile devices. However, the scenarios and communication between private addressed mobile nodes have limited usage. Solutions involving Network Address Translation are out of scope of this document. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Mobile Node Requirements 4.0 Home Agent Requirements 5.0 Foreign Agent Requirments 6.0 Possible usage scenarios 7.0 Implementation Considerations and Limitations 8.0 Acknowledgements 9.0 References 10.0 Authors' Addresses 11.0 Full Copyright Statement 1.0 Introduction Appendix A.4 of Reverse Tunneling for Mobile IP [1] discusses Limited Privated Address Scenarios (LPAS), but it is not very clear from the appendix that a reverse tunnel implementation MUST also support Limited Private Address Scenarios. This document clarifies Appendix A.4 of Reverse Tunneling for Mobile IP [1]. The private addresses discussed here are limited to mobile node addresses only. Private addresses are defined in RFC1918 [3]. The solutions discussed in the document is solely based upon Mobile IP [2] and Reverse Tunneling for Mobile IP [1]. No other mechanisms such as Network Address Trnaslators etc. are part of this solution. It has been deemed by ISPs that having reverse tunnel and limited private address support in their operating environment are essential for deployment of mobile IP devices as number of publicly routable IP-addresses are scarce and do not meet the demand of high volume of mobile devices, such as laptops, PDAs and cell-phones. Private addressed mobile nodes can be deployed in 3G wireless environment and as well as in enterprise realms. The private addressed mobile nodes are associated with it's home agent and thus two mobile nodes belonging to same home agent can Chakrabarti, Montenegro, Yokota expires August 2002 [Page 2] INTERNET DRAFT February 2002 communicate with each other through reverse tunnel even when they are visiting foreign domains. The packets from the private mobile nodes to each other must be reverse tunneled, as the private addresses are not routable through the internet. However, the assumption is that the foreign agent's care-of-address and home agent address are all publicly routable addresses. Operation in the presence of route optimization [4] is outside the scope of this document. 2.0 Terminology The document uses the following terms in addition to what is defined in [1] and [2]. LPAS Limited Privated address Scenario which can be used by ISPs and enterprizes given the current state of Mobile IP specifications. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [9]. 3.0 Mobile Node Requirements The following are the requirements for private addressed mobile nodes in the limited private address support scenario. o Mobile node MUST obtain reverse tunnel through registration as described in Reverse Tunneling for Mobile IP [1]. o A mobile node MUST have unique home address in it's home domain o A mobile node with public co-located COA may use private home address via reverse tunnel o A mobile node may never visit home and always roams. An example will be cell-phones. 4.0 Home Agent Requirements o Home Agent MUST support reverse tunnel encapsulation and decapsulation and process registration request with 'T' bit set. o The home agent MUST not support overlapping private addresses for mobile node's home address. Thus it MUST assign unique private home address to each of it's mobile nodes. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 3] INTERNET DRAFT February 2002 o The home agent SHOULD be able to assign private addresses out of it's address pool to the mobile nodes for use of home addresses. This is in accordance with section 3.8 of [2]. o Home agent address MUST be a publicly routable address. 5.0 Foreign Agent Requirements o All advertising interfaces of the foreign agent MUST have publicly routable care-of address. Thus, a mobile node with a private address visits the foreign agent only in its publicly routable network. This restriction is to avoid visiting private addressed subnets in the foreign network. o Foreign agents MUST support reverse tunneling in order to support private addressed mobile nodes. If a foreign agent receives a registration request from a mobile node with a private address, and the mobile node has not set the 'T' bit, the foreign agent SHOULD reject it. o If a foreign agent supports reverse tunneling, then it MUST support the simple scenario of private address support, i.e LPAS. o A foreign agent MUST disambiguate among mobile nodes with conflicting private addresses by using link-layer inforamtion and or home-agent information. o A foreign agent should make sure that two mobile nodes visiting the same foreign agent corresponds with each other through their respective home agents. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 4] INTERNET DRAFT February 2002 6.0 Possible Usage Scenarios 1) Two private addressed mobile nodes visiting same foreign agent and the mobile nodes have same home agent. 10.10.1.2 +----+ IF1=COA1+-------+ | MN1|------------------------| FA | +----+ +------------| | | IF2=COA2+-------+ +---+ | | | +-----+ | | MN2 | | +-----+ | 10.10.3.2 | | HAA1 +------+ | HA1 | +------+ Note that if IF1 = IF2, then COA1 = COA2 and this is a valid scenario or configuration. COA1, COA2 and HAA1 are all publicly routable addresses. 2) Two private addressed mobile nodes visiting same foreign agent and the mobile nodes have different home agent. MN1 and MN2 may or may not have same (overlapping) IP -addresses. 10.10.1.2 +----+ IF1=COA1+-------+ HAA2 +-----+ | MN1|------------------------| FA |---------| HA2 | +----+ +------------| | +-----+ | IF2=COA2+-------+ +---+ | | | +-----+ | | MN2 | | +-----+ | 10.10.1.2 | | HAA1 +------+ | HA1 | +------+ Note that even if MN1 and MN2 are connected to the same FA, they are Chakrabarti, Montenegro, Yokota expires August 2002 [Page 5] INTERNET DRAFT February 2002 logically separated by reverse tunneling, and they don't communicate each other since they belong to different HAs. For the case that IF1 = IF2, refer to section 7.0. 3) Two mobile nodes are visiting different foreign networks/foreign agents, the mobile nodes actually belong to a single home agent. 10.10.1.2 +----+ IF1=COA1+-------+ HAA2 +-----+ | MN1|------------------------| FA1 |---------| HA | +----+ | | +-----+ +-------+ | 10.10.1.5 | +-----+ | | MN2 |-----+ | +-----+ | IF2=COA2 | +-------+ | | | +------+ | FA2 | | | +------+ 7.0 Implementation Considerations and Limitations When two mobile nodes with same private addresses visit a single foreign agent on the same shared link or share the same COA, foreign agent must distinguish between the two, in both direction of packet flow. For example, in forward direction, if mobile nodes use unique point to point links, foreign agent can distinguish easily by their interface identification. But there is a problem when the mobile nodes sharing same private addresses visit the foreign agent on the same shared link such as ethernet. In this case, IP address to ethernet address mapping becomes ambigous, thus ethernet address lookup must consider some other mobile-node specific information to support private addressed mobile nodes correctly on the shared link. The same problem appears while forwarding to the reverse tunnel, to avoid this problem reverse tunnel lookup may consider matching with ethernet address as well. This may not be an easy solution and may require architectural change in the IP kernel implementation. In a nutshell, it is better to provide mobility service to the private addressed mobile nodes through one-to-one link - such as point-to- point link in 3G wireless CDMA environment. Some implementations may choose to use other link-level information, such as mobile node identification number to distinguish between two conflicting private addressed mobile nodes visitng the same agent on the same link. Appendix A.3 of RFC3024 [1] has elaborated this situation. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 6] INTERNET DRAFT February 2002 If a private addressed mobile node registers with two diferent home agents using the same shared link or via same COA, it SHOULD use different home addresses. Thus a foreign agent should use to distinguish two different private addressed mobile nodes in the reverse direction (for reverse tunnel). Note that MN's unique identification is implementation dependent. From the above scenarios it can be observed that two private mobile nodes can communicate to each other if they belong to the same home agent. A private-addressed mobile node can communicate to a correspondent node in its home network. But the mobile node will not be able to communicate with a correspondent node in the global internet. In order to solve this problem, it is recommended that the mobile node implementation should request a global address to it's home-agent through NAI. This requires modification of RFC2794 as currently it does not distinguish between private and global addresses. (XXX: How about having a modification in rfc2794 to introduce another field for address type ?) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address Type | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type = 0 (global) 1(private) Alternatively, a mobile node may be configured with separate home agent services for supplying private and public addresses to it. Thus, it can obtain public address through the designated home agent when necessary to use a global home-address. This solution implies that a address-less mobile-node can be configured with two home-agent addresses, each providing private ip-address and global ip-address respectively via NAI [8] request. The expiration period of the assignment of a global address to a mobile node should not be shorter than the accepted lifetime of the registration, and it should be extended when the registration is successfully updated. Private addressed mobile nodes using Network Address Translation [6] are out of scope of this document. Such situations are discussed in Mobile IP NAT/NATPT traversal [7] document. However, adoption of Mobile IPv6 [9] will provide a long term solution for device address scalability. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 7] INTERNET DRAFT February 2002 8.0 Acknowledgements The authors like to acknowledge Tom Hiller and David Welch of Lucent Technologies for the idea of having private addressed only mobile nodes in the MobileIP deployment scenarios. Also we acknowledge Erik Nordmark of Sun Microsystems for the intial idea on 'limited' private address usage as a temporary solution of Mobile IPv4 deployment scenario. 9.0 References [1] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 3024, January 2001. [2] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [3] Rekhter, Y.et al., "Address Allocation for Private Internets", RFC 1918, February, 1996. [4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress. [6] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [7] Levkowetz, H and S. Vaarala, "Mobile IP NAT/NAPT Traversal using UDP Tunnelling", draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt, Work in Progress. [8] Calhoun, P and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC2794, March 2000. [9] D. Johnson, C. Perkins. "Mobility Support in IPv6", draft- ietf-mobileip-ipv6-15.txt. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 8] INTERNET DRAFT February 2002 Editor and Chair Addresses Questions about this document may be directed at: Samita Chakrabarti Sun Microsystems 901 San Antonio Road Palo Alto, CA 94303 USA Phone: +1 650-786-5068 EMail: samita.chakrabarti@Sun.com Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE Phone: +33 476 18 80 45 EMail: gab@sun.com Hidetoshi Yokota Mobile IP Network Laboratory KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Kamifukuoka Saitama 356-8502 JAPAN Phone: +81 (492) 78-7894 Fax: +81 (492) 78-7510 EMail: yokota@kddilabs.jp The working group can be contacted via the current chairs: Basavaraj Patil Nokia Networks 6000 Connection Drive Irving, TX 75039 USA Phone: +1 972-894-6709 Fax : +1 972-894-5349 EMail: Raj.Patil@nokia.com Chakrabarti, Montenegro, Yokota expires August 2002 [Page 9] INTERNET DRAFT February 2002 Phil Roberts Motorola 1501 West Shure Drive Arlington Heights, IL 60004 USA Phone: +1 847-632-3148 EMail: QA3445@email.mot.com 11.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chakrabarti, Montenegro, Yokota expires August 2002 [Page 10] --Hover_of_Trout_134_000-- From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 02:35:20 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 CAA22754 for ; Fri, 15 Mar 2002 02:35:19 -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 AAA11684; Fri, 15 Mar 2002 00:34:44 -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 XAA02274; Thu, 14 Mar 2002 23:34: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 g2F7XqKL028866 for ; Thu, 14 Mar 2002 23:33:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F7Xp40028865 for mobile-ip-dist; Thu, 14 Mar 2002 23:33: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F7XmKL028858 for ; Thu, 14 Mar 2002 23:33:48 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26837 for ; Thu, 14 Mar 2002 23:33:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02259 for ; Thu, 14 Mar 2002 23:33:49 -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 XAA02763 for ; Thu, 14 Mar 2002 23:33:47 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2F7Xlm07760 for ; Thu, 14 Mar 2002 23:33:47 -0800 X-mProtect:  Thu, 14 Mar 2002 23:33:47 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtObJJM; Thu, 14 Mar 2002 23:33:45 PST Message-ID: <3C91A3E7.F660647D@iprg.nokia.com> Date: Thu, 14 Mar 2002 23:33:59 -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] Consensus to include recent piggybacking proposal? 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 few days ago, I posted a proposal worked out by Jari Malinen, Francis Dupont, and myself that should be a very simple way to eliminate any possible inconsistency between piggybacking and IPsec -- by the simple device of having a "final" Mobility Header and a "nonfinal" Mobility Header, that are otherwise the same. In this way, all possible conflicts with IPsec are removed, and yet endpoints that enable payload with Binding Updates are able to get that performance improvement. In order to avoid duplicating text, I put the proposal at the following URL: http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt Before this proposal, there was a pretty even split within the working group -- some were for, some against. The main objection seems to center around difficulty with IPsec policy management, and our proposal eliminates that problem entirely. Thus, I think that we should be able to include this into the base specification, and I am hoping that there will be no one objecting -- because in effect everyone gets what they want! With this note, I am attempting to gauge consensus on this issue. Thanks for your consideration of my request. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 02:35: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 CAA22768 for ; Fri, 15 Mar 2002 02:35: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 XAA18797; Thu, 14 Mar 2002 23:34: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 XAA02267; Thu, 14 Mar 2002 23: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 g2F7XYKL028856 for ; Thu, 14 Mar 2002 23:33:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F7XYEp028855 for mobile-ip-dist; Thu, 14 Mar 2002 23:33: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F7XTKL028848 for ; Thu, 14 Mar 2002 23:33:29 -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 XAA02158 for ; Thu, 14 Mar 2002 23:33:29 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA10180 for ; Thu, 14 Mar 2002 23:33:28 -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 g2F7XRUw014462 for ; Fri, 15 Mar 2002 08:33:27 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Fri Mar 15 08:33:27 2002 +0100 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 08:32:12 +0100 Message-ID: From: "Peter Grimstrup (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" , "'kempf@docomolabs-usa.com'" Subject: RE: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 08:32:42 +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: Comment inline: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 15. marts 2002 00:16 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Security on Local "Home Agent" Functionality? > > > I'm reading through Section 10.10 in the MIPv6 spec, and there is a > description how to establish forwarding from previous care of > address by > sending a BU to a "home agent on the previous link". In > Section 10.5, it > describes how an AR advertises a global unicast address for use as a > local "home agent." I'm wondering about the security implications of > this. > > One of the nice security aspects of IPv6 router discovery is that the > hosts don't learn anything other than a link local address for the Not correct any more: A Home Agent reveals its own full address using the "Modified Prefix Information Option" (6.2 in draft-15). This is needed by other Home Agents to build the list of Home Agents for the "Home Address Discovery" procedure. Peter > routers. This helps prevent attackers from outside the local network > hacking into routers. I would expect that a router might have a site > local address for network management purposes, but a global > address? And > is it such a good idea to expose that address to hosts? Do > people think > this option will be widely deployed? > > Also, given that it is deployed, what should the security requirements > be on sending a BU to this local "home agent"? Should they be the same > as for a CN, namely default RR and something stronger when we > figure out > what? Or as for sending a BU to the home network home agent, namely > based on an IPsec SA? > > I haven't seen any discussion of this, so maybe it isn't particularly > important, but it struck me as curious. > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 10:31: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 KAA01611 for ; Fri, 15 Mar 2002 10:31: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 IAA27129; Fri, 15 Mar 2002 08:30: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 HAA00160; Fri, 15 Mar 2002 07:30: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 g2FFTNKL029745 for ; Fri, 15 Mar 2002 07:29:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FFTMU0029744 for mobile-ip-dist; Fri, 15 Mar 2002 07:29: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 g2FFTIKL029737 for ; Fri, 15 Mar 2002 07:29:19 -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 g2FFTEx21373; Fri, 15 Mar 2002 16:29:15 +0100 (MET) Date: Fri, 15 Mar 2002 16:29:12 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <096901c1cbae$325bf580$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 of the nice security aspects of IPv6 router discovery is that the > hosts don't learn anything other than a link local address for the > routers. This helps prevent attackers from outside the local network > hacking into routers. I would expect that a router might have a site > local address for network management purposes, but a global address? And > is it such a good idea to expose that address to hosts? Do people think > this option will be widely deployed? The MIPv6 specification has a mechanism (the 'R' bit in prefix options for router advertisements) that allow for home agent discovery to work as well as this HA for a previous CoA to work. That has the effect of providing global as well as site-local addresses of the router to the nodes on the link. I don't think security of the routers should depend on their global addresses being 'secret'. Traceroute would presumably return them in any case. The benefits of creating a binding for a previous CoA is a function of the time it takes to do this update - the goal is to prevent packets that are in transit from CNs (and perhaps MN) from being dropped on the previous link. Perhaps this is better done using other local mechanisms to minimize packet drops during handoff? > Also, given that it is deployed, what should the security requirements > be on sending a BU to this local "home agent"? Should they be the same > as for a CN, namely default RR and something stronger when we figure out > what? Or as for sending a BU to the home network home agent, namely > based on an IPsec SA? The security requirements for the HA result in the assumption that the MN has a pre-configured arrangement with its HA in order to associate the authorization to do bindings for the HoA with an IPsec SA. If this is applied to the HA for the previous CoA it would seem to require some form of pre-establishment there as well. But that wouldn't introduce any new security concerns and not require additional specification work. Doing RR after the MN has moved away doesn't work. The RR check for the HoA i.e. previous CoA in this case would assume that the MN is reachable at the previous CoA, which it isn't. So unless this RR check is performed (and "refreshed") before the MN moves and the RR check for the new CoA is done after the move, can RR be made to work in this case. Seems complex. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 10:42: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 KAA01879 for ; Fri, 15 Mar 2002 10:42: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 IAA14915; Fri, 15 Mar 2002 08:41: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 HAA02584; Fri, 15 Mar 2002 07:41: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 g2FFerKL029841 for ; Fri, 15 Mar 2002 07:40:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FFerVe029840 for mobile-ip-dist; Fri, 15 Mar 2002 07:40: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 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 g2FFenKL029833 for ; Fri, 15 Mar 2002 07:40:50 -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 g2FFehx24884; Fri, 15 Mar 2002 16:40:43 +0100 (MET) Date: Fri, 15 Mar 2002 16:40:41 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal? To: charliep@iprg.nokia.com Cc: Mobile IP Working Group In-Reply-To: "Your message with ID" <3C91A3E7.F660647D@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: > Before this proposal, there was a pretty even split within the > working group -- some were for, some against. The main objection > seems to center around difficulty with IPsec policy management, > and our proposal eliminates that problem entirely. Thus, I think > that we should be able to include this into the base specification, > and I am hoping that there will be no one objecting -- because > in effect everyone gets what they want! Charlie, I recall seeing a point about security gateways imposing policy i.e. the sender of the piggybacked message might not be able to tell what policies apply to the MH and the payload in the case of a SG with fine-grained policy. I think this needs to be better understood. So I think there is some additional thinking and writing necessary. I personally see no harm in pursuing this as a separate short specification - and it has benefits of being able to do things more in parallel by avoiding cramming everything into the same specification. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 13:25:01 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 NAA06669 for ; Fri, 15 Mar 2002 13:25: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 LAA00101; Fri, 15 Mar 2002 11:24: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 KAA23705; Fri, 15 Mar 2002 10:23: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 g2FIN4KL000129 for ; Fri, 15 Mar 2002 10:23:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FIN4Io000128 for mobile-ip-dist; Fri, 15 Mar 2002 10:23: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FIN1KL000120 for ; Fri, 15 Mar 2002 10:23:01 -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 KAA20195 for ; Fri, 15 Mar 2002 10:23:01 -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 LAA17193 for ; Fri, 15 Mar 2002 11:23:00 -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 KAA28228 for ; Fri, 15 Mar 2002 10:22:59 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FIMwh06597 for ; Fri, 15 Mar 2002 10:22:58 -0800 X-mProtect:  Fri, 15 Mar 2002 10:22:58 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2T4Q54; Fri, 15 Mar 2002 10:22:56 PST Message-ID: <3C923C01.BA2825A1@iprg.nokia.com> Date: Fri, 15 Mar 2002 10:22:57 -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] Mobility Extension Header (was ISSUE: Design teamrecommendation: New recommendation on piggybacking) 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 Karen, The answer is very simple. "Karen E Nielsen (TED)" wrote: > > Table 1. Piggybacking with IPsec > > > > IPSec policy for IPSec policy > > Mobility header for Payload Can piggyback > > 1. no no yes > > 2. no yes yes > > 3. yes no no > > 4. yes yes no > > > > > > From the table, the sender does not piggyback at all whenever the > > mobility extension header has an IPSec policy. > > > > For handling the first two cases, there is no need for any change > > to RFC 2401 or the existing IPSec implementations. Please let me > > know if I am wrong. > > > > > > I do not think that the assumption that the sender is able to determine > the presence of IPSec policies is valid: > > It can probably (by interacting with its IPSec module) determine the presence of IPSec policies on its own link, > and it can perhaps also (by asking the peer) determine whether there are IPsec policies on the > peers link - But what if some intermediate routers have IPSec policies anchored on the payload which > the sender has no knowledge of (e.g. protected tunnels over insecure networks > for certain kind of communications). Then the MH can result in these packets not being > properly processed (since the IPSec selector will target the MH and not the payload) > > I would therefore say that even in 1., piggybacking in general is not possible. The current proposal is to use both a final and non-final Mobility Header (MH). In Case 1, the non-final MH is used (because it is being piggybacked). And when the intermediate router (SG) receives this packet, it treats the MH as a normal extension header, scans past it, finds the payload and applies the appropriate IPSec policy. This should work. You were right, but the problem exists with the earlier proposal. Not with the most current piggybacking proposal which has both a final and non-final MH. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 13:34: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 NAA06826 for ; Fri, 15 Mar 2002 13:34: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 KAA14029; Fri, 15 Mar 2002 10:33: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 KAA27795; Fri, 15 Mar 2002 10:33: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 g2FIWkKL000227 for ; Fri, 15 Mar 2002 10:32:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FIWkJT000225 for mobile-ip-dist; Fri, 15 Mar 2002 10:32: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 g2FIWgKL000216 for ; Fri, 15 Mar 2002 10:32:42 -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 KAA12339 for ; Fri, 15 Mar 2002 10:32:42 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21860 for ; Fri, 15 Mar 2002 11:32:40 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FIWbI06225; Fri, 15 Mar 2002 10:32:37 -0800 (PST) Message-ID: <008f01c1cc4f$8ee59da0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Peter Grimstrup \(TED\)" , References: Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 10:31: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.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 Peter, > Not correct any more: > A Home Agent reveals its own full address using the "Modified Prefix > Information Option" (6.2 in draft-15). > This is needed by other Home Agents to build the list of Home Agents > for the "Home Address Discovery" procedure. > I was speaking of IPv6 routers in general. A Home Agent is a special IPv6 router, and I believe, if the BU security discussion recommendations are followed, the host will have some kind of strong, long lasting security association with it. Therefore, I don't see much problem in revealing a global address (it would be necessary for the IPsec SA anyway, if I my understanding of how IPsec policy is used in this case is correct). However, the AR is in the foreign network. Revealing a global address there is an entirely different matter. Do we expect the MN to have an IPsec SA with every AR in the foreign network that implements on-link "home agent" functionality? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14: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 OAA07368 for ; Fri, 15 Mar 2002 14:07:00 -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 LAA21918; Fri, 15 Mar 2002 11:06:26 -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 LAA19126; Fri, 15 Mar 2002 11:06: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 g2FJ5NKL000344 for ; Fri, 15 Mar 2002 11:05:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJ5N5v000343 for mobile-ip-dist; Fri, 15 Mar 2002 11: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FJ5KKL000336 for ; Fri, 15 Mar 2002 11:05: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 LAA09411 for ; Fri, 15 Mar 2002 11:05:20 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20588 for ; Fri, 15 Mar 2002 12:05:19 -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 g2FJ5IUw002734 for ; Fri, 15 Mar 2002 20:05:18 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 15 20:05:17 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 19:55:21 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB28@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Fri, 15 Mar 2002 20:05: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: Karen Nielsen sent two emails to highlight the inability to piggyback some RR messages since they are placed in IPsec tunnels by the HA. You can generalise the same problem for Security Gateways, in those cases the MN might not be aware of security policies by intermediate routers (SGs). Also the note was only relevant to IPsec and didn't address the QoS issues (e.g. when using Diffserv e2e or when having the Diffserv bits set by intermediate routers). These comments were explicitly made by David Oran and to some extent in my earlier emails. So I don't think the IPsec issues alone can justify the introduction of piggybacking in the basic spec. Hesham > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, March 15, 2002 8:34 AM > To: Mobile IP Working Group > Subject: [mobile-ip] Consensus to include recent > piggybacking proposal? > > > Hello folks, > > A few days ago, I posted a proposal worked out by Jari Malinen, > Francis Dupont, and myself that should be a very simple way to > eliminate any possible inconsistency between piggybacking and > IPsec -- by the simple device of having a "final" Mobility Header > and a "nonfinal" Mobility Header, that are otherwise the same. > In this way, all possible conflicts with IPsec are removed, and > yet endpoints that enable payload with Binding Updates are able > to get that performance improvement. > > In order to avoid duplicating text, I put the proposal at the > following URL: > http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt > > Before this proposal, there was a pretty even split within the > working group -- some were for, some against. The main objection > seems to center around difficulty with IPsec policy management, > and our proposal eliminates that problem entirely. Thus, I think > that we should be able to include this into the base specification, > and I am hoping that there will be no one objecting -- because > in effect everyone gets what they want! > > With this note, I am attempting to gauge consensus on this issue. > > Thanks for your consideration of my request. > > Regards, > Charlie P. > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14:22: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 OAA07681 for ; Fri, 15 Mar 2002 14:22: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 MAA28874; Fri, 15 Mar 2002 12:21: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 LAA27372; Fri, 15 Mar 2002 11:21: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 g2FJKZKL000442 for ; Fri, 15 Mar 2002 11:20:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJKZ0X000441 for mobile-ip-dist; Fri, 15 Mar 2002 11:20: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 g2FJKWKL000434 for ; Fri, 15 Mar 2002 11:20:32 -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 LAA16177 for ; Fri, 15 Mar 2002 11:20:32 -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 LAA08876 for ; Fri, 15 Mar 2002 11:20:32 -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 g2FJMlx05754 for ; Fri, 15 Mar 2002 13:22:47 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 13:20:30 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 13:20:09 -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] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 13:20:09 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12A27@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Security on Local "Home Agent" Functionality? Thread-Index: AcHMUCUiWvvh3QvVRxSYeN1XqPBdNQABjn0A To: Cc: X-OriginalArrivalTime: 15 Mar 2002 19:20:09.0512 (UTC) FILETIME=[6C0CDA80:01C1CC56] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FJKWKL000435 Sender: owner-mobile-ip@sunroof.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 James Kempf [kempf@docomolabs-usa.com] wrote: > >However, the AR is in the foreign network. Revealing >a global address there is an entirely different matter. >Do we expect the MN to have an IPsec SA with >every AR in the foreign network that implements >on-link "home agent" functionality? The DT recommends that "on-link" or temporary home agent (previous AR) should process BUs from MNs only if it has an SA with it. The same security requirements that are applicable for the normal MN-HA BUs are aplicable to the temporary HA. The base MIPv6 specification hence will not permit MNs to send BUs to previous ARs (temporary HA). However with FMIPv6 or other future extensions we could specify how an MN can establish an SA with its AR which can be for the specific purpose of having the AR act as a temp HA. > > > jak -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14:27: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 OAA07831 for ; Fri, 15 Mar 2002 14:27: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 LAA27351; Fri, 15 Mar 2002 11:26:58 -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 LAA29904; Fri, 15 Mar 2002 11: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 g2FJQ4KL000543 for ; Fri, 15 Mar 2002 11:26:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJQ4M0000542 for mobile-ip-dist; Fri, 15 Mar 2002 11: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FJQ0KL000535 for ; Fri, 15 Mar 2002 11:26:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29482 for ; Fri, 15 Mar 2002 11:26:01 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08407 for ; Fri, 15 Mar 2002 11:26:05 -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 LAA03176 for ; Fri, 15 Mar 2002 11:26:00 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FJPOs06912 for ; Fri, 15 Mar 2002 11:25:24 -0800 X-mProtect:  Fri, 15 Mar 2002 11:25:24 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpds25Xxz; Fri, 15 Mar 2002 11:25:23 PST Message-ID: <3C924AA3.956FD2A4@iprg.nokia.com> Date: Fri, 15 Mar 2002 11:25: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal? References: <4DA6EA82906FD511BE2F00508BCF053802C6AB28@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: > > Karen Nielsen sent two emails to highlight > the inability to piggyback some RR messages > since they are placed in IPsec tunnels > by the HA. You can generalise the same > problem for Security Gateways, in those cases > the MN might not be aware of security policies by > intermediate routers (SGs). And I responded to Karen. It is not an issue with the current proposal. Vijay > Also the note was only relevant to IPsec and > didn't address the QoS issues (e.g. when using > Diffserv e2e or when having the Diffserv bits > set by intermediate routers). These comments > were explicitly made by David Oran and to some > extent in my earlier emails. > So I don't think the IPsec issues alone can justify > the introduction of piggybacking in the basic > spec. > > Hesham > > > -----Original Message----- > > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Friday, March 15, 2002 8:34 AM > > To: Mobile IP Working Group > > Subject: [mobile-ip] Consensus to include recent > > piggybacking proposal? > > > > > > Hello folks, > > > > A few days ago, I posted a proposal worked out by Jari Malinen, > > Francis Dupont, and myself that should be a very simple way to > > eliminate any possible inconsistency between piggybacking and > > IPsec -- by the simple device of having a "final" Mobility Header > > and a "nonfinal" Mobility Header, that are otherwise the same. > > In this way, all possible conflicts with IPsec are removed, and > > yet endpoints that enable payload with Binding Updates are able > > to get that performance improvement. > > > > In order to avoid duplicating text, I put the proposal at the > > following URL: > > http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt > > > > Before this proposal, there was a pretty even split within the > > working group -- some were for, some against. The main objection > > seems to center around difficulty with IPsec policy management, > > and our proposal eliminates that problem entirely. Thus, I think > > that we should be able to include this into the base specification, > > and I am hoping that there will be no one objecting -- because > > in effect everyone gets what they want! > > > > With this note, I am attempting to gauge consensus on this issue. > > > > Thanks for your consideration of my request. > > > > Regards, > > Charlie P. > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14:38: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 OAA08008 for ; Fri, 15 Mar 2002 14:38: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 MAA12261; Fri, 15 Mar 2002 12:37: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 LAA04272; Fri, 15 Mar 2002 11:37: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 g2FJaTKL000646 for ; Fri, 15 Mar 2002 11:36:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJaTbf000645 for mobile-ip-dist; Fri, 15 Mar 2002 11:36: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 g2FJaQKL000638 for ; Fri, 15 Mar 2002 11:36:26 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23649 for ; Fri, 15 Mar 2002 11:36:27 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11078 for ; Fri, 15 Mar 2002 11:36:30 -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 g2FJaOR02554 for ; Fri, 15 Mar 2002 20:36:24 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Mar 15 20:36:23 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 20:26:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB2C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Fri, 15 Mar 2002 20:36: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: Vijay, > > Karen Nielsen sent two emails to highlight > > the inability to piggyback some RR messages > > since they are placed in IPsec tunnels > > by the HA. You can generalise the same > > problem for Security Gateways, in those cases > > the MN might not be aware of security policies by > > intermediate routers (SGs). > > And I responded to Karen. It is not an issue with the > current proposal. => Could you give me a pointer to your response? I can't find it. Karen's last email was on this proposal not your original proposal. Hesham > > Vijay > > > Also the note was only relevant to IPsec and > > didn't address the QoS issues (e.g. when using > > Diffserv e2e or when having the Diffserv bits > > set by intermediate routers). These comments > > were explicitly made by David Oran and to some > > extent in my earlier emails. > > So I don't think the IPsec issues alone can justify > > the introduction of piggybacking in the basic > > spec. > > > > Hesham > > > > > -----Original Message----- > > > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, March 15, 2002 8:34 AM > > > To: Mobile IP Working Group > > > Subject: [mobile-ip] Consensus to include recent > > > piggybacking proposal? > > > > > > > > > Hello folks, > > > > > > A few days ago, I posted a proposal worked out by > Jari Malinen, > > > Francis Dupont, and myself that should be a very simple way to > > > eliminate any possible inconsistency between piggybacking and > > > IPsec -- by the simple device of having a "final" > Mobility Header > > > and a "nonfinal" Mobility Header, that are otherwise the same. > > > In this way, all possible conflicts with IPsec are > removed, and > > > yet endpoints that enable payload with Binding > Updates are able > > > to get that performance improvement. > > > > > > In order to avoid duplicating text, I put the proposal at the > > > following URL: > > > http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt > > > > Before this proposal, there was a pretty even split within the > > working group -- some were for, some against. The main objection > > seems to center around difficulty with IPsec policy management, > > and our proposal eliminates that problem entirely. Thus, I think > > that we should be able to include this into the base specification, > > and I am hoping that there will be no one objecting -- because > > in effect everyone gets what they want! > > > > With this note, I am attempting to gauge consensus on this issue. > > > > Thanks for your consideration of my request. > > > > Regards, > > Charlie P. > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14:49: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 OAA08300 for ; Fri, 15 Mar 2002 14:49: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 MAA12729; Fri, 15 Mar 2002 12:48: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 LAA04983; Fri, 15 Mar 2002 11:48: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 g2FJlgKL000731 for ; Fri, 15 Mar 2002 11:47:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJlfAN000730 for mobile-ip-dist; Fri, 15 Mar 2002 11:47: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 g2FJlcKL000723 for ; Fri, 15 Mar 2002 11:47:38 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04587 for ; Fri, 15 Mar 2002 11:47:39 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13977 for ; Fri, 15 Mar 2002 11:47:43 -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 LAA04918; Fri, 15 Mar 2002 11:47:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FJl2k27042; Fri, 15 Mar 2002 11:47:02 -0800 X-mProtect:  Fri, 15 Mar 2002 11:47:02 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdYWpRjv; Fri, 15 Mar 2002 11:47:00 PST Message-ID: <3C924FB4.5AF31048@iprg.nokia.com> Date: Fri, 15 Mar 2002 11:47:00 -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: "Hesham Soliman (EPA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal? References: <4DA6EA82906FD511BE2F00508BCF053802C6AB28@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: > Karen Nielsen sent two emails to highlight > the inability to piggyback some RR messages > since they are placed in IPsec tunnels > by the HA. You can generalise the same > problem for Security Gateways, in those cases > the MN might not be aware of security policies by > intermediate routers (SGs). This is not an issue with the current proposal, as Vijay has pointed out. > Also the note was only relevant to IPsec and > didn't address the QoS issues (e.g. when using > Diffserv e2e or when having the Diffserv bits > set by intermediate routers). These comments > were explicitly made by David Oran and to some > extent in my earlier emails. I responded at length to those e-mails. There is no issue with respect to piggybacking and QoS, _unless_ you are trying to have some sort of "implicit" QoS without asking for it. In any other case, the QoS signalling would trivially be able to handle any setup required for deciding whether or not to use piggybacking. Regards, Charlie P. > > -----Original Message----- > > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Friday, March 15, 2002 8:34 AM > > To: Mobile IP Working Group > > Subject: [mobile-ip] Consensus to include recent > > piggybacking proposal? > > > > > > Hello folks, > > > > A few days ago, I posted a proposal worked out by Jari Malinen, > > Francis Dupont, and myself that should be a very simple way to > > eliminate any possible inconsistency between piggybacking and > > IPsec -- by the simple device of having a "final" Mobility Header > > and a "nonfinal" Mobility Header, that are otherwise the same. > > In this way, all possible conflicts with IPsec are removed, and > > yet endpoints that enable payload with Binding Updates are able > > to get that performance improvement. > > > > In order to avoid duplicating text, I put the proposal at the > > following URL: > > http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt > > > > Before this proposal, there was a pretty even split within the > > working group -- some were for, some against. The main objection > > seems to center around difficulty with IPsec policy management, > > and our proposal eliminates that problem entirely. Thus, I think > > that we should be able to include this into the base specification, > > and I am hoping that there will be no one objecting -- because > > in effect everyone gets what they want! > > > > With this note, I am attempting to gauge consensus on this issue. > > > > Thanks for your consideration of my request. > > > > Regards, > > Charlie P. > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14:56: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 OAA08552 for ; Fri, 15 Mar 2002 14:56:47 -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 MAA20548; Fri, 15 Mar 2002 12:56: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 LAA07303; Fri, 15 Mar 2002 11:56: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 g2FJtSKL000825 for ; Fri, 15 Mar 2002 11:55:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJtS4L000824 for mobile-ip-dist; Fri, 15 Mar 2002 11: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FJtOKL000817 for ; Fri, 15 Mar 2002 11:55:25 -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 LAA07127 for ; Fri, 15 Mar 2002 11:55: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 MAA26622 for ; Fri, 15 Mar 2002 12:55: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 LAA05839 for ; Fri, 15 Mar 2002 11:55:23 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FJtNx19114 for ; Fri, 15 Mar 2002 11:55:23 -0800 X-mProtect:  Fri, 15 Mar 2002 11:55:23 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbnnbfR; Fri, 15 Mar 2002 11:55:20 PST Message-ID: <3C9251A9.6EE75D4A@iprg.nokia.com> Date: Fri, 15 Mar 2002 11:55:21 -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] Consensus to include recent piggybacking proposal? References: <4DA6EA82906FD511BE2F00508BCF053802C6AB2C@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 hi Hesham, "Hesham Soliman (ERA)" wrote: > > Vijay, > > > > Karen Nielsen sent two emails to highlight > > > the inability to piggyback some RR messages > > > since they are placed in IPsec tunnels > > > by the HA. You can generalise the same > > > problem for Security Gateways, in those cases > > > the MN might not be aware of security policies by > > > intermediate routers (SGs). > > > > And I responded to Karen. It is not an issue with the > > current proposal. > > => Could you give me a pointer to your response? > I can't find it. Karen's last email was on this > proposal not your original proposal. Karen had a issue with the original proposal, which is taken care of in the second proposal. Regarding her second mail, it wasnt raising an issue with the basic proposal. It was more like an opinion on whether piggybacking is possible for RR 1a and RR 2a messages. Its fine with me either way. In fact the Yes with a (*) came from the original DT writeup. And the proposal says so too. Vijay > > Hesham > > > > > Vijay > > > > > Also the note was only relevant to IPsec and > > > didn't address the QoS issues (e.g. when using > > > Diffserv e2e or when having the Diffserv bits > > > set by intermediate routers). These comments > > > were explicitly made by David Oran and to some > > > extent in my earlier emails. > > > So I don't think the IPsec issues alone can justify > > > the introduction of piggybacking in the basic > > > spec. > > > > > > Hesham > > > > > > > -----Original Message----- > > > > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > > > > Sent: Friday, March 15, 2002 8:34 AM > > > > To: Mobile IP Working Group > > > > Subject: [mobile-ip] Consensus to include recent > > > > piggybacking proposal? > > > > > > > > > > > > Hello folks, > > > > > > > > A few days ago, I posted a proposal worked out by > > Jari Malinen, > > > > Francis Dupont, and myself that should be a very simple way to > > > > eliminate any possible inconsistency between piggybacking and > > > > IPsec -- by the simple device of having a "final" > > Mobility Header > > > > and a "nonfinal" Mobility Header, that are otherwise the same. > > > > In this way, all possible conflicts with IPsec are > > removed, and > > > > yet endpoints that enable payload with Binding > > Updates are able > > > > to get that performance improvement. > > > > > > > > In order to avoid duplicating text, I put the proposal at the > > > > following URL: > > > > > http://people.nokia.net/charliep/txt/mobilev6/piggybacking.txt > > > > > > Before this proposal, there was a pretty even split within the > > > working group -- some were for, some against. The main objection > > > seems to center around difficulty with IPsec policy management, > > > and our proposal eliminates that problem entirely. Thus, I think > > > that we should be able to include this into the base specification, > > > and I am hoping that there will be no one objecting -- because > > > in effect everyone gets what they want! > > > > > > With this note, I am attempting to gauge consensus on this issue. > > > > > > Thanks for your consideration of my request. > > > > > > Regards, > > > Charlie P. > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 14:59: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 OAA08603 for ; Fri, 15 Mar 2002 14:59: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 MAA15666; Fri, 15 Mar 2002 12:59: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 LAA08646; Fri, 15 Mar 2002 11:59: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 g2FJvvKL000881 for ; Fri, 15 Mar 2002 11:57:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJvvGv000880 for mobile-ip-dist; Fri, 15 Mar 2002 11:57: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 g2FJvsKL000873 for ; Fri, 15 Mar 2002 11:57: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 LAA04203 for ; Fri, 15 Mar 2002 11:57:54 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27711 for ; Fri, 15 Mar 2002 12:57:53 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id VAA15614; Fri, 15 Mar 2002 21:57:50 +0200 Date: Fri, 15 Mar 2002 21:57:50 +0200 Message-Id: <200203151957.VAA15614@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: <3C923C01.BA2825A1@iprg.nokia.com> (message from Vijay Devarapalli on Fri, 15 Mar 2002 10:22:57 -0800) Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design teamrecommendation: New recommendation on piggybacking) References: <3C923C01.BA2825A1@iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: > From: Vijay Devarapalli > The current proposal is to use both a final and non-final Mobility > Header (MH). In Case 1, the non-final MH is used (because it is > being piggybacked). And when the intermediate router (SG) receives > this packet, it treats the MH as a normal extension header, scans > past it, finds the payload and applies the appropriate IPSec > policy. This should work. Do I understand this correct? The solution calls "burning" two protocol numbers: one for new intermediate header and one for the final? At least, could save one by sticking to the original destination options when intermediate. If you are truly contemplating about creating a totally new extension header number, you need to remember that currently deployed IPv6 stacks only know about following extension headers - Hop-by-hop header - routing header - destination options - ah, esp If they scan the packet and run into *anything* else, they don't recognize it as extension header. They either drop the packet or assume it is upper layer protocol. They definitely not cannot skip unknown headers. IPsec policy for IPsec policy Mobility Message for Payload Can piggyback 1. no no yes 2. no yes yes 3. yes no no 4. yes yes no Basicly, this table reduces Want IPsec for Mobility Message? 1. no use intermediate header (dest options) 2. yes use mobility header (no piggyback) And just check on receive whether IPSEC was applied or not (reject packet, report error or something). From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:00:35 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 PAA08648 for ; Fri, 15 Mar 2002 15:00:35 -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 MAA22256; Fri, 15 Mar 2002 12:59: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 LAA08969; Fri, 15 Mar 2002 11:59: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 g2FJwhKL000929 for ; Fri, 15 Mar 2002 11:58:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJwhTg000928 for mobile-ip-dist; Fri, 15 Mar 2002 11:58: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 g2FJwZKL000908 for ; Fri, 15 Mar 2002 11:58:35 -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 LAA21398 for ; Fri, 15 Mar 2002 11:58:36 -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 MAA15402 for ; Fri, 15 Mar 2002 12:58: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 LAA06105 for ; Fri, 15 Mar 2002 11:58:35 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FJwOf25139 for ; Fri, 15 Mar 2002 11:58:24 -0800 X-mProtect:  Fri, 15 Mar 2002 11:58:24 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMCX5jK; Fri, 15 Mar 2002 11:58:22 PST Message-ID: <3C92525F.4A2DE604@iprg.nokia.com> Date: Fri, 15 Mar 2002 11:58:23 -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: [mobile-ip] Consensus to include recent piggybacking proposal? References: <4DA6EA82906FD511BE2F00508BCF053802C6AB28@Esealnt861.al.sw.ericsson.se> <3C924FB4.5AF31048@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 Hello folks, I forgot to say one other thing: "Charles E. Perkins" wrote: > > Also the note was only relevant to IPsec and > > didn't address the QoS issues (e.g. when using > > Diffserv e2e or when having the Diffserv bits > > set by intermediate routers). These comments > > were explicitly made by David Oran and to some > > extent in my earlier emails. > > I responded at length to those e-mails. There is no > issue with respect to piggybacking and QoS, > _unless_ you are trying to have some sort of > "implicit" QoS without asking for it. In any > other case, the QoS signalling would trivially > be able to handle any setup required for > deciding whether or not to use piggybacking. The other point here, is that there is some pretty heavy channel restriction being proposed to propagate up the stack, which can easily be construed as incompatible with IPv6. IPv6 requires minimum MTU far larger than would interfere with inclusion of a Binding Update, so all IPv6 nodes MUST be able to handle such things. Doubly so, since IPv6 nodes have to be able to parse extension headers in just this way. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15: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 PAA08659 for ; Fri, 15 Mar 2002 15:00: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 MAA16076; Fri, 15 Mar 2002 12:59: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 LAA08954; Fri, 15 Mar 2002 11:59: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 g2FJweKL000919 for ; Fri, 15 Mar 2002 11:58:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJweN5000918 for mobile-ip-dist; Fri, 15 Mar 2002 11:58: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 g2FJwXKL000901 for ; Fri, 15 Mar 2002 11:58: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 LAA12328 for ; Fri, 15 Mar 2002 11:58:34 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21622 for ; Fri, 15 Mar 2002 12:58:33 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2FJvr314837 for ; Fri, 15 Mar 2002 21:57:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 15 Mar 2002 21:58:32 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 21:58:32 +0200 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 13:58:21 -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] Final Agenda for WG meeting at IETF53 Date: Fri, 15 Mar 2002 13:58:21 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12A2F@daebe007.NOE.Nokia.com> Thread-Topic: Final Agenda for WG meeting at IETF53 Thread-Index: AcHMW8Ez0+yDKjhFEdaxrgAAhj/HZA== To: X-OriginalArrivalTime: 15 Mar 2002 19:58:21.0463 (UTC) FILETIME=[C228D270:01C1CC5B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FJwYKL000902 Sender: owner-mobile-ip@sunroof.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 Final Agenda. IP Routing for Wireless/Mobile Hosts WG (mobileip) Agenda for IETF53 TUESDAY, March 19, 2002 0900-1130 Morning Sessions ------------------------------------------------------------ 1. Agenda Bashing 10 Minutes Basavaraj Document status 1a. Registration Revocation 5 Minutes Steve Glass draft-ietf-mobileip-reg-revok-02.txt 2. Connectathon Update 5 Minutes Samita 3. Mobile IPv6 Security Discussion 60 Minutes Design Team - Overview of design decisions 10 mins - Overview of new protocol version (MH format etc.) 10 mins - Future work items 10 Mins - Open issues 30 mins 4. MIPv4/AAA Keys Open issues 10 Minutes Phil 5. LMM Requirements 10 Minutes Carl draft-ietf-mobileip-lmm-requirements-01.txt 6. NAT/NAPT Traversal 10 Minutes Henrik draft-ietf-mobileip-nat-traversal-01.txt 7. MIP/VPN Issues 10 Minutes Phil draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:01:11 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 PAA08699 for ; Fri, 15 Mar 2002 15:01:11 -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 MAA05705; Fri, 15 Mar 2002 12:00:44 -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 MAA09239; Fri, 15 Mar 2002 12:00: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 g2FJxGKL000959 for ; Fri, 15 Mar 2002 11:59:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FJxGjE000958 for mobile-ip-dist; Fri, 15 Mar 2002 11:59: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 g2FJx4KL000941 for ; Fri, 15 Mar 2002 11:59:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12491; Fri, 15 Mar 2002 11:59:05 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17195; Fri, 15 Mar 2002 11:59:09 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FJx5I09663; Fri, 15 Mar 2002 11:59:05 -0800 (PST) Message-ID: <01a501c1cc5b$a30e05e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: References: Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 11:57: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 Erik, > The MIPv6 specification has a mechanism (the 'R' bit in prefix options for > router advertisements) that allow for home agent discovery to work as well as > this HA for a previous CoA to work. That has the effect of providing global as > well as site-local addresses of the router to the nodes on the link. > > I don't think security of the routers should depend on their global addresses > being 'secret'. Traceroute would presumably return them in any case. > OK. But I assume traceroute would show a site local or link local address if the router only had that, right? So an attacker wouldn't be able to hack into it even if they knew it was there, unless they could break through the site local address routing. And I agree that keeping the router's address "secret" is not sufficient for security, but it is like making the TTL 255 on ND traffic, a quick and easy way to eliminate one class of problems, don't you think? > The benefits of creating a binding for a previous CoA is a function of > the time it takes to do this update - the goal is to prevent packets that > are in transit from CNs (and perhaps MN) from being dropped on the previous > link. Perhaps this is better done using other local mechanisms to minimize > packet drops during handoff? > Actually, I think so. This is precisely what the fast handoff proposals do. The problem with forwarding from previous care of address is that it is reactive and requires the MN to have a care of address. By the time the MN has obtained a care of address, many packets may have been dropped (note that other reactive proposals not requiring the MN to obtain a care of address may not have this problem). The proactive approaches in the FMIPv6 draft do better, because they allow the tunnel to be set up as soon as the MN moves from the old AR. Not sure whether this is a reason to drop forwarding from previous care of address, it may have other advantages, if the security implications can be fully worked out. > The security requirements for the HA result in the assumption that the MN > has a pre-configured arrangement with its HA in order to associate > the authorization to do bindings for the HoA with an IPsec SA. > If this is applied to the HA for the previous CoA it would seem to > require some form of pre-establishment there as well. > But that wouldn't introduce any new security concerns and not require > additional specification work. > But shouldn't this at least be stated in the MIPv6 spec somewhere? > Doing RR after the MN has moved away doesn't work. The RR check for the > HoA i.e. previous CoA in this case would assume that the MN is reachable > at the previous CoA, which it isn't. > So unless this RR check is performed (and "refreshed") before the MN moves > and the RR check for the new CoA is done after the move, can RR be made > to work in this case. > Seems complex. > Agree. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:04: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 PAA08766 for ; Fri, 15 Mar 2002 15:04:07 -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 NAA18081; Fri, 15 Mar 2002 13:03: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 MAA10768; Fri, 15 Mar 2002 12:03: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 g2FK2WKL001232 for ; Fri, 15 Mar 2002 12:02:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FK2Wip001231 for mobile-ip-dist; Fri, 15 Mar 2002 12: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FK2SKL001221 for ; Fri, 15 Mar 2002 12:02:28 -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 MAA14457 for ; Fri, 15 Mar 2002 12:02:29 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA29821 for ; Fri, 15 Mar 2002 13:02:25 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FK2MI09972; Fri, 15 Mar 2002 12:02:22 -0800 (PST) Message-ID: <01ad01c1cc5c$1861e190$7e6015ac@T23KEMPF> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF44A12A27@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 12:00:46 -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, > The DT recommends that "on-link" or temporary home agent (previous > AR) should process BUs from MNs only if it has an SA with it. The same > security requirements that are applicable for the normal MN-HA BUs are > aplicable to the temporary HA. > OK, I presume this will be stated in the security section of the MIPv6 draft, that all HAs have the same requirements with respect to security? > The base MIPv6 specification hence will not permit MNs to send BUs to > previous ARs (temporary HA). However with FMIPv6 or other future > extensions we could specify how an MN can establish an SA with its AR > which can be for the specific purpose of having the AR act as a temp > HA. > Probably a little premature for this, but it might be necessary to add some text to the FMIPv6 spec to cover this case.Alternatively, perhaps there is a way to achieve what FMIPv6 needs without requiring the MN to communicate beyond the routers on its current link. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:13: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 PAA09113 for ; Fri, 15 Mar 2002 15:13:19 -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 NAA28625; Fri, 15 Mar 2002 13:12:41 -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 MAA13373; Fri, 15 Mar 2002 12:12: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 g2FKBZKL001449 for ; Fri, 15 Mar 2002 12:11:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FKBYJw001448 for mobile-ip-dist; Fri, 15 Mar 2002 12:11: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FKBVKL001441 for ; Fri, 15 Mar 2002 12:11: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 MAA13032 for ; Fri, 15 Mar 2002 12:11:27 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03811 for ; Fri, 15 Mar 2002 13:11:26 -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 g2FKBPUw010958 for ; Fri, 15 Mar 2002 21:11:25 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 15 21:11:24 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 21:11:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB33@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Fri, 15 Mar 2002 21:11:19 +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, > > Karen Nielsen sent two emails to highlight > > the inability to piggyback some RR messages > > since they are placed in IPsec tunnels > > by the HA. You can generalise the same > > problem for Security Gateways, in those cases > > the MN might not be aware of security policies by > > intermediate routers (SGs). > > This is not an issue with the current proposal, > as Vijay has pointed out. => As Vijay pointed out in his most recent email, there could be issues with piggybacking 1a and 2a. Karen can speak for herself, but reading the last email, it said something like 'strongly stress ....that piggybaking 1a and 2a is not possible'. Also the other point was SGWs which the MN is not aware of. > > > Also the note was only relevant to IPsec and > > didn't address the QoS issues (e.g. when using > > Diffserv e2e or when having the Diffserv bits > > set by intermediate routers). These comments > > were explicitly made by David Oran and to some > > extent in my earlier emails. > > I responded at length to those e-mails. There is no > issue with respect to piggybacking and QoS, > _unless_ you are trying to have some sort of > "implicit" QoS without asking for it. In any > other case, the QoS signalling would trivially > be able to handle any setup required for > deciding whether or not to use piggybacking. => First of all, no one is using e2e QoS signalling today, please correct me if I'm wrong. Second, I might have missed on of your emails but I'd appreciate a pointer on how Diffserv can be used here if there is a conflict between the BU DSCPs and the payload's. Obviously Diffserv is not always used e2e and can be set by intermediate routers. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:14: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 PAA09158 for ; Fri, 15 Mar 2002 15:14: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 MAA08873; Fri, 15 Mar 2002 12:13:43 -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 MAA13861; Fri, 15 Mar 2002 12:13: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 g2FKClKL001486 for ; Fri, 15 Mar 2002 12:12:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FKCl5W001485 for mobile-ip-dist; Fri, 15 Mar 2002 12:12: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 g2FKChKL001478 for ; Fri, 15 Mar 2002 12:12:43 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10819 for ; Fri, 15 Mar 2002 12:12:44 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20657 for ; Fri, 15 Mar 2002 12:12:48 -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 g2FKCgUw011143 for ; Fri, 15 Mar 2002 21:12:42 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Mar 15 21:12:41 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 21:13:00 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB34@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Fri, 15 Mar 2002 21:12:38 +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 other point here, is that there is some pretty > heavy channel restriction being proposed to propagate > up the stack, which can easily be construed as > incompatible with IPv6. IPv6 requires minimum MTU > far larger than would interfere with inclusion of a > Binding Update, so all IPv6 nodes MUST be able to > handle such things. Doubly so, since IPv6 nodes have > to be able to parse extension headers in just this way. > => MTU is not relevant here as I tried to highlight several times. BTW, didn't we get an email from the chairs that this issue was closed? Hesham > Regards, > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:28: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 PAA09434 for ; Fri, 15 Mar 2002 15:28:44 -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 MAA11540; Fri, 15 Mar 2002 12:28:16 -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 MAA16099; Fri, 15 Mar 2002 12:28: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 g2FKRCKL001686 for ; Fri, 15 Mar 2002 12:27:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FKRCv3001685 for mobile-ip-dist; Fri, 15 Mar 2002 12:27: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FKR9KL001678 for ; Fri, 15 Mar 2002 12:27:09 -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 MAA23924 for ; Fri, 15 Mar 2002 12:27:10 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29384 for ; Fri, 15 Mar 2002 13:27:09 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id WAA15692; Fri, 15 Mar 2002 22:27:07 +0200 Date: Fri, 15 Mar 2002 22:27:07 +0200 Message-Id: <200203152027.WAA15692@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: <200203151957.VAA15614@burp.tkv.asdf.org> (message from Markku Savela on Fri, 15 Mar 2002 21:57:50 +0200) Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design teamrecommendation: New recommendation on piggybacking) References: <3C923C01.BA2825A1@iprg.nokia.com> <200203151957.VAA15614@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) 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 prompts me query, why need a new protocol number even. Would this look too kludgy? - non final mobility: use the destination options (as originally specified) - when IPSEC is desired, send the destination options in separate UDP packet, and pick a well known port for it (assign it to mobility). From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 15:42: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 PAA09782 for ; Fri, 15 Mar 2002 15:42: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 NAA08040; Fri, 15 Mar 2002 13:41: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 MAA19921; Fri, 15 Mar 2002 12: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 g2FKdNKL001772 for ; Fri, 15 Mar 2002 12:39:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FKdNuk001771 for mobile-ip-dist; Fri, 15 Mar 2002 12:39: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 g2FKdJKL001764 for ; Fri, 15 Mar 2002 12:39:20 -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 MAA01146 for ; Fri, 15 Mar 2002 12:39:20 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06888 for ; Fri, 15 Mar 2002 13:39:16 -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 g2FKfSx13944 for ; Fri, 15 Mar 2002 14:41:28 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 14:39:11 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 14:39:03 -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] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 14:39:02 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12A32@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Security on Local "Home Agent" Functionality? Thread-Index: AcHMXFUB/JqMTNQXTtOIU+JGVg6N9AABRNJw To: , X-OriginalArrivalTime: 15 Mar 2002 20:39:03.0002 (UTC) FILETIME=[716E1BA0:01C1CC61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FKdKKL001765 Sender: owner-mobile-ip@sunroof.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 James, >Hi Raj, > >> The DT recommends that "on-link" or temporary home agent (previous >> AR) should process BUs from MNs only if it has an SA with it. The same >> security requirements that are applicable for the normal MN-HA BUs are >> aplicable to the temporary HA. >> > >OK, I presume this will be stated in the security section of the MIPv6 >draft, that all HAs have the same requirements with respect to >security? The new version of the Mobile IPv6 specification which will probably be available early next week will include such a statement. >> The base MIPv6 specification hence will not permit MNs to send BUs to >> previous ARs (temporary HA). However with FMIPv6 or other future >> extensions we could specify how an MN can establish an SA with its AR >> which can be for the specific purpose of having the AR act as a temp >> HA. >> > >Probably a little premature for this, but it might be necessary to add >some text to the FMIPv6 spec to cover this case.Alternatively, perhaps >there is a way to achieve what FMIPv6 needs without requiring the MN >to communicate beyond the routers on its current link. I was just suggesting some possible approaches for solving this problem. The WG will look at alternative solutions as well. > > jak > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 16:09:52 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 QAA10458 for ; Fri, 15 Mar 2002 16:09: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 OAA21621; Fri, 15 Mar 2002 14:09: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 NAA28815; Fri, 15 Mar 2002 13:09: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 g2FL7uKL001975 for ; Fri, 15 Mar 2002 13:07:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FL7uV1001974 for mobile-ip-dist; Fri, 15 Mar 2002 13:07: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 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 g2FL7sKL001967 for ; Fri, 15 Mar 2002 13:07:54 -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 QAA15481 for ; Fri, 15 Mar 2002 16:07:55 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id QAA14984 for mobile-ip@sunroof.eng.sun.com; Fri, 15 Mar 2002 16:08:47 -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 g2F1oMKL028149 for ; Thu, 14 Mar 2002 17:50: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 RAA17913 for ; Thu, 14 Mar 2002 17:50:23 -0800 (PST) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24494 for ; Thu, 14 Mar 2002 17:50:22 -0800 (PST) Received: from bahamas.64translator.com (itgw [10.21.254.82]) by mail.64translator.com (8.11.6/8.11.6) with ESMTP id g2F1oLX24710 for ; Fri, 15 Mar 2002 10:50:21 +0900 (JST) Received: from odin.akisada.jp (dhcp161.64translator.com [10.21.32.161]) by bahamas.64translator.com (8.11.4/8.11.4) with SMTP id g2F1oKH18228 for ; Fri, 15 Mar 2002 10:50:20 +0900 (JST) Date: Fri, 15 Mar 2002 10:50:19 +0900 From: Yukiyo Akisada To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] about proxy DAD Message-Id: <20020315105019.3f846b7e.Yukiyo.Akisada@jp.yokogawa.com> In-Reply-To: <3C9114DD.AD29B895@iprg.nokia.com> References: <20020308042835.359fdc71.yukiyo_akisada@yokogawa.co.jp> <3C9114DD.AD29B895@iprg.nokia.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 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. On Thu, 14 Mar 2002 13:23:41 -0800 Vijay Devarapalli wrote: > But as RFC 2462 says, DAD can be skipped for the home > address if stateless configuration is used and the > interface id is going to be the same for the home address > and the link local address. And when you chose to skip, > it can be skipped for both cases ('S' bit set to 0/1). I can find this sentence in RFC2462. Now, I'm clear. Thanks. From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 16:16: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 QAA10642 for ; Fri, 15 Mar 2002 16:16: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 OAA24160; Fri, 15 Mar 2002 14:15: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 NAA00770; Fri, 15 Mar 2002 13:15: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 g2FLEOKL002159 for ; Fri, 15 Mar 2002 13:14:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FLEOeT002157 for mobile-ip-dist; Fri, 15 Mar 2002 13:14: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 g2FLELKL002150 for ; Fri, 15 Mar 2002 13:14:21 -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 NAA27092 for ; Fri, 15 Mar 2002 13:14:22 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21238 for ; Fri, 15 Mar 2002 14:14:21 -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 g2FLF4i08683 for ; Fri, 15 Mar 2002 23:15:04 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 23:14:20 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 23:14:20 +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] AAA keys security review Date: Fri, 15 Mar 2002 23:14:20 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C5A@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] AAA keys security review Thread-Index: AcHKtZ3UFCrzszzOSuqFjEj/pkKQ3ABsI3Vw To: , , X-OriginalArrivalTime: 15 Mar 2002 21:14:20.0415 (UTC) FILETIME=[5F81B0F0:01C1CC66] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FLELKL002151 Sender: owner-mobile-ip@sunroof.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 All, > I asked Luis Sanchez (chair of ipsp WG) to review this doc for us and he > did. We're very grateful. Here's the note he sent with his review > embedded. Please note, this was done on > version -08 before Charlie produced version -09. One issue from the Diameter last call is: Issue 215: Use of hmac-md5 is incorrect Submitter name: Pat Calhoun Submitter email address: pcalhoun@bstormnetworks.com Date first submitted: 25-Oct-01 Reference: Document: base, aaa-keys Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Need to make use that the use of md5 and hmac-md5 is consistent across both drafts. The latest aaa-keys uses hmac-md5, but uses the incorrect function prototype (it uses hmac-md5 with a prefix+suffix mode). I don't know if this has been fixed or not in the AAA-keys doc. John From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 16:57: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 QAA11499 for ; Fri, 15 Mar 2002 16:57:16 -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 OAA08202; Fri, 15 Mar 2002 14:56:08 -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 NAA20085; Fri, 15 Mar 2002 13:55: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 g2FLsnKL002396 for ; Fri, 15 Mar 2002 13:54:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FLsnsw002392 for mobile-ip-dist; Fri, 15 Mar 2002 13:54: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 g2FLsjKL002384 for ; Fri, 15 Mar 2002 13:54:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19722 for ; Fri, 15 Mar 2002 13:54:46 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27022 for ; Fri, 15 Mar 2002 13:54: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 NAA13067; Fri, 15 Mar 2002 13:54:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FLsE509737; Fri, 15 Mar 2002 13:54:14 -0800 X-mProtect:  Fri, 15 Mar 2002 13:54:14 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiQUnmI; Fri, 15 Mar 2002 13:54:12 PST Message-ID: <3C926D97.DE98D4F9@iprg.nokia.com> Date: Fri, 15 Mar 2002 13:54:31 -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: "John Loughney (NRC/Helsinki)" CC: mobile-ip@sunroof.eng.sun.com, PRoberts@MEGISTO.com, pcalhoun@bstormnetworks.com Subject: Re: [mobile-ip] AAA keys security review References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C5A@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 Hello John, This is fixed in revision -09. Regards, Charlie P. john.loughney@nokia.com wrote: > Hi All, > > > I asked Luis Sanchez (chair of ipsp WG) to review this doc for us and he > > did. We're very grateful. Here's the note he sent with his review > > embedded. Please note, this was done on > > version -08 before Charlie produced version -09. > > One issue from the Diameter last call is: > > Issue 215: Use of hmac-md5 is incorrect > Submitter name: Pat Calhoun > Submitter email address: pcalhoun@bstormnetworks.com > Date first submitted: 25-Oct-01 > Reference: > Document: base, aaa-keys > Comment type: Technical > Priority: 1 > Section: > Rationale/Explanation of issue: > > Need to make use that the use of md5 and hmac-md5 is consistent across > both drafts. The latest aaa-keys uses hmac-md5, but uses the incorrect > function prototype (it uses hmac-md5 with a prefix+suffix mode). > > I don't know if this has been fixed or not in the AAA-keys > doc. > > John From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 16:58: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 QAA11532 for ; Fri, 15 Mar 2002 16:58: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 OAA06908; Fri, 15 Mar 2002 14:57:59 -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 NAA20677; Fri, 15 Mar 2002 13:57: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 g2FLv7KL002475 for ; Fri, 15 Mar 2002 13:57:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FLv7rC002474 for mobile-ip-dist; Fri, 15 Mar 2002 13:57: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 g2FLv3KL002467 for ; Fri, 15 Mar 2002 13:57:03 -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 NAA20496 for ; Fri, 15 Mar 2002 13:57:05 -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 OAA06503 for ; Fri, 15 Mar 2002 14:57: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 NAA13221 for ; Fri, 15 Mar 2002 13:57:04 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2FLup713849 for ; Fri, 15 Mar 2002 13:56:51 -0800 X-mProtect:  Fri, 15 Mar 2002 13:56:51 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIqWASR; Fri, 15 Mar 2002 13:56:49 PST Message-ID: <3C926E22.96FD798@iprg.nokia.com> Date: Fri, 15 Mar 2002 13:56: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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal? References: <4DA6EA82906FD511BE2F00508BCF053802C6AB33@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: > > Charlie, > > > > Karen Nielsen sent two emails to highlight > > > the inability to piggyback some RR messages > > > since they are placed in IPsec tunnels > > > by the HA. You can generalise the same > > > problem for Security Gateways, in those cases > > > the MN might not be aware of security policies by > > > intermediate routers (SGs). > > > > This is not an issue with the current proposal, > > as Vijay has pointed out. > > => As Vijay pointed out in his most recent email, > there could be issues with piggybacking 1a and > 2a. Karen can speak for herself, but reading the > last email, it said something like 'strongly > stress ....that piggybaking 1a and 2a is not possible'. Hesham, I said either way is fine. That is *NOT* the issue here.... Vijay > > Also the other point was SGWs which the MN is > not aware of. > > > > > > Also the note was only relevant to IPsec and > > > didn't address the QoS issues (e.g. when using > > > Diffserv e2e or when having the Diffserv bits > > > set by intermediate routers). These comments > > > were explicitly made by David Oran and to some > > > extent in my earlier emails. > > > > I responded at length to those e-mails. There is no > > issue with respect to piggybacking and QoS, > > _unless_ you are trying to have some sort of > > "implicit" QoS without asking for it. In any > > other case, the QoS signalling would trivially > > be able to handle any setup required for > > deciding whether or not to use piggybacking. > > => First of all, no one is using e2e QoS signalling > today, please correct me if I'm wrong. > Second, I might have missed on of your emails > but I'd appreciate a pointer on how > Diffserv can be used here if there is a conflict > between the BU DSCPs and the payload's. > Obviously Diffserv is not always used e2e and > can be set by intermediate routers. > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 17:22: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 RAA12205 for ; Fri, 15 Mar 2002 17:22: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 PAA18773; Fri, 15 Mar 2002 15:21: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 OAA22841; Fri, 15 Mar 2002 14:21: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 g2FMKtKL002681 for ; Fri, 15 Mar 2002 14:20:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FMKtbu002680 for mobile-ip-dist; Fri, 15 Mar 2002 14: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FMKqKL002673 for ; Fri, 15 Mar 2002 14:20:52 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13007 for ; Fri, 15 Mar 2002 14:20:52 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03676 for ; Fri, 15 Mar 2002 14:20:52 -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 g2FMLXi20175 for ; Sat, 16 Mar 2002 00:21:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 16 Mar 2002 00:20:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Sat, 16 Mar 2002 00:20:49 +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] AAA keys security review Date: Sat, 16 Mar 2002 00:20:49 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C5B@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] AAA keys security review Thread-Index: AcHMa/1PchiDUUclTmeNVu1D0ynX9wAA5+5Q To: Cc: X-OriginalArrivalTime: 15 Mar 2002 22:20:49.0949 (UTC) FILETIME=[A97444D0:01C1CC6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FMKqKL002674 Sender: owner-mobile-ip@sunroof.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 Charlie, > This is fixed in revision -09. Great - just wanted to make sure nothing got dropped. John From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 17:30: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 RAA12445 for ; Fri, 15 Mar 2002 17:30: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 PAA19745; Fri, 15 Mar 2002 15:29: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 OAA25208; Fri, 15 Mar 2002 14:29: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 g2FMSeKL002791 for ; Fri, 15 Mar 2002 14:28:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FMSe1r002790 for mobile-ip-dist; Fri, 15 Mar 2002 14:28: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 g2FMSaKL002783 for ; Fri, 15 Mar 2002 14:28:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24979 for ; Fri, 15 Mar 2002 14:28:37 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05598 for ; Fri, 15 Mar 2002 14:28:37 -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 g2FMSZR22502 for ; Fri, 15 Mar 2002 23:28:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 15 23:28:33 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Mar 2002 23:18:37 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB39@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Subject: RE: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 23:28:31 +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, > global as > > well as site-local addresses of the router to the nodes > on the link. > > > > I don't think security of the routers should depend on > their global > addresses > > being 'secret'. Traceroute would presumably return them > in any case. > > > > OK. But I assume traceroute would show a site local or link local > address if the router only had that, right? So an attacker > wouldn't be > able to hack into it even if they knew it was there, unless > they could > break through the site local address routing. And I agree > that keeping > the router's address "secret" is not sufficient for > security, but it is > like making the TTL 255 on ND traffic, a quick and easy way > to eliminate > one class of problems, don't you think? => Even if you only have site-local, you can be attacked from within the site. Some routers will need global addresses anyway if the network management nodes are not in the same site. > > > The benefits of creating a binding for a previous CoA is > a function of > > the time it takes to do this update - the goal is to > prevent packets > that > > are in transit from CNs (and perhaps MN) from being dropped on the > previous > > link. Perhaps this is better done using other local mechanisms to > minimize > > packet drops during handoff? > > > > Actually, I think so. This is precisely what the fast > handoff proposals > do. The problem with forwarding from previous care of > address is that it > is reactive and requires the MN to have a care of address. > By the time > the MN has obtained a care of address, many packets may have been > dropped => Not if you get the CoA before you move. (note that other reactive proposals not requiring the MN to > obtain a care of address may not have this problem). The proactive > approaches in the FMIPv6 draft do better, because they > allow the tunnel > to be set up as soon as the MN moves from the old AR. => But all methods in FMIPv6 will do that. Some with explicit L3 signalling and some without. The question that comes to mind is: If there are security problems with explicit L3 signalling, does removing this signalling and replacing it by inter-router signalling remove the problems ? ;) I mean, if the required security level for a node to forward traffic to an address is to prove that it has the authority for doing so (hence RR), can we just assume that any router sending this message to another router, will have such authority ? I'm just not so sure that the FMIPv6 problems will go away if we remove the BU signalling to the default router. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 18:03: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 SAA13137 for ; Fri, 15 Mar 2002 18:03:40 -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 QAA05927; Fri, 15 Mar 2002 16:03: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 PAA10736; Fri, 15 Mar 2002 15:02: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 g2FN1tKL003005 for ; Fri, 15 Mar 2002 15:01:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FN1tQg003004 for mobile-ip-dist; Fri, 15 Mar 2002 15:01: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 g2FN1qKL002997 for ; Fri, 15 Mar 2002 15:01:52 -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 PAA10386; Fri, 15 Mar 2002 15:01:52 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12505; Fri, 15 Mar 2002 16:01:51 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FN1oI15940; Fri, 15 Mar 2002 15:01:50 -0800 (PST) Message-ID: <085501c1cc75$2ac618b0$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Erik Nordmark" References: <4DA6EA82906FD511BE2F00508BCF053802C6AB39@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 15:00:14 -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 Hesham, > => Even if you only have site-local, you > can be attacked from within the site. > Some routers will need global addresses anyway > if the network management nodes are not > in the same site. > OK, but by not exposing the address to end hosts, you decrease the chances. Also, if the router needs to be managed from outside the site, it could be done through a firewall-style proxy. I'm not saying that site-local addresses are the final answer to router security, just that they strike me as a good idea, as does not exposing the addresses to end hosts. > > Actually, I think so. This is precisely what the fast > > handoff proposals > > do. The problem with forwarding from previous care of > > address is that it > > is reactive and requires the MN to have a care of address. > > By the time > > the MN has obtained a care of address, many packets may have been > > dropped > > => Not if you get the CoA before you move. > I was speaking in this email about FFPCA as described in the FMIPv6 draft, not as augmented by FMIPv6. > => But all methods in FMIPv6 will do that. Some > with explicit L3 signalling and some without. > The question that comes to mind is: > If there are security problems with explicit > L3 signalling, does removing this signalling and > replacing it by inter-router signalling > remove the problems ? ;) > I mean, if the required security level for a node > to forward traffic to an address is to prove > that it has the authority for doing so (hence RR), > can we just assume that any router sending > this message to another router, will have > such authority ? > I'm just not so sure that the FMIPv6 problems > will go away if we remove the BU signalling > to the default router. > Well, with regard to FMIPv6, my thinking here is that any time you can convert two problems into one generic problem and just solve the generic problem, you win. :-) Thus, if we could figure out some way to make the FMIPv6 signaling: router<->router host<->local link router, then we could remove the problem of how to secure off-link router<->host and be left only with the problem of how to secure host<->local link router. This is a generic IPv6 ND problem, as we have been discussing in the IPNG list, and so a solution for ND would work for FMIPv6 also. Just like MIPv6 uses standard ND signaling for CoA aquistion, instead of special signaling as in MIPv4. The router<->router security is presumably taken care of by the backbone routing. Maybe the host<->local link router security solution would also work for the host<->off-link router solution too, of course, but it strikes me as a worthwhile effort to try to simplify the security problems associated with fast handover in MIPv6 if we possibly can. Make sense? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 18:16: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 SAA13496 for ; Fri, 15 Mar 2002 18:16: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 QAA10696; Fri, 15 Mar 2002 16:16: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 PAA14832; Fri, 15 Mar 2002 15:16: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 g2FNEnKL003096 for ; Fri, 15 Mar 2002 15:14:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FNEn5f003095 for mobile-ip-dist; Fri, 15 Mar 2002 15:14: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 g2FNEkKL003088 for ; Fri, 15 Mar 2002 15:14:46 -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 PAA25315 for ; Fri, 15 Mar 2002 15:14:47 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10092 for ; Fri, 15 Mar 2002 16:14:46 -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 g2FNEiUw029631 for ; Sat, 16 Mar 2002 00:14:45 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Mar 16 00:14:44 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Mar 2002 00:04:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB40@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Subject: RE: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Sat, 16 Mar 2002 00:14:42 +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: > > => But all methods in FMIPv6 will do that. Some > > with explicit L3 signalling and some without. > > The question that comes to mind is: > > If there are security problems with explicit > > L3 signalling, does removing this signalling and > > replacing it by inter-router signalling > > remove the problems ? ;) > > I mean, if the required security level for a node > > to forward traffic to an address is to prove > > that it has the authority for doing so (hence RR), > > can we just assume that any router sending > > this message to another router, will have > > such authority ? > > I'm just not so sure that the FMIPv6 problems > > will go away if we remove the BU signalling > > to the default router. > > > > Well, with regard to FMIPv6, > my thinking here is that any time you can convert > two problems into one generic problem > and just solve the generic problem, you win. :-) > > Thus, if we could figure out some way to make > the FMIPv6 signaling: > > router<->router > host<->local link router, => Well, if it's to the link local address then we would have a problem. It needs to be an address with larger scope I think. > > then we could remove the problem of how to secure > off-link router<->host and be left only with > the problem of how to secure host<->local link router. > This is a generic IPv6 ND problem, as we have > been discussing in the IPNG list, and so a solution > for ND would work for FMIPv6 also. => There is an additional complication for FMIPv6. The DT recommended that RR is needed for the CoA as well. So this would make life extremely complicated for FMIPv6 to be able to forward before you move. I think we need to spend more time on it. Just like > MIPv6 uses standard ND signaling for CoA > aquistion, instead of special signaling as in MIPv4. => ND does not have a concept of a HoA. The problem with MIPv6 is that you need to verify 2 addresses. The problem with forwarding before moving is that you're essentially asking for a bombing attack for a short period of time :) (until you verify your CoA). Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 15 19:01: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 TAA14340 for ; Fri, 15 Mar 2002 19:01:12 -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 RAA24748; Fri, 15 Mar 2002 17:00: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 QAA05407; Fri, 15 Mar 2002 16:00: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 g2FNxIKL003228 for ; Fri, 15 Mar 2002 15:59:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FNxI1S003227 for mobile-ip-dist; Fri, 15 Mar 2002 15:59: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FNxFKL003220 for ; Fri, 15 Mar 2002 15:59: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 PAA14581 for ; Fri, 15 Mar 2002 15:59:16 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00081 for ; Fri, 15 Mar 2002 15:59:15 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FNxEI17726; Fri, 15 Mar 2002 15:59:14 -0800 (PST) Message-ID: <0a9101c1cc7d$2fbe6630$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Erik Nordmark" References: <4DA6EA82906FD511BE2F00508BCF053802C6AB40@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Fri, 15 Mar 2002 15:57: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 Let's talk about it off line next week. Maybe CT will help, though I've heard some arguments against using CT for IPsec context. I'm hoping we can have some of these issues worked out by Yokohama. jak ----- Original Message ----- From: "Hesham Soliman (ERA)" To: ; "Erik Nordmark" Sent: Friday, March 15, 2002 3:14 PM Subject: RE: [mobile-ip] Security on Local "Home Agent" Functionality? > => Well, if it's to the link local address > then we would have a problem. It needs > to be an address with larger scope I think. > > > > > then we could remove the problem of how to secure > > off-link router<->host and be left only with > > the problem of how to secure host<->local link router. > > This is a generic IPv6 ND problem, as we have > > been discussing in the IPNG list, and so a solution > > for ND would work for FMIPv6 also. > > => There is an additional complication for FMIPv6. > The DT recommended that RR is needed for the > CoA as well. So this would make life extremely > complicated for FMIPv6 to be able to forward > before you move. > > I think we need to spend more time on it. > > Just like > > MIPv6 uses standard ND signaling for CoA > > aquistion, instead of special signaling as in MIPv4. > > => ND does not have a concept of a HoA. The problem > with MIPv6 is that you need to verify 2 addresses. > The problem with forwarding before moving is > that you're essentially asking for a bombing attack > for a short period of time :) (until you verify > your CoA). > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 01:36: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 BAA21168 for ; Sat, 16 Mar 2002 01:36:02 -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 XAA07991; Fri, 15 Mar 2002 23:35: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 WAA09007; Fri, 15 Mar 2002 22:35: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 g2G6YJKL003638 for ; Fri, 15 Mar 2002 22:34:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2G6YJbf003637 for mobile-ip-dist; Fri, 15 Mar 2002 22:34: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 g2G6YFKL003630 for ; Fri, 15 Mar 2002 22:34:16 -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 WAA28962 for ; Fri, 15 Mar 2002 22:34:17 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04635 for ; Fri, 15 Mar 2002 23:34:16 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3237F6A904 for ; Sat, 16 Mar 2002 08:34:15 +0200 (EET) Message-ID: <3C92E7BD.8050500@kolumbus.fi> Date: Sat, 16 Mar 2002 08:35:41 +0200 From: Jari Arkko 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] MIPv6 Internet Draft 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 Folks, The design team has worked for the last couple of weeks on updating draft-ietf-mobileip-ipv6-15.txt based on the discussions on the mailing list, the consensus that has been reached, and discussions in the team beyond the major issues present in the recommendations. As you surely have noticed, we didn't produce a new version before the Internet Draft deadline. However, we are approaching a new version soon and intend to submit it next week. Even if the current text is not very mature and there are many serious problems in it, we thought it would be useful to start reviewing and discussing this. Also, once the basic message flows and formats are out, it becomes easier to discuss issues on the mailing list. For this purpose we have provided an early version for your review: http://www.piuha.net/~jarkko/publications/mipv6/mipv6-modified-parts-pre16.pdf This file contains only the modified parts in PDF format. I'll send the full new I-D version in text format as soon as I get it. The modifications have also been listed under Appendix A.1 on page 61. Please note that this very much work in progress. The below list gives some of the currently open issues or parts have not been edited right yet: - Need to get IPv6 interface ID bit allocated to be able to prevent bidding down. - Figure out if alternative CoA can work with the RR messaging. - Home agent operation, how to secure: use ESP or AH? - Max BCE entry lifetime has to be specified somewhere. - Use of HAO or not for home registrations. - Authentication data, BU, BA exact formats e.g. parameter vs. fixed field. - Should we specify that the correspondent nodes MUST be able to keep nonces and hence also cookies fresh for at least 60 seconds, in order to ease retransmission implementation on the mobile node side? - Need suboptions on HAO any more? - Securing BRs with authentication data inherited from the BU/BA time? - SPI necessary? - What to put in the future functionality section on e.g. unvHAO or piggybacking? - Need state tables or better behaviour descriptions in the cn, mn chapters? Comments are very much appreciated. Jari Arkko From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 01:43:12 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 BAA21283 for ; Sat, 16 Mar 2002 01:43:11 -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 XAA06356; Fri, 15 Mar 2002 23:42:38 -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 WAA10080; Fri, 15 Mar 2002 22:42: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 g2G6foKL003722 for ; Fri, 15 Mar 2002 22:41:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2G6foYf003721 for mobile-ip-dist; Fri, 15 Mar 2002 22:41: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 g2G6fkKL003714 for ; Fri, 15 Mar 2002 22:41:46 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14726 for ; Fri, 15 Mar 2002 22:41:47 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22250 for ; Fri, 15 Mar 2002 22:41:47 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 779A66A904 for ; Sat, 16 Mar 2002 08:41:40 +0200 (EET) Message-ID: <3C92E97B.4080207@kolumbus.fi> Date: Sat, 16 Mar 2002 08:43:07 +0200 From: Jari Arkko 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] Re: MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.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 And it appears that we now have also I-D format (thanks to Charlie for this). You can reach the files from the links below: I-D format, full text: http://www.piuha.net/~jarkko/publications/mipv6/draft-ietf-mobileip-ipv6-pre16.txt PDF format, modified parts only: http://www.piuha.net/~jarkko/publications/mipv6/mipv6-modified-parts-pre16.pdf Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 20:17: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 UAA12873 for ; Sat, 16 Mar 2002 20:17:04 -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 SAA19615; Sat, 16 Mar 2002 18:13: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 RAA06551; Sat, 16 Mar 2002 17:13: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 g2H1CGKL004981 for ; Sat, 16 Mar 2002 17:12:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2H1CG5a004980 for mobile-ip-dist; Sat, 16 Mar 2002 17:12: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 g2H1CCKL004973 for ; Sat, 16 Mar 2002 17:12:12 -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 g2H1C7x02630; Sun, 17 Mar 2002 02:12:07 +0100 (MET) Date: Sun, 17 Mar 2002 02:12:03 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? To: James Kempf Cc: Erik Nordmark , 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: > OK. But I assume traceroute would show a site local or link local > address if the router only had that, right? So an attacker wouldn't be > able to hack into it even if they knew it was there, unless they could > break through the site local address routing. And I agree that keeping > the router's address "secret" is not sufficient for security, but it is > like making the TTL 255 on ND traffic, a quick and easy way to eliminate > one class of problems, don't you think? Yes, traceroute will show whatever address the routers picks for the ICMP error. But it is harder to make sense out of traceroute if these addresses can't be convered to hostnames that carry some information. So having the router not have a global address makes a lot of assumptions about the operational aspects of the network. If we want the MIPv6 specification and MNs implemented from it be able to do bindings for a previous CoA when the previous default router doesn't have a global address it seems like there has to be a way to tell whether the site-local address of that router is in fact valid in the new location of the MN after a move. > Actually, I think so. This is precisely what the fast handoff proposals > do. The problem with forwarding from previous care of address is that it > is reactive and requires the MN to have a care of address. By the time > the MN has obtained a care of address, many packets may have been > dropped (note that other reactive proposals not requiring the MN to > obtain a care of address may not have this problem). The proactive > approaches in the FMIPv6 draft do better, because they allow the tunnel > to be set up as soon as the MN moves from the old AR. OK > > The security requirements for the HA result in the assumption that the > MN > > has a pre-configured arrangement with its HA in order to associate > > the authorization to do bindings for the HoA with an IPsec SA. > > If this is applied to the HA for the previous CoA it would seem to > > require some form of pre-establishment there as well. > > But that wouldn't introduce any new security concerns and not require > > additional specification work. > > > > But shouldn't this at least be stated in the MIPv6 spec somewhere? Yes, I think so. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 20:17:46 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 UAA12920 for ; Sat, 16 Mar 2002 20:17: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 SAA00546; Sat, 16 Mar 2002 18:14: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 RAA06755; Sat, 16 Mar 2002 17:13: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 g2H1DHKL004998 for ; Sat, 16 Mar 2002 17:13:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2H1DHGr004997 for mobile-ip-dist; Sat, 16 Mar 2002 17:13: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 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 g2H1DCKL004990 for ; Sat, 16 Mar 2002 17:13: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 g2H1DBx02675; Sun, 17 Mar 2002 02:13:11 +0100 (MET) Date: Sun, 17 Mar 2002 02:13:07 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design teamrecommendation: New recommendation on piggybacking) To: vijayd@iprg.nokia.com Cc: 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 current proposal is to use both a final and non-final Mobility > Header (MH). In Case 1, the non-final MH is used (because it is > being piggybacked). And when the intermediate router (SG) receives > this packet, it treats the MH as a normal extension header, scans > past it, finds the payload and applies the appropriate IPSec > policy. This should work. > > You were right, but the problem exists with the earlier proposal. > Not with the most current piggybacking proposal which has both > a final and non-final MH. Vijay, How do the know header types allow the sender to determine the policy at the SG? Suppose the SG has a policy saying that the MH header type needs to be protected. Are you disallowing such policies at the SG? I also don't understand why the writeup says IPsec does this for any packet. If no policy exists, the final header type MAY be changed to the non-final extension, If it doesn't get changed then the SG can't have a policy for the payload either. So I think it should be a MUST instead of a MAY above, but the note doesn't explain the reasoning for the MAY. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 20:41: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 UAA13510 for ; Sat, 16 Mar 2002 20:41: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 RAA16923; Sat, 16 Mar 2002 17:37: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 RAA10974; Sat, 16 Mar 2002 17:37: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 g2H1aOKL005143 for ; Sat, 16 Mar 2002 17:36:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2H1aOWV005142 for mobile-ip-dist; Sat, 16 Mar 2002 17: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 jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2H1aLKL005135 for ; Sat, 16 Mar 2002 17:36:21 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g2H1aNXO389454; Sat, 16 Mar 2002 17:36:23 -0800 (PST) Message-Id: <200203170136.g2H1aNXO389454@jurassic.eng.sun.com> Date: Sat, 16 Mar 2002 17:38:34 -0800 (PST) From: Samita Chakrabarti Subject: [mobile-ip] MIPv6 Draft-15 general issues from Connectathon-2002 To: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com Cc: samita@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yuytW6EQhLUDZo0PYe8Ixg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-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 following issues were discussed (some cases solutions were suggested) at the Connectathon 2002 discussion session on MIPv6 spec issues. MIPv6 participants at Connectathon would like to see these issues resolved/clarified at draft-16 version of MIPv6 draft. 1) The correspondent node section should specify what status code the CN would return if it receives a de-registration BU for which there is no matching binding exists. Currently, it can only specify status (128- reason unspecified), but it's better to have a specific status code to indicate to MN that there is no BCE to delete. Otherwise, MN would not know whether the BACK status code is for some other reason or non-existent BCE. A new status code is perhaps a better choice for security concerned MNs which want to delete it's BCE from the CN before going away. 2) When neighbor solicitation is sent to the global address of the MN at it's home network, should HA tunnel this to MN ? At Connectathon discussion, the rough consensus was that NS should be filtered out. The draft should specify the behavior in this case. 3) Should the implementation drop the piggybacked data if the BY sequence number is out of order (if piggybacking is adopted) ? 4) Apparently the draft-15 (section 5.2) is not quite clear on benefit of setting refresh value of BACK. The draft describes home-agent node and non-homeagent cases and specifies that the refresh value SHOULD be equal to the lifetime for non-home-agent nodes. Question was raised in the discussion on usage of refresh field as it is a 32 bit quantity. If it's not that useful, removing the refresh field would save bits where bandwitdth is limited or expensive. 5) section 9.4 of draft-15 says that HA uses routing header when it communicates to the MN while it's not home and HA has a BCE for the MN. The de-registration section is not clear (section 9.2), whether HA would use routing header or not with the BACK when MN is back home. It does not make sense to have routing header with the BACK while MN is back home. The draft should specify the steps in this case whether HA would delete the BCE first and then send BACK to the MN without routing header. This clarification is highly needed in the draft, as it causes interoperability problem due to different interpretation of the meaning of the draft. -Samita From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 20:57: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 UAA13772 for ; Sat, 16 Mar 2002 20:57: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 RAA17327; Sat, 16 Mar 2002 17:53:38 -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 RAA06628; Sat, 16 Mar 2002 17: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 g2H1qWKL005238 for ; Sat, 16 Mar 2002 17:52:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2H1qVcU005237 for mobile-ip-dist; Sat, 16 Mar 2002 17:52: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 jurassic.eng.sun.com (jurassic [129.146.89.50] (may be forged)) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2H1qTKL005230 for ; Sat, 16 Mar 2002 17:52:29 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g2H1qSXO390243; Sat, 16 Mar 2002 17:52:28 -0800 (PST) Message-Id: <200203170152.g2H1qSXO390243@jurassic.eng.sun.com> Date: Sat, 16 Mar 2002 17:54:39 -0800 (PST) From: Samita Chakrabarti Subject: [mobile-ip] RFC3220 clarification issues To: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com Cc: samita@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Dd1UIcQomLPFLdb+P4SdKg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-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 following issues and questions were raised at the Connectathon 2002 event in March. Minor interoperability issues detected from RFC3220: Section 3.5.2 says: 3.5.2. Mobile-Home Authentication Extension Exactly one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent. However, draft is not clear about the error code if multiple MN-HA extension headers were present. Should this be poorly formatted request ? Section 3.7.2.1 has a contradictory statement which should be corrected: If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign Authentication Extension is found, or if the Authenticator is invalid, the foreign agent MUST *silently* discard the Request and SHOULD log the event as a security exception. The foreign agent also SHOULD send a Registration Reply to the mobile node with Code 67. If the FA silently discards the packet how should it send a reply to the MN ? Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 16 23:02: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 XAA17528 for ; Sat, 16 Mar 2002 23:02: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 TAA21132; Sat, 16 Mar 2002 19:55: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 TAA22952; Sat, 16 Mar 2002 19:55: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 g2H3sDKL005507 for ; Sat, 16 Mar 2002 19:54:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2H3sD5g005506 for mobile-ip-dist; Sat, 16 Mar 2002 19:54: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 g2H3sAKL005499 for ; Sat, 16 Mar 2002 19:54: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 TAA10425 for ; Sat, 16 Mar 2002 19:54:11 -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 UAA26261 for ; Sat, 16 Mar 2002 20:54:10 -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 TAA06396; Sat, 16 Mar 2002 19:54:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2H3s9901823; Sat, 16 Mar 2002 19:54:09 -0800 X-mProtect:  Sat, 16 Mar 2002 19:54:09 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.150, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgaQbmh; Sat, 16 Mar 2002 19:54:06 PST Message-ID: <3C94130A.2000300@iprg.nokia.com> Date: Sat, 16 Mar 2002 19:52:42 -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: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Extension Header (was ISSUE: Design teamrecommendation: New recommendation on piggybacking) 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 Erik, Erik Nordmark wrote: >>The current proposal is to use both a final and non-final Mobility >>Header (MH). In Case 1, the non-final MH is used (because it is >>being piggybacked). And when the intermediate router (SG) receives >>this packet, it treats the MH as a normal extension header, scans >>past it, finds the payload and applies the appropriate IPSec >>policy. This should work. >> >>You were right, but the problem exists with the earlier proposal. >>Not with the most current piggybacking proposal which has both >>a final and non-final MH. >> > > Vijay, > > How do the know header types allow the sender to determine the policy > at the SG? > > Suppose the SG has a policy saying that the MH header type needs to be > protected. Are you disallowing such policies at the SG? I definitely dont want an intermediate SG to apply any IPSec policy to the Mobility Header. Protection for the Mobility Header is end-to-end. > I also don't understand why the writeup says > IPsec does this for any packet. If no policy exists, the > final header type MAY be changed to the non-final extension, > > If it doesn't get changed then the SG can't have a policy for the payload > either. > So I think it should be a MUST instead of a MAY above, but the note > doesn't explain the reasoning for the MAY. I am not sure I understood this paragraph. I am here in Minneapolis the whole of sunday. I will talk to you sometime..... regards Vijay > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 17 01:28: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 BAA19854 for ; Sun, 17 Mar 2002 01:28: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 XAA08060; Sat, 16 Mar 2002 23:17: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 WAA29402; Sat, 16 Mar 2002 22:17: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 g2H6GiKL005719 for ; Sat, 16 Mar 2002 22:16:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2H6GiAc005718 for mobile-ip-dist; Sat, 16 Mar 2002 22:16: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 g2H6GbKL005711 for ; Sat, 16 Mar 2002 22:16:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21231 for ; Sat, 16 Mar 2002 22:16:38 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16324 for ; Sat, 16 Mar 2002 22:16:37 -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 WAA09490; Sat, 16 Mar 2002 22:16:37 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2H6Gat22850; Sat, 16 Mar 2002 22:16:36 -0800 X-mProtect:  Sat, 16 Mar 2002 22:16:36 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.20.253, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpda5wwTc; Sat, 16 Mar 2002 22:16:33 PST Message-ID: <3C9434D4.3D0A466B@iprg.nokia.com> Date: Sat, 16 Mar 2002 22:16:52 -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: samita@eng.sun.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RFC3220 clarification issues References: <200203170152.g2H1qSXO390243@jurassic.eng.sun.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 Samita, I guess we should not have to have rfc3220bis for this! Samita Chakrabarti wrote: > However, draft is not clear about the error code if multiple MN-HA extension > headers were present. Should this be poorly formatted request ? That would seem appropriate to me. There are probably other such illegal formations that are not explicitly indicated by their own error code, and they all would reasonably share that one you suggest. > Section 3.7.2.1 has a contradictory statement which should be corrected: > > If no Mobile-Foreign > Authentication Extension is found, or if more than one Mobile-Foreign > Authentication Extension is found, or if the Authenticator is > invalid, the foreign agent MUST *silently* discard the Request and > SHOULD log the event as a security exception. The foreign agent also > SHOULD send a Registration Reply to the mobile node with Code 67. > > If the FA silently discards the packet how should it send a reply to > the MN ? You are right that this is poor wording. The intention was that the Registration Request should not be sent on to the home agent, since it was already rejected. So, if one insisted on finding an arcane interpretation to allow this, we could say that the "Request" is discarded, and the Reply was newly generated. But I already agree with you that this isn't what people usually mean by "silently discard". Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 17 11:25: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 LAA04511 for ; Sun, 17 Mar 2002 11:25:58 -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 JAA28425; Sun, 17 Mar 2002 09:25: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 IAA28929; Sun, 17 Mar 2002 08:25: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 g2HGOZKL006779 for ; Sun, 17 Mar 2002 08:24:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HGOZdn006778 for mobile-ip-dist; Sun, 17 Mar 2002 08:24: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 g2HGOWKL006771 for ; Sun, 17 Mar 2002 08:24:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04911 for ; Sun, 17 Mar 2002 08:24:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00865 for ; Sun, 17 Mar 2002 08:24:35 -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 g2HGOIk25418; Sun, 17 Mar 2002 17:24: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 RAA23196; Sun, 17 Mar 2002 17:24: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 g2HGOIg58562; Sun, 17 Mar 2002 17:24:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203171624.g2HGOIg58562@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, mroe@microsoft.com Subject: Re: [mobile-ip] Piggybacking - DT recommendation In-reply-to: Your message of Mon, 04 Mar 2002 14:41:40 +0100. Date: Sun, 17 Mar 2002 17:24: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: In your previous mail you wrote: => catching an old mail... I'm trying to work out an example of where an MN tries to use IKE to do a BU with a CN. It goes something like this: - MN kicks IKE to set up a SA to use for the BU Must the MN verify that it has a certificate with its HoA as subject(alt)name to do this? No, because then it would not be able to take advantage of the DNSSEC reference above. Thus an IPsec SA is always attempted. - MN/CN finishes with SA establishment If the subject(alt)name was the home address then the CN can conclude that BUs protected by the SA are authorized for that Home Address. If not the CN does a DNS lookup of the hostname in the certificate subject(alt)name. It must use DNSsec for this i.e. all signature chains must be verified (the way DNSsec normally does it). If (one of) the IP addresses returned from the DNS is the HoA then BUs protected by the SA are authorized for that HoA. If the subject(alt)names are only mbox names (such as erik.nordmark@eng.sun.com) then this will fail and the SA is not useful for authorizing BUs. Does the above make sense? => yes, DNSsec moves the "should use IP addresses" to "should use FQDNs". The lookup of a hostname (FQDN) with DNSsec validation is presumably more expensive than the extra roundtrip caused by using RR together with IPsec. => this argument is valid if IPsec is used *only* for BU protection. My concern is when IPsec is used for another reason, it should be allowed to protect BUs too without extra-overhead (no RR for instance). And if RR is used together with IPsec you can also handle things for mbox certificates. => I strongly disagree: we should not mixed RR which has easy MITM problems with strong authentication is the final goal is or can be strong authentication. Thanks Francis.Dupont@enst-bretagne.fr PS: this is more IPsec discussion than mobile IP. From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 17 12:27: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 MAA07068 for ; Sun, 17 Mar 2002 12:27:56 -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 KAA22239; Sun, 17 Mar 2002 10:27: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 JAA29270; Sun, 17 Mar 2002 09:27: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 g2HHQOKL006918 for ; Sun, 17 Mar 2002 09:26:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HHQOhx006917 for mobile-ip-dist; Sun, 17 Mar 2002 09:26: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 g2HHQKKL006910 for ; Sun, 17 Mar 2002 09:26:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29176 for ; Sun, 17 Mar 2002 09:26:22 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00255 for ; Sun, 17 Mar 2002 09:26: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 g2HHQFk00400 for ; Sun, 17 Mar 2002 18:26: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 SAA23473 for ; Sun, 17 Mar 2002 18: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 g2HHQFg58752 for ; Sun, 17 Mar 2002 18:26:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203171726.g2HHQFg58752@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 Mon, 04 Mar 2002 17:39:17 +0100. <4DA6EA82906FD511BE2F00508BCF053802C6AA65@Esealnt861.al.sw.ericsson.se> Date: Sun, 17 Mar 2002 18: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: => The only major difference I see is the amplification aspect of the attack. => I can't see an amplification aspect, this is only a variation of the fake HAO reflection attack... => It doesn't matter if the target notices the RH or not. The point is you would not be able to prevent it. You will detect the attacker of course, but you won't prevent the attack. => this is already the case with a direct attack or an indirect attack through a rogue CN. I can't see what are your requirements here? => As I said, I see the main difference being the amplification => there is no amplification, only reflection. but I also see a performance loss when always mandating RR for the CoA. => this is my concern: RR gives nothing more. Hence, the internal debate with myself :) The question is how secure we want RO to be given the performance loss. I can't answer it yet without looking into it in more detail. => (:-) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 17 18:24: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 SAA13012 for ; Sun, 17 Mar 2002 18:24:57 -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 QAA02416; Sun, 17 Mar 2002 16:23: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 PAA22868; Sun, 17 Mar 2002 15:22: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 g2HNLmKL007350 for ; Sun, 17 Mar 2002 15:21:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HNLmcD007349 for mobile-ip-dist; Sun, 17 Mar 2002 15: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HNLjKL007342 for ; Sun, 17 Mar 2002 15:21:45 -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 PAA22829 for ; Sun, 17 Mar 2002 15:21:46 -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 QAA14642 for ; Sun, 17 Mar 2002 16:21:45 -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 g2HNLiR13087 for ; Mon, 18 Mar 2002 00:21:44 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Mar 18 00:20:14 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 00:21:20 +0100 Message-ID: From: "Karen E Nielsen (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Mon, 18 Mar 2002 00:20:23 +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 Viray, I agree that the conflict between piggybacking and intermediate routers having IPSEC policies that the MN's and the CN's not are aware off is non-relevant in the current proposal. However, the problem with the new proposal and the RR messages is that the requirement that the RR messages (2b. and, perhaps, 2a.)) should be protected in secure tunnels HA-MN means that NOT ONLY can these messages not be piggybacked - but they MUST be implemented as final protocol elements in order to be detectable by the IPSEC selectors. In other words the extension header approach will not be usable for the 2a. and 2b. RR messages. So if you want to go with the extension header approach, then half the RR messages must be implemented in a final protocol element and half in an extension header. Karen > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: 15. marts 2002 22:57 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Consensus to include recent piggybacking > proposal? > > > "Hesham Soliman (ERA)" wrote: > > > > Charlie, > > > > > > Karen Nielsen sent two emails to highlight > > > > the inability to piggyback some RR messages > > > > since they are placed in IPsec tunnels > > > > by the HA. You can generalise the same > > > > problem for Security Gateways, in those cases > > > > the MN might not be aware of security policies by > > > > intermediate routers (SGs). > > > > > > This is not an issue with the current proposal, > > > as Vijay has pointed out. > > > > => As Vijay pointed out in his most recent email, > > there could be issues with piggybacking 1a and > > 2a. Karen can speak for herself, but reading the > > last email, it said something like 'strongly > > stress ....that piggybaking 1a and 2a is not possible'. > > Hesham, > > I said either way is fine. That is *NOT* the issue here.... > > Vijay > > > > > Also the other point was SGWs which the MN is > > not aware of. > > > > > > > > > Also the note was only relevant to IPsec and > > > > didn't address the QoS issues (e.g. when using > > > > Diffserv e2e or when having the Diffserv bits > > > > set by intermediate routers). These comments > > > > were explicitly made by David Oran and to some > > > > extent in my earlier emails. > > > > > > I responded at length to those e-mails. There is no > > > issue with respect to piggybacking and QoS, > > > _unless_ you are trying to have some sort of > > > "implicit" QoS without asking for it. In any > > > other case, the QoS signalling would trivially > > > be able to handle any setup required for > > > deciding whether or not to use piggybacking. > > > > => First of all, no one is using e2e QoS signalling > > today, please correct me if I'm wrong. > > Second, I might have missed on of your emails > > but I'd appreciate a pointer on how > > Diffserv can be used here if there is a conflict > > between the BU DSCPs and the payload's. > > Obviously Diffserv is not always used e2e and > > can be set by intermediate routers. > > > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 17 23:13: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 XAA19164 for ; Sun, 17 Mar 2002 23:13: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 VAA07983; Sun, 17 Mar 2002 21:13: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 UAA18356; Sun, 17 Mar 2002 20:12: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 g2I4BoKL007763 for ; Sun, 17 Mar 2002 20:11:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2I4Bosq007762 for mobile-ip-dist; Sun, 17 Mar 2002 20:11: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 g2I4BkKL007755 for ; Sun, 17 Mar 2002 20:11:46 -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 UAA18265 for ; Sun, 17 Mar 2002 20:11:48 -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 UAA22007 for ; Sun, 17 Mar 2002 20:11:48 -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 UAA12551 for ; Sun, 17 Mar 2002 20:11:48 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2I4Bhd09578 for ; Sun, 17 Mar 2002 20:11:43 -0800 X-mProtect:  Sun, 17 Mar 2002 20:11:43 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.73, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdG3Sa2R; Sun, 17 Mar 2002 20:11:40 PST Message-ID: <3C9568A1.6090800@iprg.nokia.com> Date: Sun, 17 Mar 2002 20:10:09 -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] Consensus to include recent piggybacking proposal ? 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 Karen, Karen E Nielsen (TED) wrote: > Hi Viray, > > I agree that the conflict between piggybacking and intermediate routers having IPSEC policies > that the MN's and the CN's not are aware off is non-relevant in the current proposal. good. > > However, the problem with the new proposal and the RR messages > is that the requirement that the RR messages (2b. and, > perhaps, 2a.)) should be protected in secure tunnels HA-MN means that > NOT ONLY can these messages not be piggybacked - but they MUST be implemented as final > protocol elements in order to be detectable by the IPSEC selectors. Okay. 2a and 2b cant be piggybacked (that means final Mobility Header). Fine with me. > In other words the extension header approach will not be usable for the > 2a. and 2b. RR messages. So if you want to go with the extension header > approach, then half the RR messages must be implemented in a final protocol > element and half in an extension header. So?? I dont see the problem. 1a and 1b are initiated by MN (HoTI and CoTI). And 2a and 2b (HoT and CoT) are responses from the CN. Or I am too tired to figure out what you are saying.... are you at the IETF? regards Vijay > > Karen > > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: 15. marts 2002 22:57 >>To: mobile-ip@sunroof.eng.sun.com >>Subject: Re: [mobile-ip] Consensus to include recent piggybacking >>proposal? >> >> >>"Hesham Soliman (ERA)" wrote: >> >>>Charlie, >>> >>> > > Karen Nielsen sent two emails to highlight >>> > > the inability to piggyback some RR messages >>> > > since they are placed in IPsec tunnels >>> > > by the HA. You can generalise the same >>> > > problem for Security Gateways, in those cases >>> > > the MN might not be aware of security policies by >>> > > intermediate routers (SGs). >>> > >>> > This is not an issue with the current proposal, >>> > as Vijay has pointed out. >>> >>>=> As Vijay pointed out in his most recent email, >>>there could be issues with piggybacking 1a and >>>2a. Karen can speak for herself, but reading the >>>last email, it said something like 'strongly >>>stress ....that piggybaking 1a and 2a is not possible'. >>> >>Hesham, >> >>I said either way is fine. That is *NOT* the issue here.... >> >>Vijay >> >> >>>Also the other point was SGWs which the MN is >>>not aware of. >>> >>> > >>> > > Also the note was only relevant to IPsec and >>> > > didn't address the QoS issues (e.g. when using >>> > > Diffserv e2e or when having the Diffserv bits >>> > > set by intermediate routers). These comments >>> > > were explicitly made by David Oran and to some >>> > > extent in my earlier emails. >>> > >>> > I responded at length to those e-mails. There is no >>> > issue with respect to piggybacking and QoS, >>> > _unless_ you are trying to have some sort of >>> > "implicit" QoS without asking for it. In any >>> > other case, the QoS signalling would trivially >>> > be able to handle any setup required for >>> > deciding whether or not to use piggybacking. >>> >>>=> First of all, no one is using e2e QoS signalling >>>today, please correct me if I'm wrong. >>>Second, I might have missed on of your emails >>>but I'd appreciate a pointer on how >>>Diffserv can be used here if there is a conflict >>>between the BU DSCPs and the payload's. >>>Obviously Diffserv is not always used e2e and >>>can be set by intermediate routers. >>> >>>Hesham >>> From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 18 00: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 AAA20620 for ; Mon, 18 Mar 2002 00:37:37 -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 WAA27095; Sun, 17 Mar 2002 22:37: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 VAA27946; Sun, 17 Mar 2002 21:37: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 g2I5aJKL007920 for ; Sun, 17 Mar 2002 21:36:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2I5aJ8H007919 for mobile-ip-dist; Sun, 17 Mar 2002 21:36: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 g2I5aGKL007912 for ; Sun, 17 Mar 2002 21:36:16 -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 VAA27872 for ; Sun, 17 Mar 2002 21:36:17 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA17901 for ; Sun, 17 Mar 2002 22:36:15 -0700 (MST) Received: from T23KEMPF (dhcp163.docomolabs-usa.com [172.21.96.163]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2I5aCI00505; Sun, 17 Mar 2002 21:36:12 -0800 (PST) Message-ID: <003201c1ce3e$98773d10$a36015ac@T23KEMPF> From: "James Kempf" To: Cc: "Erik Nordmark" , References: Subject: Re: [mobile-ip] Security on Local "Home Agent" Functionality? Date: Sun, 17 Mar 2002 21:32:59 -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 > > OK. But I assume traceroute would show a site local or link local > > address if the router only had that, right? So an attacker wouldn't be > > able to hack into it even if they knew it was there, unless they could > > break through the site local address routing. And I agree that keeping > > the router's address "secret" is not sufficient for security, but it is > > like making the TTL 255 on ND traffic, a quick and easy way to eliminate > > one class of problems, don't you think? > > Yes, traceroute will show whatever address the routers picks for the > ICMP error. But it is harder to make sense out of traceroute if these > addresses can't be convered to hostnames that carry some information. > > So having the router not have a global address makes a lot of assumptions > about the operational aspects of the network. > True. > If we want the MIPv6 specification and MNs implemented from it > be able to do bindings for a previous CoA when the previous default router > doesn't have a global address it seems like there has to be a way to > tell whether the site-local address of that router is in fact valid > in the new location of the MN after a move. > Well, one of the points I think I am trying to make is that FMIPv6 is probably going to be better for fast handover, though there are other reasons why one might want to do FPCoA. And if it were possible in FMIPv6 to confine signaling between the mobile host and the local access router, the mobile host would never need to discover a global or site local address, it could always just use the on link address. This might be able to reduce the security impact on FMIPv6 considerably. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 18 07:02: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 HAA03704 for ; Mon, 18 Mar 2002 07:02: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 DAA16544; Mon, 18 Mar 2002 03:59: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 DAA18527; Mon, 18 Mar 2002 03:59: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 g2IBwlKL008316 for ; Mon, 18 Mar 2002 03:58:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IBwl6h008315 for mobile-ip-dist; Mon, 18 Mar 2002 03:58: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 g2IBwiKL008308 for ; Mon, 18 Mar 2002 03:58: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 DAA24241 for ; Mon, 18 Mar 2002 03:58:44 -0800 (PST) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05277 for ; Mon, 18 Mar 2002 04:58:44 -0700 (MST) Received: from ipsi.fraunhofer.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA24270; Mon, 18 Mar 2002 12:58:41 +0100 (MET) Message-ID: <3C95D935.25B10724@ipsi.fraunhofer.de> Date: Mon, 18 Mar 2002 13:10:29 +0100 From: Wolfgang Schoenfeld Organization: FhG IPSI X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: de,en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] Localized Mobility Management 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, Following the discussion on this and similar topics in this mailing list, we published a paper "Modeling IP-Based Mobility Management" at CNDS 2002 (http://www.ece.neu.edu/conf/CNDS/2002/). It is also available at http://www.ipsi.fraunhofer.de/~schfeld/Papers/cnds2002.ps Comments are welcome. From the Abstract: We develop a simple model of mobility management, analyse handoff performance as well as its effect on payload, and explore the effect of hierarchies as well of some handoff variants. Moreover, we show that the modeled mobility management is robust even if the mobile device moves faster than handoff performance seems to allow. Wolfgang -- Prof. Dr. Wolfgang Schoenfeld, Fraunhofer IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 18 09:11: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 JAA05625 for ; Mon, 18 Mar 2002 09:11:09 -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 GAA07283; Mon, 18 Mar 2002 06:10:34 -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 GAA21073; Mon, 18 Mar 2002 06:10: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 g2IE9OKL008582 for ; Mon, 18 Mar 2002 06:09:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IE9Ojx008581 for mobile-ip-dist; Mon, 18 Mar 2002 06:09: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IE9KKL008574 for ; Mon, 18 Mar 2002 06:09:20 -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 GAA16370 for ; Mon, 18 Mar 2002 06:09:22 -0800 (PST) Received: from gems.uia.ac.be (hgems.uia.ac.be [143.169.254.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21080 for ; Mon, 18 Mar 2002 07:09:21 -0700 (MST) Received: from pcinf15 (pcinf15.uia.ac.be [143.169.1.67]) by gems.uia.ac.be (8.11.6/8.11.6) with ESMTP id g2IE9If10438 for ; Mon, 18 Mar 2002 15:09:18 +0100 (MET) From: "Nik Van den Wijngaert" To: Subject: [mobile-ip] IPv4 regional registration Date: Mon, 18 Mar 2002 15:07:52 +0100 Message-ID: <000301c1ce86$4b1c4d10$4301a98f@pcinf15> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Scanned-By: MIMEDefang 2.5 Sender: owner-mobile-ip@sunroof.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 everybody, I'm new to this list, so forgive me if this has been raised before (although I couldn't find any reference in the archives). I'm implementing hierarchical mobile ip (v4), so I'm using the document "draft-ietf-mobileip-reg-tunnel-06" In section B.2 there is a paragraph that states: " The crossover FA will receive both a Registration Request and a Binding Update for the mobile node. When the crossover FA receives the Registration Request, it continues to send traffic via the old path until it receives a valid Registration Reply with a Code indicating success. Then it starts sending traffic via the new route. " But isn't this crossover FA the FA that will generate the registration reply? I'm confused about the part "...until it receives a valid registration reply...". Maybe I'm missing something obvious here? Thanks, Nik Van den Wijngaert. From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 18 11: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 LAA08281 for ; Mon, 18 Mar 2002 11:05:50 -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 JAA20605; Mon, 18 Mar 2002 09:05: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 IAA10928; Mon, 18 Mar 2002 08:05: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 g2IG4HKL008968 for ; Mon, 18 Mar 2002 08:04:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IG4GA9008967 for mobile-ip-dist; Mon, 18 Mar 2002 08:04: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 g2IG4DKL008960 for ; Mon, 18 Mar 2002 08:04:13 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06814 for ; Mon, 18 Mar 2002 08:04:14 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06642 for ; Mon, 18 Mar 2002 08:04:17 -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 g2IG49Uw010497 for ; Mon, 18 Mar 2002 17:04:13 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Mar 18 17:04:08 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 17:04:08 +0100 Message-ID: From: "Karen E Nielsen (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Mon, 18 Mar 2002 17:04:06 +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: > > > Okay. 2a and 2b cant be piggybacked (that means final Mobility > Header). Fine with me. > > > In other words the extension header approach will not be > usable for the > > 2a. and 2b. RR messages. So if you want to go with the > extension header > > approach, then half the RR messages must be implemented in > a final protocol > > element and half in an extension header. > > > So?? I dont see the problem. 1a and 1b are initiated by MN (HoTI > and CoTI). And 2a and 2b (HoT and CoT) are responses from the CN. > Or I am too tired to figure out what you are saying.... > > are you at the IETF? I am. However, I think that we are in full agreement. The fact that the RR 2a and 2b messages must be put in the final MH was all that I wanted to point out. Karen > > regards > Vijay > > > > > Karen > > > > > > > >>-----Original Message----- > >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > >>Sent: 15. marts 2002 22:57 > >>To: mobile-ip@sunroof.eng.sun.com > >>Subject: Re: [mobile-ip] Consensus to include recent piggybacking > >>proposal? > >> > >> > >>"Hesham Soliman (ERA)" wrote: > >> > >>>Charlie, > >>> > >>> > > Karen Nielsen sent two emails to highlight > >>> > > the inability to piggyback some RR messages > >>> > > since they are placed in IPsec tunnels > >>> > > by the HA. You can generalise the same > >>> > > problem for Security Gateways, in those cases > >>> > > the MN might not be aware of security policies by > >>> > > intermediate routers (SGs). > >>> > > >>> > This is not an issue with the current proposal, > >>> > as Vijay has pointed out. > >>> > >>>=> As Vijay pointed out in his most recent email, > >>>there could be issues with piggybacking 1a and > >>>2a. Karen can speak for herself, but reading the > >>>last email, it said something like 'strongly > >>>stress ....that piggybaking 1a and 2a is not possible'. > >>> > >>Hesham, > >> > >>I said either way is fine. That is *NOT* the issue here.... > >> > >>Vijay > >> > >> > >>>Also the other point was SGWs which the MN is > >>>not aware of. > >>> > >>> > > >>> > > Also the note was only relevant to IPsec and > >>> > > didn't address the QoS issues (e.g. when using > >>> > > Diffserv e2e or when having the Diffserv bits > >>> > > set by intermediate routers). These comments > >>> > > were explicitly made by David Oran and to some > >>> > > extent in my earlier emails. > >>> > > >>> > I responded at length to those e-mails. There is no > >>> > issue with respect to piggybacking and QoS, > >>> > _unless_ you are trying to have some sort of > >>> > "implicit" QoS without asking for it. In any > >>> > other case, the QoS signalling would trivially > >>> > be able to handle any setup required for > >>> > deciding whether or not to use piggybacking. > >>> > >>>=> First of all, no one is using e2e QoS signalling > >>>today, please correct me if I'm wrong. > >>>Second, I might have missed on of your emails > >>>but I'd appreciate a pointer on how > >>>Diffserv can be used here if there is a conflict > >>>between the BU DSCPs and the payload's. > >>>Obviously Diffserv is not always used e2e and > >>>can be set by intermediate routers. > >>> > >>>Hesham > >>> > > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 18 11:27: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 LAA09662 for ; Mon, 18 Mar 2002 11:27: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 JAA21898; Mon, 18 Mar 2002 09:26: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 IAA17323; Mon, 18 Mar 2002 08:26: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 g2IGPoKL009088 for ; Mon, 18 Mar 2002 08:25:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IGPoFh009087 for mobile-ip-dist; Mon, 18 Mar 2002 08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IGPlKL009080 for ; Mon, 18 Mar 2002 08:25:47 -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 IAA16939 for ; Mon, 18 Mar 2002 08:25:48 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01210 for ; Mon, 18 Mar 2002 09:25: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 g2IGPhUw019953 for ; Mon, 18 Mar 2002 17:25:44 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Mon Mar 18 17:25:42 2002 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 17:25:42 +0100 Message-ID: From: "Karen E Nielsen (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ? Date: Mon, 18 Mar 2002 17:25: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 Viray, Sorry for sending multiple mails. > > > Hi Viray, > > > > I agree that the conflict between piggybacking and > intermediate routers having IPSEC policies > > that the MN's and the CN's not are aware off is > non-relevant in the current proposal. > > > good. > Conceptually though, one aspect of the problem still stands in the sense that by allowing the optional implementation of MIPv6 Control Messages in extension headers then they (MIPv6 control messages) cannot in general be protected by IPSEC policies set-up by the network (for some reason unknown to the user) over certain un-trusted links. Karen From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 18 15:18: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 PAA18525 for ; Mon, 18 Mar 2002 15:18:22 -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 NAA26119; Mon, 18 Mar 2002 13:17: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 MAA13983; Mon, 18 Mar 2002 12:17: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 g2IKEeKL009964 for ; Mon, 18 Mar 2002 12:14:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IKEeX9009963 for mobile-ip-dist; Mon, 18 Mar 2002 12:14: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 g2IKEbKL009956 for ; Mon, 18 Mar 2002 12:14:37 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11818 for ; Mon, 18 Mar 2002 12:14:39 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15337 for ; Mon, 18 Mar 2002 12:14:42 -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 g2IKEZq11937; Mon, 18 Mar 2002 14:14:35 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 14:14:36 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCAC8@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" , "'Charles E. Perkins'" Subject: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Mon, 18 Mar 2002 14:14:32 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CEB9.8446F940" Sender: owner-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_01C1CEB9.8446F940 Content-Type: text/plain; charset="iso-8859-1" Hello all; This email is quite long and I appreciate it if as many people as possible have the patience to read through it and post their input. I exchanged few emails with Charlie Perkins which led me to post the following for this mail list. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++ From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to share with all of you the following proposed interpretation to prevent a conflict between these two RFCs. 1. RFC3220 introduced a new term "Authorization-enabling extension" and made it restricted that registration request MUST have only one authorization-enabling extension after renaming the MN-HA Authentication extension as authorization-enabling extension, as per section 3.5.2: "3.5.2. Mobile-Home Authentication Extension Exactly one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent. The Mobile-Home Authentication Extension is always an authorization-enabling for registration messages specified in this document. This requirement is intended to eliminate problems [2] which result from the uncontrolled propagation of remote redirects in the Internet. The location of the extension marks the end of the authenticated data." 2. This made it impossible for Mobile Node to include the MN-HA and MN-AAA Authentication extensions in the same Registration Request. 3. However, RFC3012 section 6 mandates Mobile Node to include MN-HA Authentication extension in every Registration Request message as long as the Mobile Node has a security association with its Home Agent. (MN MUST always maintain a security association with all of its home agents, as per RFC3220 (RFC2002)), "6. MN-AAA Authentication subtype "............................................ If the MN-AAA Authentication extension is present, then the Registration Message sent by the mobile node MUST contain the Mobile-HA Authentication extension [8] if it shares a security association with the Home Agent............" 4. Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA Authentication extension whenever it does not have a security association with the Foreign Agent, as in section 3.1. Since, at least conceptually although it is not referenced any where in the standard, MN-AAA authentication extension is viewed as an authorization-enabling extension, this very wide interpretation causes a real conflict between RFC3220 & RFC3012 (RFC3012bis). Therefore the following interpretation proposes a solution for this issue: 1. Since RFC3220 defines the Authorization-enabling extension as follows in section 1.6: "Authorization-enabling extension An authentication which makes a (registration) message acceptable to the ultimate recipient of the registration message. An authorization-enabling extension MUST contain an SPI. In this document, all uses of authorization-enabling extension refer to authentication extensions that enable the Registration Request message to be acceptable to the home agent. Using additional protocol structures specified outside of this document, it may be possible for the mobile node to provide authentication of its registration to the home agent, by way of another authenticating entity within the network that is acceptable to the home agent (for example, see RFC 2794 [6])." 2. While RFC3012 introduced MN-AAA authentication extension to offer a mechanism to authenticate the Mobile Node to the visited Foreign Agent, as it is clearly obvious in the Abstract, Introduction, and section 3.1 ""3.1. Mobile Node Processing for Registration Requests". AND since the ultimate recipient of the Registration Request is always the Home Agent, MN-AAA authentication extension does not comply with the definition of the Authorization-enabling extension offered in RFC3220. 1. This will resolve the conflict and allows the Mobile Node to always include the MN-HA Authentication extension (Authorization-enabling) and MN-AAA authentication extension (not an authorization-enabling). 2. When FA process the Registration Request received from the Mobile Node, it is optional for the FA to forward the MN-AAA authentication extension or remove it as per RFC3012 section 3.2. "The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension from the Registration Request prior to the completion of the authentication performed by the AAA infrastructure. The appendix provides an example of an action that could be taken by a foreign agent." 3. Then HA always receives a MN-HA Authentication extension and optionally MN-AAA authentication extension in every Registration Request. HA may use AAA to get the shared secret key for authenticating the RRQ message using MN-HA Authentication extension or use the MN-AAA authentication extension through the AAA infrastructure. Now As per Charlie's suggestion: 1. A new cause code for the MN failing authentication at the Home Agent using the AAA (MN-AAA authentication extension) may be needed. 2. Also, RFC3012bis should be viewed as obsoleting the word "Exactly" -- perhaps changing it to a "At least" in section 3.5.2 of RFC3220. "3.5.2. Mobile-Home Authentication Extension Exactly At least one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent." ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++ Thanks for your consideration. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1CEB9.8446F940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A proposal for resolving a very Possible conflict between = RFC3220 & RFC3012 (RFC3012bis)

Hello all;

This email is quite long and I = appreciate it if as many people as possible have the patience to read = through it and post their input.

I exchanged few emails with Charlie = Perkins which led me to post the following for this mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++
From my reading of RFC3220 and = RFC3012 (RFC3102-bis), I would like to share with all of you the = following proposed interpretation to prevent a conflict between these = two RFCs.


1.      = RFC3220 introduced a new term "Authorization-enabling extension" = and made it restricted that registration request MUST have only one = authorization-enabling extension after renaming the MN-HA = Authentication extension as authorization-enabling extension, as per = section 3.5.2:

        "3.5.2. Mobile-Home Authentication = Extension
   =      Exactly one authorization-enabling extension MUST be present in = all
   =      Registration Requests, and also in all Registration Replies = generated
  =       by the Home Agent.  The = Mobile-Home Authentication = Extension is
   =      always an = authorization-enabling for registration messages specified
   =      in this document.  This requirement is = intended to eliminate problems
   =      [2] which result from the uncontrolled = propagation of remote
   =      redirects in the Internet.  The location = of the extension marks the
   =      end of the authenticated data."

2.      This = made it impossible for Mobile = Node to include the MN-HA and = MN-AAA Authentication extensions in the same Registration = Request.

3.      = However, RFC3012 section 6 = mandates Mobile Node to include MN-HA Authentication extension in every = Registration Request message = as long as the Mobile Node has a security association with its Home = Agent. (MN MUST always maintain a security association with all of its = home agents, as per RFC3220 (RFC2002)),

          &nb= sp;  "6. MN-AAA = Authentication subtype
   =      = "............................................  = If the MN-AAA = Authentication
   =      extension is present, then the Registration = Message sent by the
   =      mobile node MUST contain the Mobile-HA = Authentication extension [8]
  =       if it shares a security association with = the Home Agent............"
4.      Also, RFC3012, mandates that the Mobile Node = MUST include MN-AAA Authentication extension whenever it does not have = a security association with the Foreign Agent, as in section = 3.1.

Since, at least conceptually although it is not referenced any = where in the standard, MN-AAA = authentication extension is viewed as an authorization-enabling = extension, this very wide interpretation causes a real conflict between = RFC3220 & RFC3012 (RFC3012bis). Therefore the following = interpretation proposes a solution for this issue:

1.      = Since RFC3220 defines the Authorization-enabling extension as follows = in section 1.6:

        "Authorization-enabling = extension
        An authentication which makes a (registration) = message
        acceptable to the ultimate recipient of the = registration
        message.  An authorization-enabling extension = MUST contain
        an SPI.
        In this document, all uses of = authorization-enabling
        extension refer to authentication extensions = that enable the
        Registration Request message to be acceptable = to the home
        agent. Using additional protocol structures = specified
        outside of this document, it may be possible = for the mobile
        node to provide authentication of its = registration to the
        home agent, by way of another authenticating = entity within
        the network that is acceptable to the home = agent (for
        example, see RFC 2794 [6])."

2.      = While RFC3012 introduced MN-AAA authentication extension to offer a = mechanism to authenticate the Mobile Node to the visited Foreign Agent, = as it is clearly obvious in the Abstract, Introduction, and section 3.1 = ""3.1. Mobile Node Processing for Registration = Requests".

AND since the ultimate recipient of the Registration Request is always the = Home Agent, MN-AAA authentication extension does not comply with the definition of the = Authorization-enabling extension offered in RFC3220.

    1.      This = will resolve the conflict and allows the Mobile Node to always include = the MN-HA Authentication extension (Authorization-enabling) and MN-AAA = authentication extension (not = an authorization-enabling).

    2.      =       When FA process the Registration Request = received from the Mobile Node, it is optional for the FA to forward the = MN-AAA authentication extension or remove it as per RFC3012 section = 3.2.

        "The Foreign Agent = MUST NOT remove the MN-AAA = Authentication Extension
   =      from the Registration Request prior to the = completion of the
   =      authentication performed by the AAA = infrastructure.  The appendix
   =      provides an example of an action that could be = taken by a foreign
   =      agent."

    3.      Then = HA always receives a MN-HA Authentication extension and optionally = MN-AAA authentication extension in every Registration Request. HA may = use AAA to get the shared secret key for authenticating the RRQ message = using MN-HA Authentication extension or use the MN-AAA authentication = extension through the AAA infrastructure.

Now As per Charlie's = suggestion:

1.      A new cause = code for the MN failing = authentication at the Home Agent using the AAA (MN-AAA authentication = extension) may be needed.

2.      Also, RFC3012bis should be viewed as obsoleting = the word "Exactly" = -- perhaps changing it to a "At least" = in section 3.5.2 of RFC3220.

"3.5.2. Mobile-Home Authentication Extension
Exactly At least one authorization-enabling extension MUST be present in all
Registration Requests, and = also in all Registration Replies generated
by the Home = Agent."

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++

Thanks for your consideration.


Regards;

Ahmad = Muhanna

------_=_NextPart_001_01C1CEB9.8446F940-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 03:18:20 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 DAA17110 for ; Tue, 19 Mar 2002 03:18:20 -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 BAA28123; Tue, 19 Mar 2002 01:17: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 AAA23846; Tue, 19 Mar 2002 00:17: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 g2J8GVKL013028 for ; Tue, 19 Mar 2002 00:16:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J8GUEE013027 for mobile-ip-dist; Tue, 19 Mar 2002 00:16: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 g2J8GQKL013020 for ; Tue, 19 Mar 2002 00:16: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 AAA21518 for ; Tue, 19 Mar 2002 00:15:52 -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 BAA15776 for ; Tue, 19 Mar 2002 01:15: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 AAA25978 for ; Tue, 19 Mar 2002 00:15:51 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2J8Fos14442 for ; Tue, 19 Mar 2002 00:15:50 -0800 X-mProtect:  Tue, 19 Mar 2002 00:15:50 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.193.185, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsX0Iww; Tue, 19 Mar 2002 00:15:47 PST Message-ID: <3C96F349.3010909@iprg.nokia.com> Date: Tue, 19 Mar 2002 00:14:01 -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] Consensus to include recent piggybacking proposal ? 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 Karen E Nielsen (TED) wrote: > Conceptually though, one aspect of the problem still stands in the sense > that by allowing the optional implementation of MIPv6 Control Messages in extension headers then they (MIPv6 control messages) cannot in general be protected by IPSEC policies > set-up by the network (for some reason unknown to the user) over certain un-trusted links. True. But as I said in an earlier mail, protection for Mobility Header is end-to-end. I dont like an intermediate security gateway applying some IPSec policy to the Mobility Header. Cant think of any scenario where it would be useful. Vijay > > Karen > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 03:42: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 DAA17603 for ; Tue, 19 Mar 2002 03:42: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 AAA24250; Tue, 19 Mar 2002 00:40:56 -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 AAA22540; Tue, 19 Mar 2002 00:40: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 g2J8cGKL013136 for ; Tue, 19 Mar 2002 00:38:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J8cFSA013135 for mobile-ip-dist; Tue, 19 Mar 2002 00:38: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 g2J8cCKL013128 for ; Tue, 19 Mar 2002 00:38: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 AAA26366 for ; Tue, 19 Mar 2002 00:37:53 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA22593 for ; Tue, 19 Mar 2002 01:37:51 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id KAA00875; Tue, 19 Mar 2002 10:37:49 +0200 Date: Tue, 19 Mar 2002 10:37:49 +0200 Message-Id: <200203190837.KAA00875@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: <3C96F349.3010909@iprg.nokia.com> (message from Vijay Devarapalli on Tue, 19 Mar 2002 00:14:01 -0800) Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal ? References: <3C96F349.3010909@iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 7.106) 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: > True. But as I said in an earlier mail, protection for Mobility Header > is end-to-end. I dont like an intermediate security gateway applying > some IPSec policy to the Mobility Header. Cant think of any scenario > where it would be useful. Still, even if IPSEC and MIP6 are implemented on same host, it is bad design if they have to be aware of each other. I still propose the following solution 1) no new protocol numbers are assigned/requested 2) MIP6 information is passed in Destination options pretty much as original RFC/(or Draft?) specified 3) if MIP6 wants a specific IPSEC protection, then it does not piggyback existing streams, but instead "piggybacks" it's own generated UDP packets with a port that is designated for the purpose. (This is about the only difference to the original drafts: use UDP instead of "No Next Header") Seems pretty simple and clean to me. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 06:03: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 GAA19294 for ; Tue, 19 Mar 2002 06:03: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 EAA21079; Tue, 19 Mar 2002 04:02: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 DAA19484; Tue, 19 Mar 2002 03:02: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 g2JB1aKL013374 for ; Tue, 19 Mar 2002 03:01:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JB1a9C013373 for mobile-ip-dist; Tue, 19 Mar 2002 03:01: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 g2JB1XKL013366 for ; Tue, 19 Mar 2002 03:01: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 DAA19339 for ; Tue, 19 Mar 2002 03:01:33 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09987 for ; Tue, 19 Mar 2002 03:01:32 -0800 (PST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2JB1QUw003853; Tue, 19 Mar 2002 12:01:31 +0100 (MET) Received: from research-gs4iel.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id MAA27612; Tue, 19 Mar 2002 12:01:26 +0100 Message-Id: <5.0.0.25.0.20020319115606.023cf5e8@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 19 Mar 2002 12:01:19 +0100 To: mobile-ip@sunroof.eng.sun.com, From: Annika Jonsson Subject: Re: [mobile-ip] IPv4 regional registration Cc: "Nik Van den Wijngaert" In-Reply-To: <000301c1ce86$4b1c4d10$4301a98f@pcinf15> 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 Nik, the reason is that section B.2 deals with home registrations, where the Registration Request has to go all the way to the HA, which means that the FA must wait for a Registration Reply from the HA. In section B.3, which deals with Regional Registrations, the FA generates the Registration Reply. /Annika At 15:07 2002-03-18 +0100, Nik Van den Wijngaert wrote: >Hi everybody, > >I'm new to this list, so forgive me if this has been raised before >(although I couldn't find any reference in the archives). > >I'm implementing hierarchical mobile ip (v4), so I'm using the document >"draft-ietf-mobileip-reg-tunnel-06" > >In section B.2 there is a paragraph that states: > >" >The crossover FA will receive both a Registration Request and a Binding >Update for the mobile node. When the crossover FA receives the >Registration Request, it continues to send traffic via the old path >until it receives a valid Registration Reply with a Code indicating >success. Then it starts sending traffic via the new route. " > >But isn't this crossover FA the FA that will generate the registration >reply? I'm confused about the part "...until it receives a valid >registration reply...". > >Maybe I'm missing something obvious here? > > >Thanks, >Nik Van den Wijngaert. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 09:48: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 JAA23207 for ; Tue, 19 Mar 2002 09:48:10 -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 HAA10637; Tue, 19 Mar 2002 07:47: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 GAA03148; Tue, 19 Mar 2002 06:47: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 g2JEjYKL013972 for ; Tue, 19 Mar 2002 06:45:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JEjY5V013971 for mobile-ip-dist; Tue, 19 Mar 2002 06:45: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JEjVKL013964 for ; Tue, 19 Mar 2002 06:45:31 -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 GAA07031 for ; Tue, 19 Mar 2002 06:45:31 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09811 for ; Tue, 19 Mar 2002 07:45:30 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5B92137E0 for ; Tue, 19 Mar 2002 09:44:38 -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 A9005201F; Tue, 19 Mar 2002 08:44:37 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2JEiaR15608; Tue, 19 Mar 2002 09:44:37 -0500 (EST) Received: from compaq.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2JEiab07989; Tue, 19 Mar 2002 09:44:36 -0500 (EST) Message-ID: <3C974ED3.60D00724@compaq.com> Date: Tue, 19 Mar 2002 08:44:35 -0600 From: Vladislav Yasevich X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16-acpi i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.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 I was just looking at this doc and noticed that it's requiring a correspondent node to send Message 3 and 4 of the RR simultaneously. That implies that the correspondent is supposed to wait for both Message 1 and 2 of the RR to arrive (as they are not guaranteed to arive at the same time). Is that intentional? Just looking for a clarification. -vlad Jari Arkko wrote: > > Folks, > > The design team has worked for the last couple of weeks on > updating draft-ietf-mobileip-ipv6-15.txt based on the > discussions on the mailing list, the consensus that > has been reached, and discussions in the team beyond the > major issues present in the recommendations. As you surely > have noticed, we didn't produce a new version before the > Internet Draft deadline. However, we are approaching a > new version soon and intend to submit it next week. > > Even if the current text is not very mature and there are > many serious problems in it, we thought it would be useful > to start reviewing and discussing this. Also, once the basic > message flows and formats are out, it becomes easier to discuss > issues on the mailing list. For this purpose we have provided > an early version for your review: > > http://www.piuha.net/~jarkko/publications/mipv6/mipv6-modified-parts-pre16.pdf > > This file contains only the modified parts in PDF format. > I'll send the full new I-D version in text format as soon > as I get it. > > The modifications have also been listed under Appendix A.1 > on page 61. Please note that this very much work in progress. > The below list gives some of the currently open issues or > parts have not been edited right yet: > > - Need to get IPv6 interface ID bit allocated to be able to prevent > bidding down. > > - Figure out if alternative CoA can work with the RR messaging. > > - Home agent operation, how to secure: use ESP or AH? > > - Max BCE entry lifetime has to be specified somewhere. > > - Use of HAO or not for home registrations. > > - Authentication data, BU, BA exact formats e.g. parameter > vs. fixed field. > > - Should we specify that the correspondent nodes MUST be able to keep > nonces and hence also cookies fresh for at least 60 seconds, in > order to ease retransmission implementation on the mobile node > side? > > - Need suboptions on HAO any more? > > - Securing BRs with authentication data inherited from the BU/BA time? > > - SPI necessary? > > - What to put in the future functionality section on e.g. > unvHAO or piggybacking? > > - Need state tables or better behaviour descriptions in the > cn, mn chapters? > > Comments are very much appreciated. > > Jari Arkko From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 09:57: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 JAA23481 for ; Tue, 19 Mar 2002 09:57:20 -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 GAA18650; Tue, 19 Mar 2002 06:56:31 -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 GAA05616; Tue, 19 Mar 2002 06:55: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 g2JEsfKL014089 for ; Tue, 19 Mar 2002 06:54:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JEsfpG014088 for mobile-ip-dist; Tue, 19 Mar 2002 06:54: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 g2JEsbKL014081 for ; Tue, 19 Mar 2002 06:54:37 -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 GAA05095 for ; Tue, 19 Mar 2002 06:54:38 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13961 for ; Tue, 19 Mar 2002 07:54:37 -0700 (MST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2JEsaW23181; Tue, 19 Mar 2002 09:54:36 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA21013; Tue, 19 Mar 2002 08:54:35 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id IAA05165; Tue, 19 Mar 2002 08:54:35 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15511.20778.951701.104577@nwsgpb.ih.lucent.com> Date: Tue, 19 Mar 2002 08:54:34 -0600 (CST) From: Pete McCann To: mobile-ip@sunroof.eng.sun.com Cc: "'Charles E. Perkins'" Subject: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCAC8@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCAC8@zrc2c013.us.nortel.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.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, Ahmad, I agree with this approach, except for your point 3 below: > 3. Then HA always receives a MN-HA Authentication extension and > optionally MN-AAA authentication extension in every Registration Request. HA > may use AAA to get the shared secret key for authenticating the RRQ message > using MN-HA Authentication extension or use the MN-AAA authentication > extension through the AAA infrastructure. I think there are cases, such as dynamic HA assignment, where the MN doesn't have an association with the HA at first. So, we should allow cases where the MN includes ONLY MN-AAA in the RRQ and it is the basis for authentication at the HA. Also, I would like to clarify the rules for when the FA can strip out the MN-AAA: it can do so after verifying it with a AAA infrastructure, and only if a MN-HA authentication extension was present previously in the RRQ. -Pete Ahmad Muhanna writes: > Hello all; > > This email is quite long and I appreciate it if as many people as possible > have the patience to read through it and post their input. > > I exchanged few emails with Charlie Perkins which led me to post the > following for this mail list. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++ > >From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to share > with all of you the following proposed interpretation to prevent a conflict > between these two RFCs. > > > 1. RFC3220 introduced a new term "Authorization-enabling extension" and > made it restricted that registration request MUST have only one > authorization-enabling extension after renaming the MN-HA Authentication > extension as authorization-enabling extension, as per section 3.5.2: > "3.5.2. Mobile-Home Authentication Extension > Exactly one authorization-enabling extension MUST be present in all > Registration Requests, and also in all Registration Replies > generated > by the Home Agent. The Mobile-Home Authentication Extension is > always an authorization-enabling for registration messages specified > in this document. This requirement is intended to eliminate > problems > [2] which result from the uncontrolled propagation of remote > redirects in the Internet. The location of the extension marks the > end of the authenticated data." > > 2. This made it impossible for Mobile Node to include the MN-HA and > MN-AAA Authentication extensions in the same Registration Request. > 3. However, RFC3012 section 6 mandates Mobile Node to include MN-HA > Authentication extension in every Registration Request message as long as > the Mobile Node has a security association with its Home Agent. (MN MUST > always maintain a security association with all of its home agents, as per > RFC3220 (RFC2002)), > "6. MN-AAA Authentication subtype > "............................................ If the MN-AAA > Authentication > extension is present, then the Registration Message sent by the > mobile node MUST contain the Mobile-HA Authentication extension [8] > if it shares a security association with the Home Agent............" > > 4. Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA > Authentication extension whenever it does not have a security association > with the Foreign Agent, as in section 3.1. > > Since, at least conceptually although it is not referenced any where in the > standard, MN-AAA authentication extension is viewed as an > authorization-enabling extension, this very wide interpretation causes a > real conflict between RFC3220 & RFC3012 (RFC3012bis). Therefore the > following interpretation proposes a solution for this issue: > > 1. Since RFC3220 defines the Authorization-enabling extension as > follows in section 1.6: > > "Authorization-enabling extension > An authentication which makes a (registration) message > acceptable to the ultimate recipient of the registration > message. An authorization-enabling extension MUST contain > an SPI. > In this document, all uses of authorization-enabling > extension refer to authentication extensions that enable the > Registration Request message to be acceptable to the home > agent. Using additional protocol structures specified > outside of this document, it may be possible for the mobile > node to provide authentication of its registration to the > home agent, by way of another authenticating entity within > the network that is acceptable to the home agent (for > example, see RFC 2794 [6])." > > 2. While RFC3012 introduced MN-AAA authentication extension to offer a > mechanism to authenticate the Mobile Node to the visited Foreign Agent, as > it is clearly obvious in the Abstract, Introduction, and section 3.1 ""3.1. > Mobile Node Processing for Registration Requests". > > AND since the ultimate recipient of the Registration Request is always the > Home Agent, MN-AAA authentication extension does not comply with the > definition of the Authorization-enabling extension offered in RFC3220. > > 1. This will resolve the conflict and allows the Mobile Node to > always include the MN-HA Authentication extension (Authorization-enabling) > and MN-AAA authentication extension (not an authorization-enabling). > 2. When FA process the Registration Request received from > the Mobile Node, it is optional for the FA to forward the MN-AAA > authentication extension or remove it as per RFC3012 section 3.2. > "The Foreign Agent MUST NOT remove the MN-AAA Authentication > Extension > from the Registration Request prior to the completion of the > authentication performed by the AAA infrastructure. The appendix > provides an example of an action that could be taken by a foreign > agent." > 3. Then HA always receives a MN-HA Authentication extension and > optionally MN-AAA authentication extension in every Registration Request. HA > may use AAA to get the shared secret key for authenticating the RRQ message > using MN-HA Authentication extension or use the MN-AAA authentication > extension through the AAA infrastructure. > > Now As per Charlie's suggestion: > > 1. A new cause code for the MN failing authentication at the Home Agent > using the AAA (MN-AAA authentication extension) may be needed. > > 2. Also, RFC3012bis should be viewed as obsoleting the word "Exactly" > -- perhaps changing it to a "At least" in section 3.5.2 of RFC3220. > "3.5.2. Mobile-Home Authentication Extension > Exactly At least one authorization-enabling extension MUST be present in all > Registration Requests, and also in all Registration Replies generated > by the Home Agent." > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++ > > Thanks for your consideration. > > > Regards; > > Ahmad Muhanna > > > > > > > A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) > > > >

Hello all; >

> >

This email is quite long and I appreciate it if as many people as possible have the patience to read through it and post their input.

> >

I exchanged few emails with Charlie Perkins which led me to post the following for this mail list. >

> >

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to share with all of you the following proposed interpretation to prevent a conflict between these two RFCs.

>
> >

1.      RFC3220 introduced a new term "Authorization-enabling extension" and made it restricted that registration request MUST have only one authorization-enabling extension after renaming the MN-HA Authentication extension as authorization-enabling extension, as per section 3.5.2:

> >

        "3.5.2. Mobile-Home Authentication Extension >
        Exactly one authorization-enabling extension MUST be present in all >
        Registration Requests, and also in all Registration Replies generated >
        by the Home Agent.  The Mobile-Home Authentication Extension is >
        always an authorization-enabling for registration messages specified >
        in this document.  This requirement is intended to eliminate problems >
        [2] which result from the uncontrolled propagation of remote >
        redirects in the Internet.  The location of the extension marks the >
        end of the authenticated data." >

> >

2.      This made it impossible for Mobile Node to include the MN-HA and MN-AAA Authentication extensions in the same Registration Request.

> >

3.      However, RFC3012 section 6 mandates Mobile Node to include MN-HA Authentication extension in every Registration Request message as long as the Mobile Node has a security association with its Home Agent. (MN MUST always maintain a security association with all of its home agents, as per RFC3220 (RFC2002)),

> >

             "6. MN-AAA Authentication subtype >
        "............................................  If the MN-AAA Authentication >
        extension is present, then the Registration Message sent by the >
        mobile node MUST contain the Mobile-HA Authentication extension [8] >
        if it shares a security association with the Home Agent............" >
4.      Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA Authentication extension whenever it does not have a security association with the Foreign Agent, as in section 3.1.

> >

Since, at least conceptually although it is not referenced any where in the standard, MN-AAA authentication extension is viewed as an authorization-enabling extension, this very wide interpretation causes a real conflict between RFC3220 & RFC3012 (RFC3012bis). Therefore the following interpretation proposes a solution for this issue:

> >

1.      Since RFC3220 defines the Authorization-enabling extension as follows in section 1.6: >

> >

        "Authorization-enabling extension >
        An authentication which makes a (registration) message >
        acceptable to the ultimate recipient of the registration >
        message.  An authorization-enabling extension MUST contain >
        an SPI. >
        In this document, all uses of authorization-enabling >
        extension refer to authentication extensions that enable the >
        Registration Request message to be acceptable to the home >
        agent. Using additional protocol structures specified >
        outside of this document, it may be possible for the mobile >
        node to provide authentication of its registration to the >
        home agent, by way of another authenticating entity within >
        the network that is acceptable to the home agent (for >
        example, see RFC 2794 [6])." >

> >

2.      While RFC3012 introduced MN-AAA authentication extension to offer a mechanism to authenticate the Mobile Node to the visited Foreign Agent, as it is clearly obvious in the Abstract, Introduction, and section 3.1 ""3.1. Mobile Node Processing for Registration Requests".

> >

AND since the ultimate recipient of the Registration Request is always the Home Agent, MN-AAA authentication extension does not comply with the definition of the Authorization-enabling extension offered in RFC3220.

>
    >

    1.      This will resolve the conflict and allows the Mobile Node to always include the MN-HA Authentication extension (Authorization-enabling) and MN-AAA authentication extension (not an authorization-enabling).

    > >

    2.            When FA process the Registration Request received from the Mobile Node, it is optional for the FA to forward the MN-AAA authentication extension or remove it as per RFC3012 section 3.2.

    >
>

        "The Foreign Agent MUST NOT remove the MN-AAA Authentication Extension >
        from the Registration Request prior to the completion of the >
        authentication performed by the AAA infrastructure.  The appendix >
        provides an example of an action that could be taken by a foreign >
        agent." >

    >

    3.      Then HA always receives a MN-HA Authentication extension and optionally MN-AAA authentication extension in every Registration Request. HA may use AAA to get the shared secret key for authenticating the RRQ message using MN-HA Authentication extension or use the MN-AAA authentication extension through the AAA infrastructure.

    >
>

Now As per Charlie's suggestion: >

> >

1.      A new cause code for the MN failing authentication at the Home Agent using the AAA (MN-AAA authentication extension) may be needed.

> >

2.      Also, RFC3012bis should be viewed as obsoleting the word "Exactly" -- perhaps changing it to a "At least" in section 3.5.2 of RFC3220.

> >

"3.5.2. Mobile-Home Authentication Extension >
Exactly At least one authorization-enabling extension MUST be present in all >
Registration Requests, and also in all Registration Replies generated >
by the Home Agent." >

> >

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >

> >

Thanks for your consideration. >

>
> >

Regards; >

> >

Ahmad Muhanna >

> > > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 10:22: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 KAA24183 for ; Tue, 19 Mar 2002 10:22: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 IAA13805; Tue, 19 Mar 2002 08:21: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 HAA09695; Tue, 19 Mar 2002 07: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 g2JFJgKL014308 for ; Tue, 19 Mar 2002 07:19:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JFJge0014307 for mobile-ip-dist; Tue, 19 Mar 2002 07:19: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 g2JFJbKL014300 for ; Tue, 19 Mar 2002 07:19:38 -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 g2JFJax00566 for ; Tue, 19 Mar 2002 16:19:37 +0100 (MET) Date: Tue, 19 Mar 2002 16:19:29 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal ? To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203190837.KAA00875@burp.tkv.asdf.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: > I still propose the following solution > > 1) no new protocol numbers are assigned/requested > > 2) MIP6 information is passed in Destination options pretty much as > original RFC/(or Draft?) specified Markku, This would not allow the RR packets (HoT in particular) to be protected using an IPsec tunnel between the HA and MN. Without this protection any nodes on that path, including anybody on the link the MN is visiting, can send forge BUs for the MN. Using a separate terminal payload type for the RR packets allows doing this as well as using IPsec to protect home registrations. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 10:25: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 KAA24239 for ; Tue, 19 Mar 2002 10:25: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 HAA24759; Tue, 19 Mar 2002 07:25:01 -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 HAA10330; Tue, 19 Mar 2002 07:24: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 g2JFO2KL014403 for ; Tue, 19 Mar 2002 07:24:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JFO2RR014402 for mobile-ip-dist; Tue, 19 Mar 2002 07:24: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 g2JFNwKL014395 for ; Tue, 19 Mar 2002 07:23:59 -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 g2JFNsx00791; Tue, 19 Mar 2002 16:23:55 +0100 (MET) Date: Tue, 19 Mar 2002 16:23:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] MIPv6 Internet Draft To: Vladislav.Yasevich@compaq.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C974ED3.60D00724@compaq.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 was just looking at this doc and noticed that it's requiring > a correspondent node to send Message 3 and 4 of the RR simultaneously. > That implies that the correspondent is supposed to wait for both > Message 1 and 2 of the RR to arrive (as they are not guaranteed to > arive at the same time). Is that intentional? Vladislav, That isn't the intent so it seems like a clarification is needed. The CN responds to the CoTI with a CoT and the HoTI with a HoT independently (and without creating any state). The MN then needs to wait for both the CoT and HoT before it has the cookies necessary to send the BU. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 10:26: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 KAA24264 for ; Tue, 19 Mar 2002 10:26:14 -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 IAA29457; Tue, 19 Mar 2002 08:25: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 HAA10438; Tue, 19 Mar 2002 07:25: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 g2JFOmKL014420 for ; Tue, 19 Mar 2002 07:24:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JFOmiq014419 for mobile-ip-dist; Tue, 19 Mar 2002 07:24: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 g2JFOjKL014412 for ; Tue, 19 Mar 2002 07:24: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 HAA10279 for ; Tue, 19 Mar 2002 07:24:45 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28713 for ; Tue, 19 Mar 2002 08:24:44 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA01182; Tue, 19 Mar 2002 17:24:43 +0200 Date: Tue, 19 Mar 2002 17:24:43 +0200 Message-Id: <200203191524.RAA01182@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: (message from Erik Nordmark on Tue, 19 Mar 2002 16:19:29 +0100 (CET)) Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal ? References: Mime-Version: 1.0 (generated by tm-edit 7.106) 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: > Using a separate terminal payload type for the RR packets allows doing this > as well as using IPsec to protect home registrations. You left out my final point. This is the "separate terminal payload": 3) if MIP6 wants a specific IPSEC protection, then it does not piggyback existing streams, but instead "piggybacks" it's own generated UDP packets with a port that is designated for the purpose. (This is about the only difference to the original drafts: use UDP instead of "No Next Header") This is *FINAL* header, header such is needed. IPSEC can latch on the selected well known port. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 10:33: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 KAA24430 for ; Tue, 19 Mar 2002 10:33:30 -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 IAA28889; Tue, 19 Mar 2002 08:32: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 HAA11809; Tue, 19 Mar 2002 07: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 g2JFVNKL014630 for ; Tue, 19 Mar 2002 07:31:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JFVNbb014629 for mobile-ip-dist; Tue, 19 Mar 2002 07:31: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 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 g2JFVJKL014622 for ; Tue, 19 Mar 2002 07:31:19 -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 g2JFVGx02067; Tue, 19 Mar 2002 16:31:16 +0100 (MET) Date: Tue, 19 Mar 2002 16:31:09 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal ? To: msa@burp.tkv.asdf.org Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203191524.RAA01182@burp.tkv.asdf.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: > > Using a separate terminal payload type for the RR packets allows doing this > > as well as using IPsec to protect home registrations. > > You left out my final point. This is the "separate terminal payload": > > 3) if MIP6 wants a specific IPSEC protection, then it does not > piggyback existing streams, but instead "piggybacks" it's own > generated UDP packets with a port that is designated for the > purpose. (This is about the only difference to the original drafts: > use UDP instead of "No Next Header") > > This is *FINAL* header, header such is needed. IPSEC can latch on the > selected well known port. I think this means that at least HoT always need to be carried in UDP and also that BU/BAck used for home registrations need to be carried in UDP. It would seem complex to be able to handle the same messages (BU/BAck) carried both in UDP and in DO. What would we gain from this? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 10:34: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 KAA24454 for ; Tue, 19 Mar 2002 10:34:06 -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 IAA29439; Tue, 19 Mar 2002 08: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 HAA12039; Tue, 19 Mar 2002 07: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 g2JFWXKL014647 for ; Tue, 19 Mar 2002 07:32:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JFWXRw014646 for mobile-ip-dist; Tue, 19 Mar 2002 07:32: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 g2JFWUKL014639 for ; Tue, 19 Mar 2002 07:32:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11822 for ; Tue, 19 Mar 2002 07:32:31 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21006 for ; Tue, 19 Mar 2002 07:32:26 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA01217; Tue, 19 Mar 2002 17:32:26 +0200 Date: Tue, 19 Mar 2002 17:32:26 +0200 Message-Id: <200203191532.RAA01217@burp.tkv.asdf.org> From: Markku Savela To: Erik.Nordmark@eng.sun.com CC: mobile-ip@sunroof.eng.sun.com In-reply-to: (message from Erik Nordmark on Tue, 19 Mar 2002 16:31:09 +0100 (CET)) Subject: Re: [mobile-ip] Consensus to include recent piggybacking proposal ? References: Mime-Version: 1.0 (generated by tm-edit 7.106) 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 would seem complex to be able to handle the same messages (BU/BAck) carried > both in UDP and in DO. What would we gain from this? No, UDP payload would be empty. It's always DO. Thats the beauty of it. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 12:10: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 MAA27559 for ; Tue, 19 Mar 2002 12:10:39 -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 KAA10839; Tue, 19 Mar 2002 10:09: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 JAA15246; Tue, 19 Mar 2002 09: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 g2JH8rKL015307 for ; Tue, 19 Mar 2002 09:08:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JH8raO015306 for mobile-ip-dist; Tue, 19 Mar 2002 09:08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JH8oKL015299 for ; Tue, 19 Mar 2002 09:08:50 -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 JAA15035 for ; Tue, 19 Mar 2002 09:08:52 -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 KAA24972 for ; Tue, 19 Mar 2002 10:08:50 -0700 (MST) Received: from fredrikj (hotel-33.local.ipunplugged.com [192.168.8.33]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA09404; Tue, 19 Mar 2002 18:06:08 +0100 From: "Fredrik Johansson" To: , "Phil Roberts" , "Charlie Perkins" Subject: RE: [mobile-ip] AAA keys security review Date: Tue, 19 Mar 2002 18:09:08 +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: <3C8F8B86.F7942BB8@iprg.nokia.com> 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 Charlie, Here's my suggestion for text describing the nature of the Mn<->AAA security association. Mobile Node - AAA Security Association The security association shared between the Mobile Node and the AAA home server is used for mutual authentication. It is also used when deriving Mobility Security Associations from the key material distributed via the AAA and Mobile IP protocols. The Security Association consists of at least one (potentially more) Security Context. Each Security Context is uniquley identified by a SPI, and consits of an algorithm identifier, a key, and a lifetime. Distribution of the Security Association is outside the scope of this document, one example is that it can be manually configured. When deriving Mobility Security Associations one calculates a value for the key using the algorithm and key pointed to by the AAA SPI in the key distribution extension toghether with the received key material. The calculated key is then stored in the new Mobility Security Context toghether with the other necessary data recieved in the key distribution extension. /Fredrik >-----Original Message----- >From: owner-mobile-ip@sunroof.eng.sun.com >[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Charles E. >Perkins >Sent: den 13 mars 2002 18:25 >To: Phil Roberts; Pat R. Calhoun >Cc: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] AAA keys security review > > >Hello Phil, > >The relevant material from gen-key has been merged into version ...-09 >I can carry out the other two recommendations in a newly revised >draft produced after the upcoming IETF. However, I should think that >these are relatively small things, and should not require a new >working group last call. In other words, either version ...-09 or >the newly revised document could conceivably go directly for IESG >consideration. > >I can describe the nature of the (mobile node<-->AAA) security >association, but I would appreciate any help that someone might >offer (including, as always, actual text). > >What do you think? > >Regards, >Charlie P. > > > >Phil Roberts wrote: >> >> Hi folks, >> >> I asked Luis Sanchez (chair of ipsp WG) to review this doc >for us and he >> did. We're very >> grateful. Here's the note he sent with his review embedded. >Please note, >> this was done on >> version -08 before Charlie produced version -09. >> >> Phil >> ------------------------------ >> >> Hi Phil, >> >> Enclose you will find a security review of >> draft-ietf-mobileip-aaa-key-08.txt. The findings have input from the >> following individuals listed in alphabetical order: >> >> - S. Bitan >> - S. Kent >> - H. Orman >> >> Any mistakes are solely mine. Thanks! >> >> Luis >> >> ------------------------------------------- >> >> General Observation: Overall the document is in reasonable shape. I >> would merge this document with draft-ietf-mobileip-gen-key-01.txt. The >> document should however, undergo editorial review. One major concern is >> the lack of a succinct security goal statement. Such statement would be >> beneficial to the reader and would avoid confusion "why isn't this >> protected, why is this protected, should this be protected, etc." >> >> In the IPsec context, security associations are simplex and uniquely >> identified by the triple (IP address, SPI, protocol). It is not clear if >> there is a 1to1 mapping between IPsec security associations and the >> "security associations" between mobile nodes and AAA servers. Perhaps >> this is discussed in some other document. >> >> **Recommendation: Add text to explain the nature of the AAA server to >> Mobile Node security association. >> >> - The mobile node calculates a key by hashing a concatenation of bits >> that include the AAA-key. How does the mobile get this key? Does it >> arrive on the wire? If it arrives on the wire it better be encrypted as >> a result of using yet some other protocol exchange to provide: peer >> authentication, data integrity and confidentiality. Are we assuming a >> security association using IKE between the MN and its home AAA server >> and that is how this AAA-key is generated? Otherwise, if pre-configured >> (manually? )how is this different from pre-configuring an MN-HA key. I >> might be asking the obvious here by not understanding the protocol >> exchanges. >> >> **Recommendation: Add text to explain how the AAA-Key is generated and >> configured in the MN and other peers. >> >> - For key derivation, the document recommends using one of the >> algorithms listed in the following table >> >> Algorithm Identifier Name Reference >> --------------------- ------------------ ------------ >> 1 MD5/prefix+suffix RFC 2002 [11] >> 2 HMAC MD5 RFC 2104 [6] >> 3 SHA-1 FIPS 180-1 [10] >> >> Back in 1996 Bellare, Canetti and Krawczyk published a paper on crypto >> discussing how a keyed hash function used in append/pre-append mode is >> more susceptible to the "divide and conquer" attack, although >> impractical, than a keyed-hashed function using a keyed-IV instead. They >> also proved that cryptographically HMAC is as strong as the hash >> function used with it. One can no make such a statement of a keyed-hash >> function used in prefix+suffix mode. As such, IPsec dropped RFC1828 and >> adopted HMAC-MD5 and HMAC-SHA1 the latter one truncated to 90bits. >> Another potential problem with MD5/prefix+suffix could come in if the >> nonsecret component of the key is variable length. In that case, if you >> were using MD5(secret, nonsecret) = newkey, then someone might be able >> to see newkey and later observe an exchange where nonsecret' = >> nonsecret|1. Then the key would be MD5(newkey, 1) = newkey'. You have >> to analyze the protocol very carefully to assure that this doesn't >> happen, but if you use HMAC, you don't have to worry about it. >> >> **Recommendation: Advise reader to derive keys using: key = >> HMAC-MD5(AAA-key, {Key Material | node-addres}) >> >> or HMAC-SHA1. Do not recommend using MD5/prefix+suffix or just SHA-1. >> >> - The AAA key need to be chosen at random (or using a cryptographically >> strong pseudo-random generator seeded with a random seed), and >> periodically refreshed. The document makes reference to RFC1750 and >> this is appropriate however, it does not mention refreshing. It is not >> clear that we can recommended a specific frequency for key changes as >> the attacks refered to above may seem practically infeasible. However, >> periodic key refreshment is a fundamental security practice that helps >> against potential weaknesses of the function and keys, and limits the >> damage of an exposed key. >> >> **Recommendation: Add a statement to indicate that both the Mobile Node >> and the AAA server MUST refresh their shared AAA-key. This could be done >> via the AAA protocol or some other out-of-band mechanism. For in-band >> refreshing the new key MUST be encrypted, authenticated and its >> integrity MUST be protected while on transit. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 13:02:23 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 NAA29149 for ; Tue, 19 Mar 2002 13:02:22 -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 LAA11104; Tue, 19 Mar 2002 11:01:48 -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 KAA24374; Tue, 19 Mar 2002 10:01: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 g2JI0YKL015528 for ; Tue, 19 Mar 2002 10:00:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JI0YRV015527 for mobile-ip-dist; Tue, 19 Mar 2002 10:00: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JI0VKL015520 for ; Tue, 19 Mar 2002 10:00:31 -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 KAA23642 for ; Tue, 19 Mar 2002 10:00:33 -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 LAA21470 for ; Tue, 19 Mar 2002 11:00: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 g2JI0Tu08436; Tue, 19 Mar 2002 12:00:30 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 12:00:30 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCAD3@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Charles E. Perkins'" , "'Pete McCann'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Tue, 19 Mar 2002 12:00:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CF6F.F19C0CE0" Sender: owner-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_01C1CF6F.F19C0CE0 Content-Type: text/plain; charset="iso-8859-1" Hi Pete; I thought that I sent this message but it seems that it did not go through. Well, I would like to agree with you, However, the following points make it very difficult: I. RFC3220 (RFC2002): It is mandatory for the Mobile Node to have a security association with all of its Home Agents as per section 3.6. "3.6. Mobile Node Considerations A mobile node MUST be configured with a netmask and a mobility security association for each of its home agents. ..... " 2. RFC3012: It is mandatory that MN must include the MN-HA authentication extension in every RRQ message as long as the mobile Node shares a security association with its home agent, as per section 6. below. Now, in my opinion, anything else needs to change the existing standard including RFC3220, which mandates the MN to maintain a security association with its Home Agents. However, in the case of dynamically allocated Home Agent: As per RFC3220, the MN must have a security association with its home agents. This means that the MN MUST have this security association before sending any RRQ messages. I think the best approach without introducing any serious conflicts and changes in the standard may be the following: 1. MN MUST maintain at all times a security association with all of its home agents or HOME DOMAIN. 2. I assume that Dynamically allocated HA is one which belongs to the MN Home Domain. 3. If the Dynamically allocated HA does not have the security parameters available for this MN, it MUST inquire it (ex. AAA infrastructure) to get the needed security parameters to be able to authenticate the MN. 4. IF the HA or Home Domain needs to update (for example) the shared secret key with the MN, it always can be done after the initial RRQ with the last (configured or updated) security parameters the MN shares with its Home Agents (Home Domain). Thanks for consideration. Regards; Ahmad Muhanna -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Tuesday, March 19, 2002 8:55 AM To: mobile-ip@sunroof.eng.sun.com Cc: 'Charles E. Perkins' Subject: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Hi, Ahmad, I agree with this approach, except for your point 3 below: > 3. Then HA always receives a MN-HA Authentication extension and > optionally MN-AAA authentication extension in every Registration Request. HA > may use AAA to get the shared secret key for authenticating the RRQ message > using MN-HA Authentication extension or use the MN-AAA authentication > extension through the AAA infrastructure. I think there are cases, such as dynamic HA assignment, where the MN doesn't have an association with the HA at first. So, we should allow cases where the MN includes ONLY MN-AAA in the RRQ and it is the basis for authentication at the HA. Also, I would like to clarify the rules for when the FA can strip out the MN-AAA: it can do so after verifying it with a AAA infrastructure, and only if a MN-HA authentication extension was present previously in the RRQ. -Pete Ahmad Muhanna writes: > Hello all; > > This email is quite long and I appreciate it if as many people as possible > have the patience to read through it and post their input. > > I exchanged few emails with Charlie Perkins which led me to post the > following for this mail list. > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++ > >From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to share > with all of you the following proposed interpretation to prevent a conflict > between these two RFCs. > > > 1. RFC3220 introduced a new term "Authorization-enabling extension" and > made it restricted that registration request MUST have only one > authorization-enabling extension after renaming the MN-HA Authentication > extension as authorization-enabling extension, as per section 3.5.2: > "3.5.2. Mobile-Home Authentication Extension > Exactly one authorization-enabling extension MUST be present in all > Registration Requests, and also in all Registration Replies > generated > by the Home Agent. The Mobile-Home Authentication Extension is > always an authorization-enabling for registration messages specified > in this document. This requirement is intended to eliminate > problems > [2] which result from the uncontrolled propagation of remote > redirects in the Internet. The location of the extension marks the > end of the authenticated data." > > 2. This made it impossible for Mobile Node to include the MN-HA and > MN-AAA Authentication extensions in the same Registration Request. > 3. However, RFC3012 section 6 mandates Mobile Node to include MN-HA > Authentication extension in every Registration Request message as long as > the Mobile Node has a security association with its Home Agent. (MN MUST > always maintain a security association with all of its home agents, as per > RFC3220 (RFC2002)), > "6. MN-AAA Authentication subtype > "............................................ If the MN-AAA > Authentication > extension is present, then the Registration Message sent by the > mobile node MUST contain the Mobile-HA Authentication extension [8] > if it shares a security association with the Home Agent............" > > 4. Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA > Authentication extension whenever it does not have a security association > with the Foreign Agent, as in section 3.1. > > Since, at least conceptually although it is not referenced any where in the > standard, MN-AAA authentication extension is viewed as an > authorization-enabling extension, this very wide interpretation causes a > real conflict between RFC3220 & RFC3012 (RFC3012bis). Therefore the > following interpretation proposes a solution for this issue: > > 1. Since RFC3220 defines the Authorization-enabling extension as > follows in section 1.6: > > "Authorization-enabling extension > An authentication which makes a (registration) message > acceptable to the ultimate recipient of the registration > message. An authorization-enabling extension MUST contain > an SPI. > In this document, all uses of authorization-enabling > extension refer to authentication extensions that enable the > Registration Request message to be acceptable to the home > agent. Using additional protocol structures specified > outside of this document, it may be possible for the mobile > node to provide authentication of its registration to the > home agent, by way of another authenticating entity within > the network that is acceptable to the home agent (for > example, see RFC 2794 [6])." > > 2. While RFC3012 introduced MN-AAA authentication extension to offer a > mechanism to authenticate the Mobile Node to the visited Foreign Agent, as > it is clearly obvious in the Abstract, Introduction, and section 3.1 ""3.1. > Mobile Node Processing for Registration Requests". > > AND since the ultimate recipient of the Registration Request is always the > Home Agent, MN-AAA authentication extension does not comply with the > definition of the Authorization-enabling extension offered in RFC3220. > > 1. This will resolve the conflict and allows the Mobile Node to > always include the MN-HA Authentication extension (Authorization-enabling) > and MN-AAA authentication extension (not an authorization-enabling). > 2. When FA process the Registration Request received from > the Mobile Node, it is optional for the FA to forward the MN-AAA > authentication extension or remove it as per RFC3012 section 3.2. > "The Foreign Agent MUST NOT remove the MN-AAA Authentication > Extension > from the Registration Request prior to the completion of the > authentication performed by the AAA infrastructure. The appendix > provides an example of an action that could be taken by a foreign > agent." > 3. Then HA always receives a MN-HA Authentication extension and > optionally MN-AAA authentication extension in every Registration Request. HA > may use AAA to get the shared secret key for authenticating the RRQ message > using MN-HA Authentication extension or use the MN-AAA authentication > extension through the AAA infrastructure. > > Now As per Charlie's suggestion: > > 1. A new cause code for the MN failing authentication at the Home Agent > using the AAA (MN-AAA authentication extension) may be needed. > > 2. Also, RFC3012bis should be viewed as obsoleting the word "Exactly" > -- perhaps changing it to a "At least" in section 3.5.2 of RFC3220. > "3.5.2. Mobile-Home Authentication Extension > Exactly At least one authorization-enabling extension MUST be present in all > Registration Requests, and also in all Registration Replies generated > by the Home Agent." > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++ > > Thanks for your consideration. > > > Regards; > > Ahmad Muhanna > ------_=_NextPart_001_01C1CF6F.F19C0CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A proposal for resolving a very Possible = conflict between RFC3220 & RFC3012 (RFC3012bis)

Hi Pete;
I thought that I sent this message but it seems that = it did not go through.

Well, I would like to agree with you, However, the = following points make it very difficult:

I.      RFC3220 = (RFC2002):
        It is = mandatory for the Mobile Node to have a security association with all = of its Home Agents as per
        section = 3.6.

        "3.6. = Mobile Node Considerations

         A mobile = node MUST be configured with a netmask and a mobility
        security = association for each of its home agents.
        .....
        "      
2.      RFC3012:
        It is = mandatory that MN must include the MN-HA authentication extension in = every RRQ message as long as the mobile      Node = shares a security association with its home agent, as per section 6. = below.

Now, in my opinion, anything else needs to change the = existing standard including RFC3220, which mandates the MN to maintain = a security association with its Home Agents.

However, in the case of dynamically allocated Home = Agent:
As per RFC3220, the MN must have a security = association with its home agents.
This means that the MN MUST have this security = association before sending any RRQ messages.

I think the best approach without introducing any = serious conflicts and changes in the standard may be the = following:
1.      MN MUST maintain at = all times a security association with all of its home agents or HOME = DOMAIN.
2.      I assume that = Dynamically allocated HA is one which belongs to the MN Home = Domain.
3.      If the Dynamically = allocated HA does not have the security parameters available for this = MN, it MUST inquire it

        (ex. AAA = infrastructure) to get the needed security parameters to be able to = authenticate the MN.
4.      IF the HA or Home = Domain needs to update (for example) the shared secret key with the MN, = it always can be done after   the initial RRQ with the last = (configured or updated) security parameters the MN shares with its Home = Agents

        (Home = Domain).

Thanks for consideration.
Regards;

Ahmad Muhanna

-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Tuesday, March 19, 2002 8:55 AM
To: mobile-ip@sunroof.eng.sun.com
Cc: 'Charles E. Perkins'
Subject: [mobile-ip] A proposal for resolving a very = Possible conflict
between RFC3220 & RFC3012 (RFC3012bis)


Hi, Ahmad,

I agree with this approach, except for your point 3 = below:

 >      = 3.      Then HA always receives a MN-HA = Authentication extension and
 > optionally MN-AAA authentication = extension in every Registration Request. HA
 > may use AAA to get the shared secret key = for authenticating the RRQ message
 > using MN-HA Authentication extension or = use the MN-AAA authentication
 > extension through the AAA = infrastructure.

I think there are cases, such as dynamic HA = assignment, where the MN
doesn't have an association with the HA at = first.  So, we should allow
cases where the MN includes ONLY MN-AAA in the RRQ = and it is the basis
for authentication at the HA.

Also, I would like to clarify the rules for when the = FA can strip out
the MN-AAA: it can do so after verifying it with a = AAA infrastructure,
and only if a MN-HA authentication extension was = present previously in
the RRQ.

-Pete

Ahmad Muhanna writes:
 > Hello all;
 >
 > This email is quite long and I appreciate = it if as many people as possible
 > have the patience to read through it and = post their input.
 >
 > I exchanged few emails with Charlie = Perkins which led me to post the
 > following for this mail list.
 >
 > = ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++
 > ++++++++
 > >From my reading of RFC3220 and = RFC3012 (RFC3102-bis), I would like to share
 > with all of you the following proposed = interpretation to prevent a conflict
 > between these two RFCs.
 >
 >
 > 1.   RFC3220 introduced a new = term "Authorization-enabling extension" and
 > made it restricted that registration = request MUST have only one
 > authorization-enabling extension after = renaming the MN-HA Authentication
 > extension as authorization-enabling = extension, as per section 3.5.2:
 >      "3.5.2. = Mobile-Home Authentication Extension
 >      Exactly one = authorization-enabling extension MUST be present in all
 >      Registration = Requests, and also in all Registration Replies
 > generated
 >      by the Home = Agent.  The Mobile-Home Authentication Extension is
 >      always an = authorization-enabling for registration messages specified
 >      in this document.=   This requirement is intended to eliminate
 > problems
 >      [2] which result = from the uncontrolled propagation of remote
 >      redirects in the = Internet.  The location of the extension marks the
 >      end of the = authenticated data."
 >
 > 2.   This made it impossible = for Mobile Node to include the MN-HA and
 > MN-AAA Authentication extensions in the = same Registration Request.
 > 3.   However, RFC3012 section 6 = mandates Mobile Node to include MN-HA
 > Authentication extension in every = Registration Request message as long as
 > the Mobile Node has a security = association with its Home Agent. (MN MUST
 > always maintain a security association = with all of its home agents, as per
 > RFC3220 (RFC2002)),
 >         = ;     "6. MN-AAA Authentication subtype
 >      = "............................................  If the = MN-AAA
 > Authentication
 >      extension is = present, then the Registration Message sent by the
 >      mobile node MUST = contain the Mobile-HA Authentication extension [8]
 >      if it shares a = security association with the Home Agent............"
 >
 > 4.   Also, RFC3012, mandates = that the Mobile Node MUST include MN-AAA
 > Authentication extension whenever it does = not have a security association
 > with the Foreign Agent, as in section = 3.1.
 >
 > Since, at least conceptually although it = is not referenced any where in the
 > standard, MN-AAA authentication extension = is viewed as an
 > authorization-enabling extension, this = very wide interpretation causes a
 > real conflict between RFC3220 & = RFC3012 (RFC3012bis). Therefore the
 > following interpretation proposes a = solution for this issue:
 >
 > 1.   Since RFC3220 defines the = Authorization-enabling extension as
 > follows in section 1.6:
 >
 >      = "Authorization-enabling extension
 >      An = authentication which makes a (registration) message
 >      acceptable to = the ultimate recipient of the registration
 >      message.  = An authorization-enabling extension MUST contain
 >      an SPI.
 >      In this = document, all uses of authorization-enabling
 >      extension refer = to authentication extensions that enable the
 >      Registration = Request message to be acceptable to the home
 >      agent. Using = additional protocol structures specified
 >      outside of this = document, it may be possible for the mobile
 >      node to provide = authentication of its registration to the
 >      home agent, by = way of another authenticating entity within
 >      the network that = is acceptable to the home agent (for
 >      example, see RFC = 2794 [6])."
 >
 > 2.   While RFC3012 introduced = MN-AAA authentication extension to offer a
 > mechanism to authenticate the Mobile Node = to the visited Foreign Agent, as
 > it is clearly obvious in the Abstract, = Introduction, and section 3.1 ""3.1.
 > Mobile Node Processing for Registration = Requests".
 >
 > AND since the ultimate recipient of the = Registration Request is always the
 > Home Agent, MN-AAA authentication = extension does not comply with the
 > definition of the Authorization-enabling = extension offered in RFC3220.
 >
 >      = 1.      This will resolve the conflict and = allows the Mobile Node to
 > always include the MN-HA Authentication = extension (Authorization-enabling)
 > and MN-AAA authentication extension (not = an authorization-enabling).
 >      = 2.            When FA = process the Registration Request received from
 > the Mobile Node, it is optional for the = FA to forward the MN-AAA
 > authentication extension or remove it as = per RFC3012 section 3.2.
 >      "The = Foreign Agent MUST NOT remove the MN-AAA Authentication
 > Extension
 >      from the = Registration Request prior to the completion of the
 >      authentication = performed by the AAA infrastructure.  The appendix
 >      provides an = example of an action that could be taken by a foreign
 >      = agent."
 >      = 3.      Then HA always receives a MN-HA = Authentication extension and
 > optionally MN-AAA authentication = extension in every Registration Request. HA
 > may use AAA to get the shared secret key = for authenticating the RRQ message
 > using MN-HA Authentication extension or = use the MN-AAA authentication
 > extension through the AAA = infrastructure.
 >
 > Now As per Charlie's suggestion:
 >
 > 1.   A new cause code for the = MN failing authentication at the Home Agent
 > using the AAA (MN-AAA authentication = extension) may be needed.
 >
 > 2.   Also, RFC3012bis should be = viewed as obsoleting the word "Exactly"
 > -- perhaps changing it to a "At = least" in section 3.5.2 of RFC3220.
 > "3.5.2. Mobile-Home Authentication = Extension
 > Exactly At least one = authorization-enabling extension MUST be present in all
 > Registration Requests, and also in all = Registration Replies generated
 > by the Home Agent."
 >
 > = ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++
 > +++++++++
 >
 > Thanks for your consideration.
 >
 >
 > Regards;
 >
 > Ahmad Muhanna
 >

------_=_NextPart_001_01C1CF6F.F19C0CE0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 17:50: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 RAA06971 for ; Tue, 19 Mar 2002 17:50:21 -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 OAA05587; Tue, 19 Mar 2002 14:49:36 -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 OAA26157; Tue, 19 Mar 2002 14:49: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 g2JMmYKL016538 for ; Tue, 19 Mar 2002 14:48:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JMmY4u016537 for mobile-ip-dist; Tue, 19 Mar 2002 14:48: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JMmVKL016530 for ; Tue, 19 Mar 2002 14:48:31 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20564 for ; Tue, 19 Mar 2002 14:48:33 -0800 (PST) From: mroe_mobileip@hushmail.com Received: from smtp3.hushmail.com (smtp3.hushmail.com [64.40.111.33]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01091 for ; Tue, 19 Mar 2002 14:48:35 -0800 (PST) Received: from mailserver4.hushmail.com (mailserver4.hushmail.com [64.40.111.27]) by smtp3.hushmail.com (Postfix) with ESMTP id BE00BF036 for ; Tue, 19 Mar 2002 15:44:44 -0800 (PST) Received: (from nobody@localhost) by mailserver4.hushmail.com (8.11.6/8.11.3) id g2JMfoh75349; Tue, 19 Mar 2002 14:41:50 -0800 (PST) (envelope-from mroe_mobileip@hushmail.com) Message-Id: <200203192241.g2JMfoh75349@mailserver4.hushmail.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: MIPv6 Internet Draft Date: Tue, 19 Mar 2002 14:41:50 -0800 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I argee with most of the things that the design team have done in mipv6-modified-parts-pre16, but I noticed a few technical issues that ought to be fixed, plus a bunch of typos: Technical Comments ================== 4.5.5, step 5 We need to be able to support alternative methods for calculating K_BU (e.g. CGA schemes, manually configured keys, IPSEC ...). This document does not need to specify the details of these alternative mechanisms, but it does need to say two things: (a) It needs to say that there might exist alternative schemes that have most of their protocol steps in common with the protocol described in this document, but have a different step 5. (b) It needs to describe how a CN node knows that this particular scheme (RR) is being used, rather than one of the others that have a different step 5. The obvious way to do this is to have a field in the BU that indicates which crypto scheme is being used. This needs to be combined with some mechanism to prevent bidding down. 4.5.5, steps 6 and 7. The key K_BU should not be used to protect messages from the CN to the MN. The way in which K_BU is constructed means that it isn't suitable for protecting messages in this direction: The MN has no reason to believe that K_BU came from the CN or that it is fresh. I recommend not authenticating BA's - the threat of forgeed BAs is not very great. 5.2.7 The SPI isn't necessary. At least, it isn't necessary if you're just using RR. It might be needed in an alternative crypto scheme that used IPSEC somehow. The SPI should be an option. 8.3.2 "Any Binding Update which fails to satisfy all of these tests for any other reason (than insufficiency of the Sequence Number) MUST be silently ignored, and the packet carrying the Binding Update MUST be discarded." - There are other situations in which the CN must be sent back an error message, rather than dropping the packet. If the nonce indices are too old, the CN needs to tell the mobile to re-run the RR tests. Re-use of HoT I believe that it is not necessary to test HoA RR every time a BU is sent. In particular, when the mobile's CoA changes, the MN can send a BU as soon as it has received a COT at its new CoA. The MN does not need to wait for a new HOT, as long as it can remember a previous recent HOT. This optimization is important, as it makes hand-offs faster. The HOT will take longer to arrive than the COT, because (a) it has to take a longer path through the network (b) the MN won't be able to receive HOT messages via its home agent until the home agent has accepted a binding update for its new CoA --- in the meantime, the HA will be forwarding HOT messages to the MN's old CoA, and they won't actually reach the MN. Other points on fast hand-offs If a MN has two interfaces, it can send COTI and receive COT for (potential) CoAs on both interfaces, but only send a BU for a CoA on its preferred interface. Then, if the preferred interface dies suddenly, the MN already has the COT response that it needs to change its CoA to the other interface. This should be explained somewhere. (Possibly in another document). Editorial Comments =================== 4.5.4 "Therefore the protection against replays and reordering attacks works when the attacker remembers up to a maximum of 2ˆ31 Binding Updates." - How many bits are there in the sequence number field? The above suggests that the sequence number is 32 bits, but 5.1.7 which says it's 16 bits. - The "2^32" is very badly typeset in the PDF version of the document 4.5.5 "4. CN -> MN(CoA): CoT(K1, l) 5. MN(CoA) -> CN: BU(HoA, CoA, MAC, j, l) - Why is this variable called l? It's called i elsewhere. - The font used in the PDF makes it hard to distinguish this from a 1. 4.5.5 "The cookie and the value i are sent directly the mobile node." Missing word "to". "Older values can be discarded, and messages using them will can be rejected as replays." Extra word "can". ========================== I think that we should be able to get this document into good shape very soon, possibly by the end of the week. Michael Roe Microsoft Research Hush provide the worlds most secure, easy to use online applications - which solution is right for you? HushMail Secure Email http://www.hushmail.com/ HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/ Hush Business - security for your Business http://www.hush.com/ Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/ Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople -----BEGIN PGP SIGNATURE----- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wmIEARECACIFAjyXwdobHG1yb2VfbW9iaWxlaXBAaHVzaG1haWwuY29tAAoJEK/io4nq 2VzLbZYAn37sW3JglrBhcJu8qMyL4eVbuh4EAJ9JQo9UXj6L51cscTVUZ29NIlNqgQ== =V96E -----END PGP SIGNATURE----- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 19:23: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 TAA08666 for ; Tue, 19 Mar 2002 19:23:46 -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 QAA21700; Tue, 19 Mar 2002 16:22: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 QAA02481; Tue, 19 Mar 2002 16:22: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 g2K0LaKL016889 for ; Tue, 19 Mar 2002 16:21:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K0Lai3016888 for mobile-ip-dist; Tue, 19 Mar 2002 16:21: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 g2K0LXKL016881 for ; Tue, 19 Mar 2002 16:21: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 QAA20811 for ; Tue, 19 Mar 2002 16:21:35 -0800 (PST) Received: from santana.widcomm.com (mail.widcomm.com [12.147.6.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28436 for ; Tue, 19 Mar 2002 17:21:28 -0700 (MST) Received: by SANTANA with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Mar 2002 16:16:36 -0800 Message-ID: <28CB1C679CFCD411817500508BEE0F1914873A@SANTANA> From: Jim Hobza To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 19 Mar 2002 16:16:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFA4.7F22AE50" Sender: owner-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_01C1CFA4.7F22AE50 Content-Type: text/plain; charset="iso-8859-1" Hello Ajoy, Could you send me a copy of the paper you discussed in this email thread? Mobility and 802.11 is a subject I am very interested in. Best regards Jim -----Original Message----- From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Tuesday, December 04, 2001 8:12 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Hello James, I sent you the paper in the separate email. Due to oversize, the email with attachment did not go though the list. BTW, if any body needs to look at the attachment I can send personal copy to them. regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, December 04, 2001 5:16 AM To: mobile-ip@sunroof.eng.sun.com; Singh Ajoy-ASINGH1 Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Hi Ajoy, Well, perhaps I am wrong then and it would supplying a pre-Layer 2 trigger is simply an implementation issue. I think the draft still has some value for Postreg, as Karim mentioned. BTW, the paper you mentioned wasn't attached. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "Singh Ajoy-ASINGH1" ; Sent: Monday, December 03, 2001 8:49 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Here I am talking about MN trigger for pre-registration. > > -----Original Message----- > From: Singh Ajoy-ASINGH1 > Sent: Monday, December 03, 2001 10:44 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Hello James, > I am not sure if I completely agree with this draft. I am > attaching some paper from Microsoft which is not > confidential. Based upon the work defined in > the document, I do not sure why it is not possible to > get trigger in case of 802.11. I believe we do not > really need to define anything special for > 802.11. I think getting L2 tigger for 802.11 looks like > some implementation issues not standard issue. Any > comments ? > regards, > ajoy > > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 5:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Folks, > > As some of you may have noticed, > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast > handoff for the current 802.11 MAC. While the 802.11 spec is always > subject to change, it may take awhile and the IPv4 fast handoff work is > supposted to be immediately deployable. We've done a short proposal for > how to support fast handoff for 802.11 as it currently exists, it's at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > ------_=_NextPart_001_01C1CFA4.7F22AE50 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] IPv4 Fast Handover Support for 802.11

Hello Ajoy,
Could you send me a copy of the paper you discussed in this email thread?  Mobility and 802.11
is a subject I am very interested in.
Best regards
Jim

-----Original Message-----
From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com]
Sent: Tuesday, December 04, 2001 8:12 AM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11


Hello James,
I sent you the paper in the separate email. Due to oversize,
the email with attachment did not go though the list.
BTW, if any body needs to look at the attachment I can send
personal copy to them.
regards,
ajoy

-----Original Message-----
From: James Kempf [mailto:kempf@docomolabs-usa.com]
Sent: Tuesday, December 04, 2001 5:16 AM
To: mobile-ip@sunroof.eng.sun.com; Singh Ajoy-ASINGH1
Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11


Hi Ajoy,

Well, perhaps I am wrong then and it would supplying a pre-Layer 2
trigger is simply an implementation issue. I think the
draft still has some value for Postreg, as Karim mentioned.

BTW, the paper you mentioned wasn't attached.


            jak

----- Original Message -----
From: "Singh Ajoy-ASINGH1" <ASINGH1@motorola.com>
To: "Singh Ajoy-ASINGH1" <ASINGH1@motorola.com>;
<mobile-ip@sunroof.eng.sun.com>
Sent: Monday, December 03, 2001 8:49 AM
Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11


> Here I am talking about MN trigger for pre-registration.
>
> -----Original Message-----
> From: Singh Ajoy-ASINGH1
> Sent: Monday, December 03, 2001 10:44 AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11
>
>
> Hello James,
> I am  not sure if I completely agree with this draft. I am
> attaching some paper from Microsoft which is not
> confidential. Based upon the work defined in
> the document, I do not sure why it is not possible to
> get trigger in case of 802.11. I believe we do not
> really need to define anything special for
> 802.11. I think getting L2 tigger for 802.11 looks like
> some implementation issues not standard issue. Any
> comments ?
> regards,
> ajoy
>
>
>
> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: Sunday, December 02, 2001 5:57 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11
>
>
> Folks,
>
> As some of you may have noticed,
> draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast
> handoff for the current 802.11 MAC. While the 802.11 spec is always
> subject to change, it may take awhile and the IPv4 fast handoff work
is
> supposted to be immediately deployable. We've done a short proposal
for
> how to support fast handoff for 802.11 as it currently exists, it's at
>
http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx
> t, it fits into the existing
> low latency framework fairly smoothly. Sorry we couldn't get this in
on
> time, but we just figured it out in the last couple days. This
proposal
> also has some other uses, re the low latency draft, and it is just to
> get the conversation started about how to fix low latency for 802.11
> (that is, we don't necessary expect the WG to accept it as is, but we
do
> want to get the problem solved).
>
>             jak
>

------_=_NextPart_001_01C1CFA4.7F22AE50-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 19:49: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 TAA09098 for ; Tue, 19 Mar 2002 19:49:43 -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 RAA08760; Tue, 19 Mar 2002 17:49: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 QAA07771; Tue, 19 Mar 2002 16:48: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 g2K0ljKL017077 for ; Tue, 19 Mar 2002 16:47:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K0lilr017076 for mobile-ip-dist; Tue, 19 Mar 2002 16:47: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 g2K0lfKL017069 for ; Tue, 19 Mar 2002 16:47:41 -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 QAA27728 for ; Tue, 19 Mar 2002 16:47:43 -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 RAA20359 for ; Tue, 19 Mar 2002 17:47: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 QAA11672; Tue, 19 Mar 2002 16:47:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2K0leN31103; Tue, 19 Mar 2002 16:47:40 -0800 X-mProtect:  Tue, 19 Mar 2002 16:47:40 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.20.251, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaclzEn; Tue, 19 Mar 2002 16:47:38 PST Message-ID: <3C97DC38.1ED518B3@iprg.nokia.com> Date: Tue, 19 Mar 2002 16:47:52 -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: Pete McCann CC: Ahmad Muhanna , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) References: <6B49EDFE974BD51197D70002A56079D801AFCACF@zrc2c013.us.nortel.com> <15511.44319.87462.926346@nwsgpb.ih.lucent.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 Pete, Pete McCann wrote: > I believe we will need to update the MN-HA key in the first RRQ/RRP, > sometimes. > > Maybe the right approach is to update the text in 3220 to explicitly > allow zero security associations with home agents, if some other > "authorization enabling extension" is present in the message. If so, the time to do so would be this week, so that we can get it in at the same time we supply the mysteriously vanished text, and update the "exactly one", and relieve the possibility for misinterpretation that was noticed during Connectathon. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 20:32: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 UAA09689 for ; Tue, 19 Mar 2002 20:32: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 RAA01407; Tue, 19 Mar 2002 17:31:41 -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 RAA16468; Tue, 19 Mar 2002 17:31: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 g2K1TvKL017202 for ; Tue, 19 Mar 2002 17:29:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K1Tvb9017201 for mobile-ip-dist; Tue, 19 Mar 2002 17:29: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 g2K1TsKL017194 for ; Tue, 19 Mar 2002 17:29: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 RAA15954 for ; Tue, 19 Mar 2002 17:29:57 -0800 (PST) Received: from cms2.etri.re.kr (cms2.etri.re.kr [129.254.16.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23651 for ; Tue, 19 Mar 2002 18:29:55 -0700 (MST) Received: from LocalHost (cbh.etri.re.kr [129.254.122.133]) by cms2.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DDGZ1AQ7; Wed, 20 Mar 2002 10:30:53 +0900 Message-ID: <005601c1cfb0$499352b0$857afe81@LocalHost> From: "???" To: Cc: References: <28CB1C679CFCD411817500508BEE0F1914873A@SANTANA> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 20 Mar 2002 10:40:58 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01C1CFFB.B8CB32B0" 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_0053_01C1CFFB.B8CB32B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 UkU6IFttb2JpbGUtaXBdIElQdjQgRmFzdCBIYW5kb3ZlciBTdXBwb3J0IGZvciA4MDIuMTFIZWxs byBBam95LCANCg0KTXkgcmVzZWFyY2ggZ3JvdXAgaXMgdmVyeSBpbnRlcmVzdGVkIGluIHRoZSBJ UHY0IGZhc3QgaGFuZG92ZXIgc3VwcG9ydCBhbmQgbWljcm8tbW9iaWxlIHNlY3VyaXR5IGZvciA4 MDIuMTEuDQpDb3VsZCB5b3Ugc2VuZCBtZSBhIGNvcHkgb2YgdGhlIHBhcGVyIHRoYXQgeW91IHNl bnQgdG8gTXIuIEphbWVzPw0KDQpCZXN0IHJlZ2FyZHMgDQoNCkJ5dW5naG8NCg0KICAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBKaW0gSG9iemEgDQogIFRvOiAnbW9iaWxl LWlwQHN1bnJvb2YuZW5nLnN1bi5jb20nIA0KICBTZW50OiBXZWRuZXNkYXksIE1hcmNoIDIwLCAy MDAyIDk6MTYgQU0NCiAgU3ViamVjdDogUkU6IFttb2JpbGUtaXBdIElQdjQgRmFzdCBIYW5kb3Zl ciBTdXBwb3J0IGZvciA4MDIuMTENCg0KDQogIEhlbGxvIEFqb3ksIA0KICBDb3VsZCB5b3Ugc2Vu ZCBtZSBhIGNvcHkgb2YgdGhlIHBhcGVyIHlvdSBkaXNjdXNzZWQgaW4gdGhpcyBlbWFpbCB0aHJl YWQ/ICBNb2JpbGl0eSBhbmQgODAyLjExIA0KICBpcyBhIHN1YmplY3QgSSBhbSB2ZXJ5IGludGVy ZXN0ZWQgaW4uIA0KICBCZXN0IHJlZ2FyZHMgDQogIEppbSANCg0KICAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSANCiAgRnJvbTogU2luZ2ggQWpveS1BU0lOR0gxIFttYWlsdG86QVNJTkdIMUBt b3Rvcm9sYS5jb21dIA0KICBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNCwgMjAwMSA4OjEyIEFN IA0KICBUbzogbW9iaWxlLWlwQHN1bnJvb2YuZW5nLnN1bi5jb20gDQogIFN1YmplY3Q6IFJFOiBb bW9iaWxlLWlwXSBJUHY0IEZhc3QgSGFuZG92ZXIgU3VwcG9ydCBmb3IgODAyLjExIA0KDQoNCg0K ICBIZWxsbyBKYW1lcywgDQogIEkgc2VudCB5b3UgdGhlIHBhcGVyIGluIHRoZSBzZXBhcmF0ZSBl bWFpbC4gRHVlIHRvIG92ZXJzaXplLCANCiAgdGhlIGVtYWlsIHdpdGggYXR0YWNobWVudCBkaWQg bm90IGdvIHRob3VnaCB0aGUgbGlzdC4gDQogIEJUVywgaWYgYW55IGJvZHkgbmVlZHMgdG8gbG9v ayBhdCB0aGUgYXR0YWNobWVudCBJIGNhbiBzZW5kIA0KICBwZXJzb25hbCBjb3B5IHRvIHRoZW0u IA0KICByZWdhcmRzLCANCiAgYWpveSANCg0KICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSAN CiAgRnJvbTogSmFtZXMgS2VtcGYgW21haWx0bzprZW1wZkBkb2NvbW9sYWJzLXVzYS5jb21dIA0K ICBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNCwgMjAwMSA1OjE2IEFNIA0KICBUbzogbW9iaWxl LWlwQHN1bnJvb2YuZW5nLnN1bi5jb207IFNpbmdoIEFqb3ktQVNJTkdIMSANCiAgU3ViamVjdDog UmU6IFttb2JpbGUtaXBdIElQdjQgRmFzdCBIYW5kb3ZlciBTdXBwb3J0IGZvciA4MDIuMTEgDQoN Cg0KDQogIEhpIEFqb3ksIA0KDQogIFdlbGwsIHBlcmhhcHMgSSBhbSB3cm9uZyB0aGVuIGFuZCBp dCB3b3VsZCBzdXBwbHlpbmcgYSBwcmUtTGF5ZXIgMiANCiAgdHJpZ2dlciBpcyBzaW1wbHkgYW4g aW1wbGVtZW50YXRpb24gaXNzdWUuIEkgdGhpbmsgdGhlIA0KICBkcmFmdCBzdGlsbCBoYXMgc29t ZSB2YWx1ZSBmb3IgUG9zdHJlZywgYXMgS2FyaW0gbWVudGlvbmVkLiANCg0KICBCVFcsIHRoZSBw YXBlciB5b3UgbWVudGlvbmVkIHdhc24ndCBhdHRhY2hlZC4gDQoNCg0KDQogICAgICAgICAgICAg IGphayANCg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiAiU2luZ2gg QWpveS1BU0lOR0gxIiA8QVNJTkdIMUBtb3Rvcm9sYS5jb20+IA0KICBUbzogIlNpbmdoIEFqb3kt QVNJTkdIMSIgPEFTSU5HSDFAbW90b3JvbGEuY29tPjsgDQogIDxtb2JpbGUtaXBAc3Vucm9vZi5l bmcuc3VuLmNvbT4gDQogIFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDMsIDIwMDEgODo0OSBBTSAN CiAgU3ViamVjdDogUkU6IFttb2JpbGUtaXBdIElQdjQgRmFzdCBIYW5kb3ZlciBTdXBwb3J0IGZv ciA4MDIuMTEgDQoNCg0KDQogID4gSGVyZSBJIGFtIHRhbGtpbmcgYWJvdXQgTU4gdHJpZ2dlciBm b3IgcHJlLXJlZ2lzdHJhdGlvbi4gDQogID4gDQogID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gDQogID4gRnJvbTogU2luZ2ggQWpveS1BU0lOR0gxIA0KICA+IFNlbnQ6IE1vbmRheSwgRGVj ZW1iZXIgMDMsIDIwMDEgMTA6NDQgQU0gDQogID4gVG86ICdtb2JpbGUtaXBAc3Vucm9vZi5lbmcu c3VuLmNvbScgDQogID4gU3ViamVjdDogUkU6IFttb2JpbGUtaXBdIElQdjQgRmFzdCBIYW5kb3Zl ciBTdXBwb3J0IGZvciA4MDIuMTEgDQogID4gDQogID4gDQogID4gSGVsbG8gSmFtZXMsIA0KICA+ IEkgYW0gIG5vdCBzdXJlIGlmIEkgY29tcGxldGVseSBhZ3JlZSB3aXRoIHRoaXMgZHJhZnQuIEkg YW0gDQogID4gYXR0YWNoaW5nIHNvbWUgcGFwZXIgZnJvbSBNaWNyb3NvZnQgd2hpY2ggaXMgbm90 IA0KICA+IGNvbmZpZGVudGlhbC4gQmFzZWQgdXBvbiB0aGUgd29yayBkZWZpbmVkIGluIA0KICA+ IHRoZSBkb2N1bWVudCwgSSBkbyBub3Qgc3VyZSB3aHkgaXQgaXMgbm90IHBvc3NpYmxlIHRvIA0K ICA+IGdldCB0cmlnZ2VyIGluIGNhc2Ugb2YgODAyLjExLiBJIGJlbGlldmUgd2UgZG8gbm90IA0K ICA+IHJlYWxseSBuZWVkIHRvIGRlZmluZSBhbnl0aGluZyBzcGVjaWFsIGZvciANCiAgPiA4MDIu MTEuIEkgdGhpbmsgZ2V0dGluZyBMMiB0aWdnZXIgZm9yIDgwMi4xMSBsb29rcyBsaWtlIA0KICA+ IHNvbWUgaW1wbGVtZW50YXRpb24gaXNzdWVzIG5vdCBzdGFuZGFyZCBpc3N1ZS4gQW55IA0KICA+ IGNvbW1lbnRzID8gDQogID4gcmVnYXJkcywgDQogID4gYWpveSANCiAgPiANCiAgPiANCiAgPiAN CiAgPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCiAgPiBGcm9tOiBKYW1lcyBLZW1wZiBb bWFpbHRvOmtlbXBmQGRvY29tb2xhYnMtdXNhLmNvbV0gDQogID4gU2VudDogU3VuZGF5LCBEZWNl bWJlciAwMiwgMjAwMSA1OjU3IFBNIA0KICA+IFRvOiBtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3Vu LmNvbSANCiAgPiBTdWJqZWN0OiBbbW9iaWxlLWlwXSBJUHY0IEZhc3QgSGFuZG92ZXIgU3VwcG9y dCBmb3IgODAyLjExIA0KICA+IA0KICA+IA0KICA+IEZvbGtzLCANCiAgPiANCiAgPiBBcyBzb21l IG9mIHlvdSBtYXkgaGF2ZSBub3RpY2VkLCANCiAgPiBkcmFmdC1pZXRmLW1vYmlsZWlwLWxvd2xh dGVuY3ktaGFuZG9mZnMtaXB2NC50eHQgZG9lcyBub3Qgc3VwcG9ydCBmYXN0IA0KICA+IGhhbmRv ZmYgZm9yIHRoZSBjdXJyZW50IDgwMi4xMSBNQUMuIFdoaWxlIHRoZSA4MDIuMTEgc3BlYyBpcyBh bHdheXMgDQogID4gc3ViamVjdCB0byBjaGFuZ2UsIGl0IG1heSB0YWtlIGF3aGlsZSBhbmQgdGhl IElQdjQgZmFzdCBoYW5kb2ZmIHdvcmsgDQogIGlzIA0KICA+IHN1cHBvc3RlZCB0byBiZSBpbW1l ZGlhdGVseSBkZXBsb3lhYmxlLiBXZSd2ZSBkb25lIGEgc2hvcnQgcHJvcG9zYWwgDQogIGZvciAN CiAgPiBob3cgdG8gc3VwcG9ydCBmYXN0IGhhbmRvZmYgZm9yIDgwMi4xMSBhcyBpdCBjdXJyZW50 bHkgZXhpc3RzLCBpdCdzIGF0IA0KICA+IA0KICBodHRwOi8vZ2VvY2l0aWVzLmNvbS9rZW1wZjQy L2RyYWZ0LWtlbXBmLW1vYmlsZWlwLXBvc3RtaXQtaGFuZG92ZXItMDAudHggDQogID4gdCwgaXQg Zml0cyBpbnRvIHRoZSBleGlzdGluZyANCiAgPiBsb3cgbGF0ZW5jeSBmcmFtZXdvcmsgZmFpcmx5 IHNtb290aGx5LiBTb3JyeSB3ZSBjb3VsZG4ndCBnZXQgdGhpcyBpbiANCiAgb24gDQogID4gdGlt ZSwgYnV0IHdlIGp1c3QgZmlndXJlZCBpdCBvdXQgaW4gdGhlIGxhc3QgY291cGxlIGRheXMuIFRo aXMgDQogIHByb3Bvc2FsIA0KICA+IGFsc28gaGFzIHNvbWUgb3RoZXIgdXNlcywgcmUgdGhlIGxv dyBsYXRlbmN5IGRyYWZ0LCBhbmQgaXQgaXMganVzdCB0byANCiAgPiBnZXQgdGhlIGNvbnZlcnNh dGlvbiBzdGFydGVkIGFib3V0IGhvdyB0byBmaXggbG93IGxhdGVuY3kgZm9yIDgwMi4xMSANCiAg PiAodGhhdCBpcywgd2UgZG9uJ3QgbmVjZXNzYXJ5IGV4cGVjdCB0aGUgV0cgdG8gYWNjZXB0IGl0 IGFzIGlzLCBidXQgd2UgDQogIGRvIA0KICA+IHdhbnQgdG8gZ2V0IHRoZSBwcm9ibGVtIHNvbHZl ZCkuIA0KICA+IA0KICA+ICAgICAgICAgICAgIGphayANCiAgPiANCg0K ------=_NextPart_000_0053_01C1CFFB.B8CB32B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5SRTogW21vYmlsZS1pcF0gSVB2NCBGYXN0IEhhbmRv dmVyIFN1cHBvcnQgZm9yIDgwMi4xMTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7 IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250 ZW50PSJNU0hUTUwgNS4wMC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+ DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQw NDsmIzQ3NTQ4OyBzaXplPTI+PEZPTlQgc2l6ZT0yPkhlbGxvIEFqb3ksPC9GT05UPiA8QlI+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjxGT05U IHNpemU9Mj5NeSByZXNlYXJjaCBncm91cCBpcyB2ZXJ5IGludGVyZXN0ZWQgaW4gDQp0aGUmbmJz cDtJUHY0IGZhc3QgaGFuZG92ZXIgc3VwcG9ydCBhbmQgbWljcm8tbW9iaWxlIHNlY3VyaXR5IGZv ciANCjgwMi4xMS48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7 JiM0NzU0ODsgc2l6ZT0yPjxGT05UIHNpemU9Mj5Db3VsZCB5b3Ugc2VuZCBtZSBhIGNvcHkgb2Yg dGhlIHBhcGVyIA0KdGhhdCB5b3Ugc2VudCB0bzwvRk9OVD4gTXIuIEphbWVzPzwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48Rk9OVCBzaXplPTI+ PC9GT05UPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1 NDg7IHNpemU9Mj48Rk9OVCBzaXplPTI+QmVzdCByZWdhcmRzPC9GT05UPiA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPkJ5dW5naG88QlI+ PC9ESVY+PC9GT05UPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAg MnB4IHNvbGlkOyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweDsgUEFERElORy1M RUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg JiM0NDQwNDsmIzQ3NTQ4OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAg PERJViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQgJiM0NDQwNDsm IzQ3NTQ4OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiA8QSANCiAgaHJlZj0ibWFp bHRvOkpIb2J6YUB3aWRjb21tLmNvbSIgdGl0bGU9SkhvYnphQHdpZGNvbW0uY29tPkppbSBIb2J6 YTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0NDQwNDsmIzQ3NTQ4OyI+ PEI+VG86PC9CPiA8QSANCiAgaHJlZj0ibWFpbHRvOidtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3Vu LmNvbSciIA0KICB0aXRsZT1tb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbT4nbW9iaWxlLWlw QHN1bnJvb2YuZW5nLnN1bi5jb20nPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBw dCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBNYXJjaCAyMCwgMjAw MiA5OjE2IA0KQU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1 NDg7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IFttb2JpbGUtaXBdIElQdjQgRmFzdCBIYW5kb3ZlciAN CiAgU3VwcG9ydCBmb3IgODAyLjExPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8UD48Rk9O VCBzaXplPTI+SGVsbG8gQWpveSw8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Q291bGQgeW91IHNl bmQgbWUgYSBjb3B5IA0KICBvZiB0aGUgcGFwZXIgeW91IGRpc2N1c3NlZCBpbiB0aGlzIGVtYWls IHRocmVhZD8mbmJzcDsgTW9iaWxpdHkgYW5kIA0KICA4MDIuMTE8L0ZPTlQ+IDxCUj48Rk9OVCBz aXplPTI+aXMgYSBzdWJqZWN0IEkgYW0gdmVyeSBpbnRlcmVzdGVkIGluLjwvRk9OVD4gDQogIDxC Uj48Rk9OVCBzaXplPTI+QmVzdCByZWdhcmRzPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPkppbTwv Rk9OVD4gPC9QPg0KICA8UD48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+RnJvbTogU2luZ2ggDQogIEFqb3ktQVNJTkdIMSBbPEEg DQogIGhyZWY9Im1haWx0bzpBU0lOR0gxQG1vdG9yb2xhLmNvbSI+bWFpbHRvOkFTSU5HSDFAbW90 b3JvbGEuY29tPC9BPl08L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPlNlbnQ6IFR1ZXNkYXks IERlY2VtYmVyIDA0LCAyMDAxIDg6MTIgQU08L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPlRv OiA8QSANCiAgaHJlZj0ibWFpbHRvOm1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tIj5tb2Jp bGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbTwvQT48L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0y PlN1YmplY3Q6IFJFOiBbbW9iaWxlLWlwXSBJUHY0IEZhc3QgSGFuZG92ZXIgU3VwcG9ydCBmb3Ig DQogIDgwMi4xMTwvRk9OVD4gPC9QPjxCUj4NCiAgPFA+PEZPTlQgc2l6ZT0yPkhlbGxvIEphbWVz LDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj5JIHNlbnQgeW91IHRoZSBwYXBlciBpbiANCiAgdGhl IHNlcGFyYXRlIGVtYWlsLiBEdWUgdG8gb3ZlcnNpemUsIDwvRk9OVD48QlI+PEZPTlQgc2l6ZT0y PnRoZSBlbWFpbCB3aXRoIA0KICBhdHRhY2htZW50IGRpZCBub3QgZ28gdGhvdWdoIHRoZSBsaXN0 LiA8L0ZPTlQ+PEJSPjxGT05UIHNpemU9Mj5CVFcsIGlmIGFueSANCiAgYm9keSBuZWVkcyB0byBs b29rIGF0IHRoZSBhdHRhY2htZW50IEkgY2FuIHNlbmQ8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6 ZT0yPnBlcnNvbmFsIGNvcHkgdG8gdGhlbS48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+cmVnYXJk cyw8L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPmFqb3k8L0ZPTlQ+IDwvUD4NCiAgPFA+PEZP TlQgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPiA8QlI+PEZPTlQgc2l6 ZT0yPkZyb206IEphbWVzIA0KICBLZW1wZiBbPEEgDQogIGhyZWY9Im1haWx0bzprZW1wZkBkb2Nv bW9sYWJzLXVzYS5jb20iPm1haWx0bzprZW1wZkBkb2NvbW9sYWJzLXVzYS5jb208L0E+XTwvRk9O VD4gDQogIDxCUj48Rk9OVCBzaXplPTI+U2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDQsIDIwMDEg NToxNiBBTTwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+VG86IG1vYmlsZS1pcEBzdW5yb29m LmVuZy5zdW4uY29tOyBTaW5naCBBam95LUFTSU5HSDE8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6 ZT0yPlN1YmplY3Q6IFJlOiBbbW9iaWxlLWlwXSBJUHY0IEZhc3QgSGFuZG92ZXIgU3VwcG9ydCBm b3IgODAyLjExPC9GT05UPiANCiAgPC9QPjxCUj4NCiAgPFA+PEZPTlQgc2l6ZT0yPkhpIEFqb3ks PC9GT05UPiA8L1A+DQogIDxQPjxGT05UIHNpemU9Mj5XZWxsLCBwZXJoYXBzIEkgYW0gd3Jvbmcg dGhlbiBhbmQgaXQgd291bGQgc3VwcGx5aW5nIGEgDQogIHByZS1MYXllciAyPC9GT05UPiA8QlI+ PEZPTlQgc2l6ZT0yPnRyaWdnZXIgaXMgc2ltcGx5IGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLiAN CiAgSSB0aGluayB0aGU8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+ZHJhZnQgc3RpbGwgaGFzIHNv bWUgdmFsdWUgZm9yIFBvc3RyZWcsIGFzIA0KICBLYXJpbSBtZW50aW9uZWQuPC9GT05UPiA8L1A+ DQogIDxQPjxGT05UIHNpemU9Mj5CVFcsIHRoZSBwYXBlciB5b3UgbWVudGlvbmVkIHdhc24ndCBh dHRhY2hlZC48L0ZPTlQ+IDwvUD48QlI+DQogIDxQPjxGT05UIA0KICBzaXplPTI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IA0KICBqYWs8L0ZPTlQ+IDwvUD4NCiAgPFA+PEZPTlQgc2l6ZT0yPi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS08L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+RnJvbTogDQogICJTaW5naCBBam95 LUFTSU5HSDEiICZsdDtBU0lOR0gxQG1vdG9yb2xhLmNvbSZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBz aXplPTI+VG86IA0KICAiU2luZ2ggQWpveS1BU0lOR0gxIiAmbHQ7QVNJTkdIMUBtb3Rvcm9sYS5j b20mZ3Q7OzwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmx0O21vYmlsZS1pcEBzdW5yb29m LmVuZy5zdW4uY29tJmd0OzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj5TZW50OiANCiAgTW9uZGF5 LCBEZWNlbWJlciAwMywgMjAwMSA4OjQ5IEFNPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPlN1Ympl Y3Q6IFJFOiANCiAgW21vYmlsZS1pcF0gSVB2NCBGYXN0IEhhbmRvdmVyIFN1cHBvcnQgZm9yIDgw Mi4xMTwvRk9OVD4gPC9QPjxCUj4NCiAgPFA+PEZPTlQgc2l6ZT0yPiZndDsgSGVyZSBJIGFtIHRh bGtpbmcgYWJvdXQgTU4gdHJpZ2dlciBmb3IgDQogIHByZS1yZWdpc3RyYXRpb24uPC9GT05UPiA8 QlI+PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyANCiAgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBGcm9t OiBTaW5naCANCiAgQWpveS1BU0lOR0gxPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgU2Vu dDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAwMSANCiAgMTA6NDQgQU08L0ZPTlQ+IDxCUj48Rk9O VCBzaXplPTI+Jmd0OyBUbzogDQogICdtb2JpbGUtaXBAc3Vucm9vZi5lbmcuc3VuLmNvbSc8L0ZP TlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBTdWJqZWN0OiBSRTogDQogIFttb2JpbGUtaXBdIElQ djQgRmFzdCBIYW5kb3ZlciBTdXBwb3J0IGZvciA4MDIuMTE8L0ZPTlQ+IDxCUj48Rk9OVCANCiAg c2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OzwvRk9OVD4gPEJSPjxGT05U IHNpemU9Mj4mZ3Q7IEhlbGxvIA0KICBKYW1lcyw8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0 OyBJIGFtJm5ic3A7IG5vdCBzdXJlIGlmIEkgY29tcGxldGVseSBhZ3JlZSANCiAgd2l0aCB0aGlz IGRyYWZ0LiBJIGFtPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgYXR0YWNoaW5nIHNvbWUg cGFwZXIgZnJvbSANCiAgTWljcm9zb2Z0IHdoaWNoIGlzIG5vdDwvRk9OVD4gPEJSPjxGT05UIHNp emU9Mj4mZ3Q7IGNvbmZpZGVudGlhbC4gQmFzZWQgdXBvbiANCiAgdGhlIHdvcmsgZGVmaW5lZCBp bjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHRoZSBkb2N1bWVudCwgSSBkbyBub3Qgc3Vy ZSANCiAgd2h5IGl0IGlzIG5vdCBwb3NzaWJsZSB0bzwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4m Z3Q7IGdldCB0cmlnZ2VyIGluIGNhc2Ugb2YgDQogIDgwMi4xMS4gSSBiZWxpZXZlIHdlIGRvIG5v dDwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHJlYWxseSBuZWVkIHRvIGRlZmluZSANCiAg YW55dGhpbmcgc3BlY2lhbCBmb3I8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyA4MDIuMTEu IEkgdGhpbmsgZ2V0dGluZyBMMiANCiAgdGlnZ2VyIGZvciA4MDIuMTEgbG9va3MgbGlrZTwvRk9O VD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHNvbWUgaW1wbGVtZW50YXRpb24gDQogIGlzc3VlcyBu b3Qgc3RhbmRhcmQgaXNzdWUuIEFueTwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGNvbW1l bnRzID88L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgcmVnYXJkcyw8L0ZPTlQ+IDxC Uj48Rk9OVCBzaXplPTI+Jmd0OyBham95PC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7 PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0y PiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTwvRk9OVD4gDQogIDxCUj48Rk9OVCBzaXplPTI+Jmd0OyBGcm9tOiBKYW1lcyBLZW1wZiBb PEEgDQogIGhyZWY9Im1haWx0bzprZW1wZkBkb2NvbW9sYWJzLXVzYS5jb20iPm1haWx0bzprZW1w ZkBkb2NvbW9sYWJzLXVzYS5jb208L0E+XTwvRk9OVD4gDQogIDxCUj48Rk9OVCBzaXplPTI+Jmd0 OyBTZW50OiBTdW5kYXksIERlY2VtYmVyIDAyLCAyMDAxIDU6NTcgUE08L0ZPTlQ+IDxCUj48Rk9O VCANCiAgc2l6ZT0yPiZndDsgVG86IG1vYmlsZS1pcEBzdW5yb29mLmVuZy5zdW4uY29tPC9GT05U PiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgDQogIFN1YmplY3Q6IFttb2JpbGUtaXBdIElQdjQgRmFz dCBIYW5kb3ZlciBTdXBwb3J0IGZvciA4MDIuMTE8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0y PiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OzwvRk9OVD4gPEJSPjxGT05UIHNpemU9 Mj4mZ3Q7IA0KICBGb2xrcyw8L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+Jmd0OzwvRk9OVD4gPEJS PjxGT05UIHNpemU9Mj4mZ3Q7IEFzIHNvbWUgb2YgDQogIHlvdSBtYXkgaGF2ZSBub3RpY2VkLDwv Rk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IA0KICBkcmFmdC1pZXRmLW1vYmlsZWlwLWxvd2xh dGVuY3ktaGFuZG9mZnMtaXB2NC50eHQgZG9lcyBub3Qgc3VwcG9ydCBmYXN0PC9GT05UPiANCiAg PEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGhhbmRvZmYgZm9yIHRoZSBjdXJyZW50IDgwMi4xMSBNQUMu IFdoaWxlIHRoZSA4MDIuMTEgDQogIHNwZWMgaXMgYWx3YXlzPC9GT05UPiA8QlI+PEZPTlQgc2l6 ZT0yPiZndDsgc3ViamVjdCB0byBjaGFuZ2UsIGl0IG1heSB0YWtlIA0KICBhd2hpbGUgYW5kIHRo ZSBJUHY0IGZhc3QgaGFuZG9mZiB3b3JrPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPmlzPC9GT05U PiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IHN1cHBvc3RlZCB0byBiZSBpbW1lZGlhdGVseSBk ZXBsb3lhYmxlLiBXZSd2ZSBkb25lIGEgDQogIHNob3J0IHByb3Bvc2FsPC9GT05UPiA8QlI+PEZP TlQgc2l6ZT0yPmZvcjwvRk9OVD4gPEJSPjxGT05UIHNpemU9Mj4mZ3Q7IGhvdyB0byANCiAgc3Vw cG9ydCBmYXN0IGhhbmRvZmYgZm9yIDgwMi4xMSBhcyBpdCBjdXJyZW50bHkgZXhpc3RzLCBpdCdz IGF0PC9GT05UPiANCiAgPEJSPjxGT05UIHNpemU9Mj4mZ3Q7PC9GT05UPiA8QlI+PEZPTlQgc2l6 ZT0yPjxBIA0KICBocmVmPSJodHRwOi8vZ2VvY2l0aWVzLmNvbS9rZW1wZjQyL2RyYWZ0LWtlbXBm LW1vYmlsZWlwLXBvc3RtaXQtaGFuZG92ZXItMDAudHgiIA0KICB0YXJnZXQ9X2JsYW5rPmh0dHA6 Ly9nZW9jaXRpZXMuY29tL2tlbXBmNDIvZHJhZnQta2VtcGYtbW9iaWxlaXAtcG9zdG1pdC1oYW5k b3Zlci0wMC50eDwvQT48L0ZPTlQ+IA0KICA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgdCwgaXQgZml0 cyBpbnRvIHRoZSBleGlzdGluZzwvRk9OVD4gPEJSPjxGT05UIA0KICBzaXplPTI+Jmd0OyBsb3cg bGF0ZW5jeSBmcmFtZXdvcmsgZmFpcmx5IHNtb290aGx5LiBTb3JyeSB3ZSBjb3VsZG4ndCBnZXQg dGhpcyANCiAgaW48L0ZPTlQ+IDxCUj48Rk9OVCBzaXplPTI+b248L0ZPTlQ+IDxCUj48Rk9OVCBz aXplPTI+Jmd0OyB0aW1lLCBidXQgd2UganVzdCANCiAgZmlndXJlZCBpdCBvdXQgaW4gdGhlIGxh c3QgY291cGxlIGRheXMuIFRoaXM8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgc2l6ZT0yPnByb3Bvc2Fs PC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgYWxzbyBoYXMgc29tZSBvdGhlciB1c2VzLCBy ZSB0aGUgDQogIGxvdyBsYXRlbmN5IGRyYWZ0LCBhbmQgaXQgaXMganVzdCB0bzwvRk9OVD4gPEJS PjxGT05UIHNpemU9Mj4mZ3Q7IGdldCB0aGUgDQogIGNvbnZlcnNhdGlvbiBzdGFydGVkIGFib3V0 IGhvdyB0byBmaXggbG93IGxhdGVuY3kgZm9yIDgwMi4xMTwvRk9OVD4gPEJSPjxGT05UIA0KICBz aXplPTI+Jmd0OyAodGhhdCBpcywgd2UgZG9uJ3QgbmVjZXNzYXJ5IGV4cGVjdCB0aGUgV0cgdG8g YWNjZXB0IGl0IGFzIGlzLCBidXQgDQogIHdlPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPmRvPC9G T05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDsgd2FudCB0byBnZXQgdGhlIA0KICBwcm9ibGVtIHNv bHZlZCkuPC9GT05UPiA8QlI+PEZPTlQgc2l6ZT0yPiZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAg c2l6ZT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIGphazwvRk9OVD4gPEJSPjxGT05UIHNpemU9 Mj4mZ3Q7PC9GT05UPiA8L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0053_01C1CFFB.B8CB32B0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 20:48: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 UAA10035 for ; Tue, 19 Mar 2002 20:48: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 SAA28986; Tue, 19 Mar 2002 18:46: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 RAA19668; Tue, 19 Mar 2002 17:46: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 g2K1jLKL017290 for ; Tue, 19 Mar 2002 17:45:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K1jLS7017289 for mobile-ip-dist; Tue, 19 Mar 2002 17:45: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 g2K1jGKL017282 for ; Tue, 19 Mar 2002 17:45:17 -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 g2K1jCx21017 for ; Wed, 20 Mar 2002 02:45:16 +0100 (MET) Date: Wed, 20 Mar 2002 02:44:55 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Slides from MIPv6 security discussion 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 slides for the MIPv6 discussion are located at http://www.piuha.net/~jarkko/publications/mipv6/ Three different presentations with the names IETF53. All powerpoint. If anybody can convert them to pdf that would be appreaciated. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 22: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 WAA12121 for ; Tue, 19 Mar 2002 22:09:52 -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 TAA11726; Tue, 19 Mar 2002 19:09: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 TAA03949; Tue, 19 Mar 2002 19:09: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 g2K38AKL017439 for ; Tue, 19 Mar 2002 19:08:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K389nV017438 for mobile-ip-dist; Tue, 19 Mar 2002 19:08: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 g2K385KL017431 for ; Tue, 19 Mar 2002 19:08:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03716 for ; Tue, 19 Mar 2002 19:08:07 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06208 for ; Tue, 19 Mar 2002 19:08:03 -0800 (PST) Received: from AlperVAIO (dhcp149.docomolabs-usa.com [172.21.96.149]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K385I23303; Tue, 19 Mar 2002 19:08:07 -0800 (PST) Message-ID: <00a101c1cfbb$80d5be10$6eb93fa6@AlperVAIO> From: "Alper E. YEGIN" To: , "Singh Ajoy-ASINGH1" References: Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 19 Mar 2002 19:00:07 -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.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 Ajoy, > Hello James, > I am not sure if I completely agree with this draft. I am > attaching some paper from Microsoft which is not > confidential. Based upon the work defined in > the document, I do not sure why it is not possible to > get trigger in case of 802.11. I believe we do not > really need to define anything special for > 802.11. I think getting L2 tigger for 802.11 looks like > some implementation issues not standard issue. Any > comments ? Yes, I agree. Getting L2 triggers on the mobile node side for WLAN is an implementation issue. Getting L2 triggers on the AR/FA side requires a protocol, IMO. Access point is what is aware of clients associating (link up) and disassociating (link down). Getting this information from access point to the router behind it would require a transport. > regards, > ajoy alper > > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 5:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Folks, > > As some of you may have noticed, > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast > handoff for the current 802.11 MAC. While the 802.11 spec is always > subject to change, it may take awhile and the IPv4 fast handoff work is > supposted to be immediately deployable. We've done a short proposal for > how to support fast handoff for 802.11 as it currently exists, it's at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 22:19: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 WAA12316 for ; Tue, 19 Mar 2002 22:19:53 -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 UAA01347; Tue, 19 Mar 2002 20:19: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 TAA06407; Tue, 19 Mar 2002 19:19: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 g2K3HlKL017521 for ; Tue, 19 Mar 2002 19:17:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K3Hk44017520 for mobile-ip-dist; Tue, 19 Mar 2002 19:17: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 g2K3HhKL017513 for ; Tue, 19 Mar 2002 19:17:43 -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 TAA03181 for ; Tue, 19 Mar 2002 19:17:45 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA03578 for ; Tue, 19 Mar 2002 20:17:44 -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 g2K3HhUw025066 for ; Wed, 20 Mar 2002 04:17:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 20 04:17:42 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 04:16:09 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB50@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Singh Ajoy-ASINGH1 Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 20 Mar 2002 04:17: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: Alper, > > Hello James, > > I am not sure if I completely agree with this draft. I am > > attaching some paper from Microsoft which is not > > confidential. Based upon the work defined in > > the document, I do not sure why it is not possible to > > get trigger in case of 802.11. I believe we do not > > really need to define anything special for > > 802.11. I think getting L2 tigger for 802.11 looks like > > some implementation issues not standard issue. Any > > comments ? > > Yes, I agree. Getting L2 triggers on the mobile node side > for WLAN is an implementation issue. > > Getting L2 triggers on the AR/FA side requires a protocol, > IMO. Access point is what is aware of clients associating > (link up) and disassociating (link down). Getting this information > from access point to the router behind it would require a transport. => Agreed. So a network initiation in WLAN is currently not possible as far as I know. I read the paper that Ajoy sent and I think it's more thant enough for WLANs. Hesham > > > regards, > > ajoy > > alper > > > > > > > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Sunday, December 02, 2001 5:57 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > Folks, > > > > As some of you may have noticed, > > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > support fast > > handoff for the current 802.11 MAC. While the 802.11 spec > is always > > subject to change, it may take awhile and the IPv4 fast > handoff work is > > supposted to be immediately deployable. We've done a > short proposal for > > how to support fast handoff for 802.11 as it currently > exists, it's at > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 19 23:51: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 XAA15109 for ; Tue, 19 Mar 2002 23:51:39 -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 VAA18230; Tue, 19 Mar 2002 21:51: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 UAA00894; Tue, 19 Mar 2002 20: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 g2K4oAKL017806 for ; Tue, 19 Mar 2002 20:50:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K4oArc017805 for mobile-ip-dist; Tue, 19 Mar 2002 20:50: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4o7KL017798 for ; Tue, 19 Mar 2002 20:50:07 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00741 for ; Tue, 19 Mar 2002 20:50:10 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08249 for ; Tue, 19 Mar 2002 19:51:51 -0800 (PST) Received: from T23KEMPF (dhcp153.docomolabs-usa.com [172.21.96.153]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2K3pkI24140; Tue, 19 Mar 2002 19:51:47 -0800 (PST) Message-ID: <00d101c1cfc2$5604ba40$956015ac@T23KEMPF> From: "James Kempf" To: , "Singh Ajoy-ASINGH1" References: <4DA6EA82906FD511BE2F00508BCF053802C6AB50@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 19 Mar 2002 19:50: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 Gentlemen, > => Agreed. So a network initiation in WLAN is > currently not possible as far as I know. > I read the paper that Ajoy sent and I think > it's more thant enough for WLANs. > Not so fast. There is a problem on the mobile side as well in that the 802.11 standard *protocol* doesn't provide any signal prior to handover, it just reassociates. Now, it is possible, depending on the 802.11 card and driver, to force handover to a particular access point, note power level and indicate when handover is likely and where, etc., but this is not the same as getting a definitive L2 trigger saying when handover is going to occur and where the MN will go, and it is *most definitively* not portable. Some NIC cards/drivers support it, others don't. As an example of a problem that could occur, suppose the driver makes an assumption, based on power levels, that the MN is going to handover somewhere and the IP level starts performing prehandover care of address change. The standard has no commitment that the handover will, in fact, occur, and it could equally well be aborted and the MN could handover to another access point. Bernard Abboba and I are attempting to raise this issue with the IEEE 802.11 committee, since they are interested in supporting fast handover. Bernard gave a short presentation on the problem at the 802.11 meeting in St. Louis last week, I'm planning on going to Vancouver in July along with Bernard to discuss it in more detail with the committee. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 09: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 JAA00122 for ; Wed, 20 Mar 2002 09: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 HAA21653; Wed, 20 Mar 2002 07:20:50 -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 GAA12789; Wed, 20 Mar 2002 06:20: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 g2KEJcKL018889 for ; Wed, 20 Mar 2002 06:19:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KEJcsm018888 for mobile-ip-dist; Wed, 20 Mar 2002 06:19: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 g2KEJYKL018881 for ; Wed, 20 Mar 2002 06:19: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 GAA12542 for ; Wed, 20 Mar 2002 06:19:36 -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 HAA15791 for ; Wed, 20 Mar 2002 07:19:35 -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 g2KEFZW10401; Wed, 20 Mar 2002 08:15:35 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 08:15:39 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCADB@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charlie Perkins'" , Pete McCann Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Wed, 20 Mar 2002 08:15:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D019.B5BB37F0" Sender: owner-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_01C1D019.B5BB37F0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; I am not sure how can we introduce new issues and text to the already published standard (RFC3220) other than the mysteriously vanished text from that RFC. I believe we need to look into this very closely before rushing for any changes. Now, I believe any addition to the standard MUST consider 100% backward compatibility with existing standard. Existing HA rejects any RRQ message which does not contain MN-HA Authentication extension. as per the standard RFC2002 (RFC3220). Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, March 19, 2002 6:48 PM To: Pete McCann Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) Hello Pete, Pete McCann wrote: > I believe we will need to update the MN-HA key in the first RRQ/RRP, > sometimes. > > Maybe the right approach is to update the text in 3220 to explicitly > allow zero security associations with home agents, if some other > "authorization enabling extension" is present in the message. If so, the time to do so would be this week, so that we can get it in at the same time we supply the mysteriously vanished text, and update the "exactly one", and relieve the possibility for misinterpretation that was noticed during Connectathon. Regards, Charlie P. ------_=_NextPart_001_01C1D019.B5BB37F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A proposal for resolving a very Possible = conflictbetween RFC3220 & RFC3012 (RFC3012bis)

Hello Charlie;

I am not sure how can we introduce new issues and = text to the already published standard (RFC3220) other than the = mysteriously vanished text from that RFC.

I believe we need to look into this very closely = before rushing for any changes.

Now, I believe any addition to the standard MUST = consider 100% backward compatibility with existing standard.
Existing HA rejects any RRQ message which does not = contain MN-HA Authentication extension. as per the standard RFC2002 = (RFC3220).

Regards;

Ahmad Muhanna
Nortel Networks
Shasta PDSN-MIP Development
Phone. + 1 972 685 1416 ESN. 445-1416
amuhanna@nortelnetworks.com



-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, March 19, 2002 6:48 PM
To: Pete McCann
Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; = 'mobile-ip@sunroof.eng.sun.com'
Subject: Re: [mobile-ip] A proposal for resolving a = very Possible
conflictbetween RFC3220 & RFC3012 = (RFC3012bis)



Hello Pete,

Pete McCann wrote:

> I believe we will need to update the MN-HA key = in the first RRQ/RRP,
> sometimes.
>
> Maybe the right approach is to update the text = in 3220 to explicitly
> allow zero security associations with home = agents, if some other
> "authorization enabling extension" is = present in the message.

If so, the time to do so would be this week, so that = we can get it in at
the same time we supply the mysteriously vanished = text, and update the
"exactly one", and relieve the possibility = for misinterpretation that was
noticed during Connectathon.

Regards,
Charlie P.


------_=_NextPart_001_01C1D019.B5BB37F0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 10:06: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 KAA01469 for ; Wed, 20 Mar 2002 10:06: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 IAA11333; Wed, 20 Mar 2002 08:05: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 HAA03018; Wed, 20 Mar 2002 07:05: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 g2KF3kKL019119 for ; Wed, 20 Mar 2002 07:03:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KF3kVn019118 for mobile-ip-dist; Wed, 20 Mar 2002 07:03: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KF3gKL019111 for ; Wed, 20 Mar 2002 07:03:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00448 for ; Wed, 20 Mar 2002 07:03:43 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26668 for ; Wed, 20 Mar 2002 07:03:32 -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 g2KF3XW04616; Wed, 20 Mar 2002 09:03:33 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 09:03:33 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCADD@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'Charles E. Perkins'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Wed, 20 Mar 2002 09:03:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D020.65C932E0" Sender: owner-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_01C1D020.65C932E0 Content-Type: text/plain; charset="iso-8859-1" Hi, Pete, I believe the following points needs to be made clear: 1. It is good to preserve a sort of forward compatibility, however, we need to keep in mind the more important issue which is backward compatibility. 2. When we need to support any argument, we can not use work in progress documentation. In other words, we can not defeat existing standard by referencing I-D which is not a standard yet. 3. As per (RFC2002) RFC3220 & RFC3012, existing HA does the following: i. Expects a SA with all of its home domain Mobile Nodes. ii. Expecting a MN-HA authentication extension in every RRQ. iii. MN-AAA authentication extension does not comply with the definition of the authorization-enabling extension and the only extension which is defined as authorization-enabling extension is the MN-HA authentication extension. 4. Now, with all of the above in mind, It is very dangerous to patch the standard here and there to satisfy future forward compatibility. 5. Interpretation of MIP standard should be done with the original and current spirit and understanding rather than the future evolution and understanding of MIP standard. This will only create more problems without introducing a comprehensive solution. I believe, a committee needs to take charge of this task with one objective in mind "How to evolve MIP standard to be forward combatable with all of the new understandings while maintaining a 100% backward combatability". Thanks for consideration; Regards; Ahmad Muhanna -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Tuesday, March 19, 2002 3:27 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH] Cc: 'mobile-ip@sunroof.eng.sun.com'; 'Charles E. Perkins' Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Hi, Ahmad, I understand your point of view, but some comments below... Ahmad Muhanna writes: > Hi Pete; > > Well, I would like to agree with you, However, the following points make it > very difficult: > > I. RFC3220 (RFC2002): > It is mandatory for the Mobile Node to have a security association > with all of its Home Agents as per > section 3.6. > > "3.6. Mobile Node Considerations > > A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents. > ..... > " Technically, "for each of its home agents" does not imply that there is a home agent - the quantification "for each" could be the empty set. > 2. RFC3012: > It is mandatory that MN must include the MN-HA authentication > extension in every RRQ message as long as the mobile Node shares a > security association with its home agent, as per section 6. below. Again, this is qualified with "as long as the mobile node shares a security association." No security association => no need for the extension. > Now, in my opinion, anything else needs to change the existing standard > including RFC3220, which mandates the MN to maintain a security association > with its Home Agents. > > However, in the case of dynamically allocated Home Agent: > As per RFC3220, the MN must have a security association with its home > agents. > This means that the MN MUST have this security association before sending > any RRQ messages. I am trying to preserve a sort of "forward compatibility" with dynamic home agent assignment ala the Diameter Mobile IP application. I think this was the intention of the language in 3220, which should have been, "at least one authorization enabling extension." The intention was to allow the MN to leave out MN-HA, especially for the case of dynamic HA assignment. > I think the best approach without introducing any serious conflicts and > changes in the standard may be the following: > 1. MN MUST maintain at all times a security association with all of its > home agents or HOME DOMAIN. Where "all of" may be the empty set. > 2. I assume that Dynamically allocated HA is one which belongs to the > MN Home Domain. Maybe not - see http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-09.txt > 3. If the Dynamically allocated HA does not have the security > parameters available for this MN, it MUST inquire it > (ex. AAA infrastructure) to get the needed security parameters to be > able to authenticate the MN. And if the HA is in the foreign domain, the keys must be generated for use by that session only and distributed to the MN in a new extension. > 4. IF the HA or Home Domain needs to update (for example) the shared > security key with the MN, it always can be done after the > initial RRQ with the last (configured or updated) security > parameters the MN shares with its Home Agents (Home Domain) I believe we will need to update the MN-HA key in the first RRQ/RRP, sometimes. Maybe the right approach is to update the text in 3220 to explicitly allow zero security associations with home agents, if some other "authorization enabling extension" is present in the message. -Pete > Thanks for consideration. > > Regards; > > Ahmad Muhanna > > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Tuesday, March 19, 2002 8:55 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: 'Charles E. Perkins' > Subject: [mobile-ip] A proposal for resolving a very Possible conflict > between RFC3220 & RFC3012 (RFC3012bis) > > > Hi, Ahmad, > > I agree with this approach, except for your point 3 below: > > > 3. Then HA always receives a MN-HA Authentication extension and > > optionally MN-AAA authentication extension in every Registration Request. > HA > > may use AAA to get the shared secret key for authenticating the RRQ > message > > using MN-HA Authentication extension or use the MN-AAA authentication > > extension through the AAA infrastructure. > > I think there are cases, such as dynamic HA assignment, where the MN > doesn't have an association with the HA at first. So, we should allow > cases where the MN includes ONLY MN-AAA in the RRQ and it is the basis > for authentication at the HA. > > Also, I would like to clarify the rules for when the FA can strip out > the MN-AAA: it can do so after verifying it with a AAA infrastructure, > and only if a MN-HA authentication extension was present previously in > the RRQ. > > -Pete > > Ahmad Muhanna writes: > > Hello all; > > > > This email is quite long and I appreciate it if as many people as > possible > > have the patience to read through it and post their input. > > > > I exchanged few emails with Charlie Perkins which led me to post the > > following for this mail list. > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > ++++++++ > > >From my reading of RFC3220 and RFC3012 (RFC3102-bis), I would like to > share > > with all of you the following proposed interpretation to prevent a > conflict > > between these two RFCs. > > > > > > 1. RFC3220 introduced a new term "Authorization-enabling extension" and > > made it restricted that registration request MUST have only one > > authorization-enabling extension after renaming the MN-HA Authentication > > extension as authorization-enabling extension, as per section 3.5.2: > > "3.5.2. Mobile-Home Authentication Extension > > Exactly one authorization-enabling extension MUST be present in all > > Registration Requests, and also in all Registration Replies > > generated > > by the Home Agent. The Mobile-Home Authentication Extension is > > always an authorization-enabling for registration messages specified > > in this document. This requirement is intended to eliminate > > problems > > [2] which result from the uncontrolled propagation of remote > > redirects in the Internet. The location of the extension marks the > > end of the authenticated data." > > > > 2. This made it impossible for Mobile Node to include the MN-HA and > > MN-AAA Authentication extensions in the same Registration Request. > > 3. However, RFC3012 section 6 mandates Mobile Node to include MN-HA > > Authentication extension in every Registration Request message as long as > > the Mobile Node has a security association with its Home Agent. (MN MUST > > always maintain a security association with all of its home agents, as > per > > RFC3220 (RFC2002)), > > "6. MN-AAA Authentication subtype > > "............................................ If the MN-AAA > > Authentication > > extension is present, then the Registration Message sent by the > > mobile node MUST contain the Mobile-HA Authentication extension [8] > > if it shares a security association with the Home Agent............" > > > > 4. Also, RFC3012, mandates that the Mobile Node MUST include MN-AAA > > Authentication extension whenever it does not have a security association > > with the Foreign Agent, as in section 3.1. > > > > Since, at least conceptually although it is not referenced any where in > the > > standard, MN-AAA authentication extension is viewed as an > > authorization-enabling extension, this very wide interpretation causes a > > real conflict between RFC3220 & RFC3012 (RFC3012bis). Therefore the > > following interpretation proposes a solution for this issue: > > > > 1. Since RFC3220 defines the Authorization-enabling extension as > > follows in section 1.6: > > > > "Authorization-enabling extension > > An authentication which makes a (registration) message > > acceptable to the ultimate recipient of the registration > > message. An authorization-enabling extension MUST contain > > an SPI. > > In this document, all uses of authorization-enabling > > extension refer to authentication extensions that enable the > > Registration Request message to be acceptable to the home > > agent. Using additional protocol structures specified > > outside of this document, it may be possible for the mobile > > node to provide authentication of its registration to the > > home agent, by way of another authenticating entity within > > the network that is acceptable to the home agent (for > > example, see RFC 2794 [6])." > > > > 2. While RFC3012 introduced MN-AAA authentication extension to offer a > > mechanism to authenticate the Mobile Node to the visited Foreign Agent, > as > > it is clearly obvious in the Abstract, Introduction, and section 3.1 > ""3.1. > > Mobile Node Processing for Registration Requests". > > > > AND since the ultimate recipient of the Registration Request is always > the > > Home Agent, MN-AAA authentication extension does not comply with the > > definition of the Authorization-enabling extension offered in RFC3220. > > > > 1. This will resolve the conflict and allows the Mobile Node to > > always include the MN-HA Authentication extension > (Authorization-enabling) > > and MN-AAA authentication extension (not an authorization-enabling). > > 2. When FA process the Registration Request received from > > the Mobile Node, it is optional for the FA to forward the MN-AAA > > authentication extension or remove it as per RFC3012 section 3.2. > > "The Foreign Agent MUST NOT remove the MN-AAA Authentication > > Extension > > from the Registration Request prior to the completion of the > > authentication performed by the AAA infrastructure. The appendix > > provides an example of an action that could be taken by a foreign > > agent." > > 3. Then HA always receives a MN-HA Authentication extension and > > optionally MN-AAA authentication extension in every Registration Request. > HA > > may use AAA to get the shared secret key for authenticating the RRQ > message > > using MN-HA Authentication extension or use the MN-AAA authentication > > extension through the AAA infrastructure. > > > > Now As per Charlie's suggestion: > > > > 1. A new cause code for the MN failing authentication at the Home Agent > > using the AAA (MN-AAA authentication extension) may be needed. > > > > 2. Also, RFC3012bis should be viewed as obsoleting the word "Exactly" > > -- perhaps changing it to a "At least" in section 3.5.2 of RFC3220. > > "3.5.2. Mobile-Home Authentication Extension > > Exactly At least one authorization-enabling extension MUST be present in > all > > Registration Requests, and also in all Registration Replies generated > > by the Home Agent." > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > +++++++++ > > > > Thanks for your consideration. > > > > > > Regards; > > > > Ahmad Muhanna > > ------_=_NextPart_001_01C1D020.65C932E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A proposal for resolving a very Possible = conflict between RFC3220 & RFC3012 (RFC3012bis)

Hi, Pete,
I believe the following points needs to be made = clear:

1. It is good to preserve a sort of forward = compatibility, however, we need to keep in mind the more important = issue which is backward compatibility.

2. When we need to support any argument, we can not = use work in progress documentation. In other words, we can not defeat = existing standard by referencing I-D which is not a standard = yet.

3. As per (RFC2002) RFC3220 & RFC3012, existing = HA does the following:
        i. =      Expects a SA with all of its home domain = Mobile Nodes.
        ii.     Expecting a MN-HA authentication = extension in every RRQ.
        iii.    MN-AAA authentication extension does = not comply with the definition of the authorization-enabling extension = and

        =         the only = extension which is defined as authorization-enabling extension is the = MN-HA authentication extension.

4. Now, with all of the above in mind, It is very = dangerous to patch the standard here and there to satisfy future = forward compatibility.

5. Interpretation of MIP standard should be done with = the original and current spirit and understanding rather than the = future evolution and understanding of MIP standard. This will only = create more problems without introducing a comprehensive = solution.


I believe, a committee needs to take charge of this = task with one objective in mind "How to evolve MIP standard to be = forward combatable with all of the new understandings while maintaining = a 100% backward combatability".

Thanks for consideration;

Regards;

Ahmad Muhanna


-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Tuesday, March 19, 2002 3:27 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'mobile-ip@sunroof.eng.sun.com'; 'Charles E. = Perkins'
Subject: RE: [mobile-ip] A proposal for resolving a = very Possible
conflict between RFC3220 & RFC3012 = (RFC3012bis)



Hi, Ahmad,

I understand your point of view, but some comments = below...

Ahmad Muhanna writes:
 > Hi Pete;
 >
 > Well, I would like to agree with you, = However, the following points make it
 > very difficult:
 >
 > I.   RFC3220 (RFC2002):
 >      It is mandatory = for the Mobile Node to have a security association
 > with all of its Home Agents as per =
 >      section = 3.6.
 >
 >      "3.6. = Mobile Node Considerations
 >
 >       A mobile = node MUST be configured with a netmask and a mobility
 >      security = association for each of its home agents.
 >      .....
 >      "

Technically, "for each of its home agents" = does not imply that there
is a home agent - the quantification "for = each" could be the empty set.

 > 2.   RFC3012:
 >      It is mandatory = that MN must include the MN-HA authentication
 > extension in every RRQ message as long as = the mobile         Node shares = a
 > security association with its home agent, = as per section 6. below.

Again, this is qualified with "as long as the = mobile node shares a
security association."  No security = association =3D> no need for the
extension.

 > Now, in my opinion, anything else needs to = change the existing standard
 > including RFC3220, which mandates the MN = to maintain a security association
 > with its Home Agents.
 >
 > However, in the case of dynamically = allocated Home Agent:
 > As per RFC3220, the MN must have a = security association with its home
 > agents.
 > This means that the MN MUST have this = security association before sending
 > any RRQ messages.

I am trying to preserve a sort of "forward = compatibility" with dynamic
home agent assignment ala the Diameter Mobile IP = application.  I think
this was the intention of the language in 3220, = which should have been,
"at least one authorization enabling = extension."  The intention was to
allow the MN to leave out MN-HA, especially for the = case of dynamic HA
assignment.

 > I think the best approach without = introducing any serious conflicts and
 > changes in the standard may be the = following:
 > 1.   MN MUST maintain at all = times a security association with all of its
 > home agents or HOME DOMAIN.

Where "all of" may be the empty set.

 > 2.   I assume that Dynamically = allocated HA is one which belongs to the
 > MN Home Domain.

Maybe not - see
http://www.ietf.org/internet-drafts/draft-ietf-aaa-dia= meter-mobileip-09.txt

 > 3.   If the Dynamically = allocated HA does not have the security
 > parameters available for this MN, it MUST = inquire it
 >      (ex. AAA = infrastructure) to get the needed security parameters to be
 > able to authenticate the MN.

And if the HA is in the foreign domain, the keys must = be generated for
use by that session only and distributed to the MN = in a new extension.

 > 4.   IF the HA or Home Domain = needs to update (for example) the shared
 > security key with the MN, it always can = be done after the
 >      initial RRQ with = the last (configured or updated) security
 > parameters the MN shares with its Home = Agents (Home Domain)

I believe we will need to update the MN-HA key in the = first RRQ/RRP,
sometimes.

Maybe the right approach is to update the text in = 3220 to explicitly
allow zero security associations with home agents, = if some other
"authorization enabling extension" is = present in the message.

-Pete

 > Thanks for consideration.
 >
 > Regards;
 >
 > Ahmad Muhanna
 >
 >
 > -----Original Message-----
 > From: Pete McCann [mailto:mccap@lucent.com]
 > Sent: Tuesday, March 19, 2002 8:55 = AM
 > To: mobile-ip@sunroof.eng.sun.com
 > Cc: 'Charles E. Perkins'
 > Subject: [mobile-ip] A proposal for = resolving a very Possible conflict
 > between RFC3220 & RFC3012 = (RFC3012bis)
 >
 >
 > Hi, Ahmad,
 >
 > I agree with this approach, except for = your point 3 below:
 >
 >  >   = 3.      Then HA always receives a MN-HA = Authentication extension and
 >  > optionally MN-AAA = authentication extension in every Registration Request.
 > HA
 >  > may use AAA to get the shared = secret key for authenticating the RRQ
 > message
 >  > using MN-HA Authentication = extension or use the MN-AAA authentication
 >  > extension through the AAA = infrastructure.
 >
 > I think there are cases, such as dynamic = HA assignment, where the MN
 > doesn't have an association with the HA = at first.  So, we should allow
 > cases where the MN includes ONLY MN-AAA = in the RRQ and it is the basis
 > for authentication at the HA.
 >
 > Also, I would like to clarify the rules = for when the FA can strip out
 > the MN-AAA: it can do so after verifying = it with a AAA infrastructure,
 > and only if a MN-HA authentication = extension was present previously in
 > the RRQ.
 >
 > -Pete
 >
 > Ahmad Muhanna writes:
 >  > Hello all;
 >  >
 >  > This email is quite long and I = appreciate it if as many people as
 > possible
 >  > have the patience to read = through it and post their input.
 >  >
 >  > I exchanged few emails with = Charlie Perkins which led me to post the
 >  > following for this mail = list.
 >  >
 >  >
 > = ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++
 >  > ++++++++
 >  > >From my reading of RFC3220 = and RFC3012 (RFC3102-bis), I would like to
 > share
 >  > with all of you the following = proposed interpretation to prevent a
 > conflict
 >  > between these two RFCs.
 >  >
 >  >
 >  > = 1.        RFC3220 introduced a new = term "Authorization-enabling extension" and
 >  > made it restricted that = registration request MUST have only one
 >  > authorization-enabling = extension after renaming the MN-HA Authentication
 >  > extension as = authorization-enabling extension, as per section 3.5.2:
 >  >   "3.5.2. = Mobile-Home Authentication Extension
 >  >    =        Exactly one authorization-enabling = extension MUST be present in all
 >  >    =        Registration Requests, and also in = all Registration Replies
 >  > generated
 >  >   =         by the Home Agent.  The = Mobile-Home Authentication Extension is
 >  >    =        always an authorization-enabling = for registration messages specified
 >  >    =        in this document.  This = requirement is intended to eliminate
 >  > problems
 >  >    =        [2] which result from the = uncontrolled propagation of remote
 >  >    =        redirects in the Internet.  = The location of the extension marks the
 >  >    =        end of the authenticated = data."
 >  >
 >  > = 2.        This made it impossible = for Mobile Node to include the MN-HA and
 >  > MN-AAA Authentication = extensions in the same Registration Request.
 >  > = 3.        However, RFC3012 section 6 = mandates Mobile Node to include MN-HA
 >  > Authentication extension in = every Registration Request message as long as
 >  > the Mobile Node has a security = association with its Home Agent. (MN MUST
 >  > always maintain a security = association with all of its home agents, as
 > per
 >  > RFC3220 (RFC2002)),
 >  = >           &n= bsp;  "6. MN-AAA Authentication subtype
 >  >    =        = "............................................  If the = MN-AAA
 >  > Authentication
 >  >    =        extension is present, then the = Registration Message sent by the
 >  >    =        mobile node MUST contain the = Mobile-HA Authentication extension [8]
 >  >   =         if it shares a security = association with the Home Agent............"
 >  >
 >  > = 4.        Also, RFC3012, mandates = that the Mobile Node MUST include MN-AAA
 >  > Authentication extension = whenever it does not have a security association
 >  > with the Foreign Agent, as in = section 3.1.
 >  >
 >  > Since, at least conceptually = although it is not referenced any where in
 > the
 >  > standard, MN-AAA = authentication extension is viewed as an
 >  > authorization-enabling = extension, this very wide interpretation causes a
 >  > real conflict between RFC3220 = & RFC3012 (RFC3012bis). Therefore the
 >  > following interpretation = proposes a solution for this issue:
 >  >
 >  > = 1.        Since RFC3220 defines the = Authorization-enabling extension as
 >  > follows in section 1.6:
 >  >
 >  >   = "Authorization-enabling extension
 >  >   An authentication which = makes a (registration) message
 >  >   acceptable to the = ultimate recipient of the registration
 >  >   message.  An = authorization-enabling extension MUST contain
 >  >   an SPI.
 >  >   In this document, all = uses of authorization-enabling
 >  >   extension refer to = authentication extensions that enable the
 >  >   Registration Request = message to be acceptable to the home
 >  >   agent. Using additional = protocol structures specified
 >  >   outside of this = document, it may be possible for the mobile
 >  >   node to provide = authentication of its registration to the
 >  >   home agent, by way of = another authenticating entity within
 >  >   the network that is = acceptable to the home agent (for
 >  >   example, see RFC 2794 = [6])."
 >  >
 >  > = 2.        While RFC3012 introduced = MN-AAA authentication extension to offer a
 >  > mechanism to authenticate the = Mobile Node to the visited Foreign Agent,
 > as
 >  > it is clearly obvious in the = Abstract, Introduction, and section 3.1
 > ""3.1.
 >  > Mobile Node Processing for = Registration Requests".
 >  >
 >  > AND since the ultimate = recipient of the Registration Request is always
 > the
 >  > Home Agent, MN-AAA = authentication extension does not comply with the
 >  > definition of the = Authorization-enabling extension offered in RFC3220.
 >  >
 >  >   = 1.      This will resolve the conflict and = allows the Mobile Node to
 >  > always include the MN-HA = Authentication extension
 > (Authorization-enabling)
 >  > and MN-AAA authentication = extension (not an authorization-enabling).
 >  >   = 2.            When FA = process the Registration Request received from
 >  > the Mobile Node, it is = optional for the FA to forward the MN-AAA
 >  > authentication extension or = remove it as per RFC3012 section 3.2.
 >  >   "The Foreign Agent = MUST NOT remove the MN-AAA Authentication
 >  > Extension
 >  >    =        from the Registration Request = prior to the completion of the
 >  >    =        authentication performed by the = AAA infrastructure.  The appendix
 >  >    =        provides an example of an action = that could be taken by a foreign
 >  >    =        agent."
 >  >   = 3.      Then HA always receives a MN-HA = Authentication extension and
 >  > optionally MN-AAA = authentication extension in every Registration Request.
 > HA
 >  > may use AAA to get the shared = secret key for authenticating the RRQ
 > message
 >  > using MN-HA Authentication = extension or use the MN-AAA authentication
 >  > extension through the AAA = infrastructure.
 >  >
 >  > Now As per Charlie's = suggestion:
 >  >
 >  > = 1.        A new cause code for the = MN failing authentication at the Home Agent
 >  > using the AAA (MN-AAA = authentication extension) may be needed.
 >  >
 >  > = 2.        Also, RFC3012bis should be = viewed as obsoleting the word "Exactly"
 >  > -- perhaps changing it to a = "At least" in section 3.5.2 of RFC3220.
 >  > "3.5.2. Mobile-Home = Authentication Extension
 >  > Exactly At least one = authorization-enabling extension MUST be present in
 > all
 >  > Registration Requests, and = also in all Registration Replies generated
 >  > by the Home = Agent."
 >  >
 >  >
 > = ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++
 >  > +++++++++
 >  >
 >  > Thanks for your = consideration.
 >  >
 >  >
 >  > Regards;
 >  >
 >  > Ahmad Muhanna
 >  >

------_=_NextPart_001_01C1D020.65C932E0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 11:19: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 LAA03832 for ; Wed, 20 Mar 2002 11:19: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 IAA00133; Wed, 20 Mar 2002 08:18: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 IAA25934; Wed, 20 Mar 2002 08: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 g2KGHkKL019593 for ; Wed, 20 Mar 2002 08:17:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGHk6g019592 for mobile-ip-dist; Wed, 20 Mar 2002 08:17: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGHhKL019585 for ; Wed, 20 Mar 2002 08:17:43 -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 IAA21521 for ; Wed, 20 Mar 2002 08:17:43 -0800 (PST) Received: from seraph2.grc.nasa.gov (seraph2.lerc.nasa.gov [128.156.10.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03976 for ; Wed, 20 Mar 2002 09:17:42 -0700 (MST) Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 2EAD5C68DE for ; Wed, 20 Mar 2002 11:17:42 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id LAA05687; Wed, 20 Mar 2002 11:17:41 -0500 (EST) Received: from katrinajoy (vtcp2-25.lerc.nasa.gov [139.88.246.25]) by apataki-fi.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-local) id LAA07760; Wed, 20 Mar 2002 11:17:38 -0500 (EST) Message-Id: <4.2.1.20020320103904.00b46bb0@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Wed, 20 Mar 2002 11:18:40 -0500 To: monet@nal.motlabs.com, mobile-ip@sunroof.eng.sun.com From: William Ivancic Subject: [mobile-ip] Mobile-ip and MONET Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_9081184==_.ALT" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=====================_9081184==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed As I understand it, MONET will follow mobile-ip protocols with some slight nuances. Hopefully, this is a correct statement. I see much of the discussion on the MONET list moving MONET from a method of deployment directly compatible with mobile-ip to a MANET. IMHO if you want to add all of the numerous stated bells and whistles, code should be written and tested and a relevant environment. Not simulated, but actually put in some relevant networks and deployed. Then the security, corporate policy, authentication to wireless (and wired) networks and other really important factors will come to light. If we don't keep MONET simple, we'll never get it deployed. Cisco does have an implementation of mobile router for IPv4. It is very simple, yet very useful. A few key items related to this deployment are: 1) No routing protocols running over the interfaces between the FAs and Mobile router (MR). The HA simply redistributes static routes. 2) A second tunnel from HA to MR inside the HA to FA tunnel solves the MR problems with associations between the HA and MR configured as virtual networks vs single host ip addresses. I believe this should also work for IPv6. (I don't think I worded this well, but the following router configuration from our test network may help.) ip mobile virtual-network 10.77.45.128 255.255.255.128 ip mobile mobile-network Dr_Loveless 10.77.45.224 255.255.255.248 ip mobile mobile-network Dr_Loveless 10.77.45.200 255.255.255.248 ip mobile mobile-network Dr_Loveless 10.77.45.208 255.255.255.240 ip mobile mobile-network mobile-router 10.77.45.144 255.255.255.240 ip mobile mobile-network mobile-router 10.77.45.160 255.255.255.248 ip mobile mobile-network mobile-router 10.77.45.136 255.255.255.248 ip mobile host 10.77.45.129 mobile-network mobile-router virtual-network 10.77.45.128 255.255.255.128 ip mobile host 10.77.45.225 mobile-network Dr_Loveless virtual-network 10.77.45.128 255.255.255.128 ip mobile secure host 10.77.45.129 spi 500 key hex 12345678123456781234567812345678 ip mobile secure host 10.77.45.225 spi 710 key hex 12345678123456781234567812345678 We (NASA) have tested nesting mobile routers with the nested mobile router's network being blow the upper layer MR. We have not tried a nested MR belonging to a different HA. I suspect this will work, by the numerous tunnels may create significant performance degradations as far a the applications are concerned. Will Ivancic --=====================_9081184==_.ALT Content-Type: text/html; charset="us-ascii" As I understand it, MONET will follow mobile-ip protocols with some slight nuances.  Hopefully, this is a correct statement.  I see much of the discussion on the MONET list  moving MONET from a method of deployment directly compatible with mobile-ip to a MANET.   IMHO if you want to add all of the numerous stated bells and whistles, code should be written and tested and a relevant environment.   Not simulated, but actually put in some relevant networks and deployed.  Then the security, corporate policy, authentication to wireless (and wired) networks and other really important factors will come to light. 

If we don't keep MONET simple, we'll never get it deployed. 


Cisco does have an implementation of mobile router for IPv4.  It is very simple, yet very useful.  A few key items related to this deployment are:

1)  No routing protocols running over the interfaces between the FAs and Mobile router (MR).  The HA simply redistributes static routes.
2)  A second tunnel from HA to MR inside the HA to FA tunnel solves the MR problems with associations between the HA and MR configured as virtual networks vs single host ip addresses.  I believe this should also work for IPv6.  (I don't think I worded this well, but the following router configuration from our test network may help.)

ip mobile virtual-network 10.77.45.128 255.255.255.128
ip mobile mobile-network Dr_Loveless 10.77.45.224 255.255.255.248
ip mobile mobile-network Dr_Loveless 10.77.45.200 255.255.255.248
ip mobile mobile-network Dr_Loveless 10.77.45.208 255.255.255.240
ip mobile mobile-network mobile-router 10.77.45.144 255.255.255.240
ip mobile mobile-network mobile-router 10.77.45.160 255.255.255.248
ip mobile mobile-network mobile-router 10.77.45.136 255.255.255.248
ip mobile host 10.77.45.129 mobile-network mobile-router virtual-network 10.77.45.128 255.255.255.128
ip mobile host 10.77.45.225 mobile-network Dr_Loveless virtual-network 10.77.45.128 255.255.255.128
ip mobile secure host 10.77.45.129 spi 500 key hex 12345678123456781234567812345678
ip mobile secure host 10.77.45.225 spi 710 key hex 12345678123456781234567812345678


We (NASA) have tested nesting mobile routers with the nested mobile router's network being blow the upper layer MR.  We have not tried a nested MR belonging to a different HA.   I suspect this will work, by the numerous tunnels may create significant performance degradations as far a the applications are concerned. 

Will Ivancic  --=====================_9081184==_.ALT-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 11:26:35 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 LAA04030 for ; Wed, 20 Mar 2002 11:26: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 JAA22736; Wed, 20 Mar 2002 09:25: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 IAA28502; Wed, 20 Mar 2002 08:25: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 g2KGOlKL019682 for ; Wed, 20 Mar 2002 08:24:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGOl91019681 for mobile-ip-dist; Wed, 20 Mar 2002 08:24: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 g2KGOiKL019674 for ; Wed, 20 Mar 2002 08:24: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 IAA28198 for ; Wed, 20 Mar 2002 08:24:45 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07814 for ; Wed, 20 Mar 2002 09:24:43 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA19624 for ; Wed, 20 Mar 2002 09:13:31 -0700 (MST)] Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA18325 for ; Wed, 20 Mar 2002 09:24:42 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2KGOdh17259 for ; Wed, 20 Mar 2002 10:24:39 -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 232072EC84 for ; Wed, 20 Mar 2002 17:24:36 +0100 (CET) To: Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft References: <200203192241.g2JMfoh75349@mailserver4.hushmail.com> From: Alexandru Petrescu Date: 20 Mar 2002 17:24:36 +0100 In-Reply-To: <200203192241.g2JMfoh75349@mailserver4.hushmail.com> Message-ID: Lines: 48 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: mroe_mobileip@hushmail.com writes: > I argee with most of the things that the design team have done in > mipv6-modified-parts-pre16, but I noticed a few technical issues that > ought to be fixed, plus a bunch of typos: I also have plenty of technical remarks. I would leave reporting typos to later. The RR described in on pages 12-13 of the pdf looks sound, but there are many issues with converting this to the actual message, the bits and bytes. For example, HoT: -the K0 is a HMAC-SHA1, then the output length is 96 I suppose, no reason to make it 128 as the message description on page 19, section 5.1.5 would suggest. -"The final 0 inside the MAC function": I think there's no need to code it on 32 bits, 1 bit would be sufficient. -the HoT message has a bizzare look with the 4 reserved bytes not being contiguous. I think that most of those aspects are currently under review. > The key K_BU should not be used to protect messages from the CN to > the MN. The way in which K_BU is constructed means that it isn't > suitable for protecting messages in this direction: The MN has no > reason to believe that K_BU came from the CN or that it is fresh. I had sent a remark to Jari on adding new K2 and K3 to be put in HoTI and CoTI such that when MN receives HoT and CoT it knows they were initiated by itself. There's also place left for the HA to modify the HoTI and HoT that pass through it. Draft says on page 20 end of section 5.1.t that "HoT should be protected by ESP", while the true fact is that only the tunnelled part of the HoT message (the message sent from HA to MN and not the HoT sent from CN to HA). Similar arguments apply to HoTI. This induces here another need (probably) to name HoT=HoT-1+HoT-2 and HoTI=HoTI-1 and HoTI-2. If this renaming is done, then it can be simply stated that ESP is applied to HoTI-1 and HoT-2, but not to HoTI-2 and HoT-1, for example. Applying ESP brings clean and much security, but involves probably much computation on the MN that receives HoT-2; a much lesser demand might be that HA just increases j for example. There are many many things that need detailed consideration in the new RR. And I've not yet assimilated entirely the 64 pages. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 11:40: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 LAA04568 for ; Wed, 20 Mar 2002 11:40: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 JAA02374; Wed, 20 Mar 2002 09:39: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 IAA02950; Wed, 20 Mar 2002 08:38: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 g2KGbkKL019859 for ; Wed, 20 Mar 2002 08:37:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGbkdV019858 for mobile-ip-dist; Wed, 20 Mar 2002 08:37: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGbgKL019848 for ; Wed, 20 Mar 2002 08:37:42 -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 IAA27954 for ; Wed, 20 Mar 2002 08:37:43 -0800 (PST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28335 for ; Wed, 20 Mar 2002 09:37:42 -0700 (MST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2KGbUf19474; Wed, 20 Mar 2002 11:37:30 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA29261; Wed, 20 Mar 2002 10:37:29 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id KAA00466; Wed, 20 Mar 2002 10:37:29 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15512.47817.333671.806677@nwsgpb.ih.lucent.com> Date: Wed, 20 Mar 2002 10:37:29 -0600 (CST) From: Pete McCann To: Charlie Perkins Cc: Ahmad Muhanna , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) In-Reply-To: <3C97DC38.1ED518B3@iprg.nokia.com> References: <6B49EDFE974BD51197D70002A56079D801AFCACF@zrc2c013.us.nortel.com> <15511.44319.87462.926346@nwsgpb.ih.lucent.com> <3C97DC38.1ED518B3@iprg.nokia.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.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, Ok, understanding the urgency, how about the following text: Change the first paragraph of Section 3.5.2 to read: At least one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent. This requirement is intended to eliminate problems [2] which result from the uncontrolled propagation of remote redirects in the Internet. The location of the extension marks the end of the authenticated data covered by that extension. The Mobile-Home Authentication Extension is always an authorization-enabling for registration messages specified in this document; future specifications may define additional authorization-enabling extensions. And the first sentence of Section 3.6: A mobile node MUST be configured with a netmask and a mobility security association for each of its pre-assigned home agents or home agents that could be discovered on a home subnet according to procedures in Section 3.6.1.2. Also, I assume that the missing text people have been discussing covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I can't find it there now. Also, I think the text in 3.6.1.3 (section header currently missing) needs to change to: a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be useful to the foreign agent), followed by c) A mobile-home authentication extension, if present, followed by d) If present, any non-authentication Extensions used only by the foreign agent, followed by e) An authorization-enabling extension, if present, followed by f) The Mobile-Foreign Authentication Extension, if present. Note that item (a) and at least one of (c) or (e) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (f) are optional. However, item (f) MUST be included when the mobile node and the foreign agent share a mobility security association. I think that should do it. -Pete Charlie Perkins writes: > > Hello Pete, > > Pete McCann wrote: > > > I believe we will need to update the MN-HA key in the first RRQ/RRP, > > sometimes. > > > > Maybe the right approach is to update the text in 3220 to explicitly > > allow zero security associations with home agents, if some other > > "authorization enabling extension" is present in the message. > > If so, the time to do so would be this week, so that we can get it in at > the same time we supply the mysteriously vanished text, and update the > "exactly one", and relieve the possibility for misinterpretation that was > noticed during Connectathon. > > Regards, > Charlie P. > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 11:42: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 LAA04682 for ; Wed, 20 Mar 2002 11:42:02 -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 JAA03304; Wed, 20 Mar 2002 09:41: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 IAA02428; Wed, 20 Mar 2002 08:36: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 g2KGZfKL019812 for ; Wed, 20 Mar 2002 08:35:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGZeYs019811 for mobile-ip-dist; Wed, 20 Mar 2002 08:35: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 g2KGZbKL019804 for ; Wed, 20 Mar 2002 08:35: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 IAA02074 for ; Wed, 20 Mar 2002 08:35:38 -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 JAA00038 for ; Wed, 20 Mar 2002 09:35: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 IAA16020; Wed, 20 Mar 2002 08:35:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2KGZVK05328; Wed, 20 Mar 2002 08:35:31 -0800 X-mProtect:  Wed, 20 Mar 2002 08:35:31 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.20.229, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAPmi47; Wed, 20 Mar 2002 08:35:28 PST Message-ID: <3C98BA5D.A4D89A09@iprg.nokia.com> Date: Wed, 20 Mar 2002 08:35: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: Ahmad Muhanna CC: "'Pete McCann'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) References: <6B49EDFE974BD51197D70002A56079D801AFCADC@zrc2c013.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 folks, Ahmad Muhanna wrote: > 1. It is good to preserve a sort of forward compatibility, however, we > need to keep in mind the more important issue which is backward > compatibility. I agree that we need backward compatibility, but I don't think that is at issue here. A home agent will require a MN-HA authentication extension if and only if it has a security association with the mobile node. Thus, if a home agent is built to work with dynamically created assocations, delivered by AAA, then by definition that home agent will be O.K. with the new specification. > 2. When we need to support any argument, we can not use work in > progress documentation. In other words, we can not defeat existing > standard by referencing I-D which is not a standard yet. We can fix anything in RFC 3220bis independently of RFC 3012bis, which is a better approach than having RFC 3012bis obsolete language in the yet-to-be-written RFC3220bis. On the other hand, the entire process has to be driven by working group consensus. And, I sincerely hope that there is no such thing as RFC3220bisbis in any near future timeframe. > 3. As per (RFC2002) RFC3220 & RFC3012, existing HA does the following: > > i. Expects a SA with all of its home domain Mobile Nodes. > > ii. Expecting a MN-HA authentication extension in every > RRQ. > iii. MN-AAA authentication extension does not comply with > the definition of the authorization-enabling extension and > the only extension which is defined as > authorization-enabling extension is the MN-HA authentication > extension. The intention for the "authorization-enabling" language in RFC 3220 was exactly to enable authorization by means other than the MN-HA authentication extension. It was a mistake not to change this, but nobody caught this instance of the inconsistency. I did change seemingly innumerable other instances of it. > 4. Now, with all of the above in mind, It is very dangerous to patch > the standard here and there to satisfy future forward compatibility. I don't think this is really true, as I explained above. Furthermore, I do think it is appropriate to eliminate straggling language that would have been eliminated before except that we just missed it. > 5. Interpretation of MIP standard should be done with the original and > current spirit and understanding rather than the future evolution and > understanding of MIP standard. This will only create more problems > without introducing a comprehensive solution. I agree with you, and yet I see that we should still take the corrective actions that have been discussed. > I believe, a committee needs to take charge of this task with one > objective in mind "How to evolve MIP standard to be forward combatable > with all of the new understandings while maintaining a 100% backward > combat ability". Hmm... another committee... I'm not so sure about this, but then again if there is a need I'll happily go along with the program, as long as the committee supplies the text to go along with any future recommendations. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 12:31: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 MAA06814 for ; Wed, 20 Mar 2002 12:31:08 -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 JAA13655; Wed, 20 Mar 2002 09:30: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 JAA07795; Wed, 20 Mar 2002 09:30: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 g2KHSqKL020255 for ; Wed, 20 Mar 2002 09:28:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KHSpBn020254 for mobile-ip-dist; Wed, 20 Mar 2002 09:28: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 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 g2KHSlKL020247 for ; Wed, 20 Mar 2002 09:28:48 -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 g2KHSjx21802; Wed, 20 Mar 2002 18:28:45 +0100 (MET) Date: Wed, 20 Mar 2002 18:28:15 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft To: Alexandru Petrescu 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: > There's also place left for the HA to modify the HoTI and HoT that > pass through it. Draft says on page 20 end of section 5.1.t that "HoT > should be protected by ESP", while the true fact is that only the > tunnelled part of the HoT message (the message sent from HA to MN and > not the HoT sent from CN to HA). Similar arguments apply to HoTI. Alexandru, The document doesn't say that the HA modify these packets - it merely forwards then from/tom the tunnel to the MN. Are you saying that there is a requirement that the HA be able to modify them? Or is the document just unclear on the fact that they pass through unmodified? Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 12:38: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 MAA07117 for ; Wed, 20 Mar 2002 12:38:45 -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 KAA05342; Wed, 20 Mar 2002 10:38: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 JAA09344; Wed, 20 Mar 2002 09:38: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 g2KHb6KL020400 for ; Wed, 20 Mar 2002 09:37:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KHb5o8020399 for mobile-ip-dist; Wed, 20 Mar 2002 09:37: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 g2KHb2KL020392 for ; Wed, 20 Mar 2002 09:37:02 -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 JAA09923 for ; Wed, 20 Mar 2002 09:37:03 -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 KAA01184 for ; Wed, 20 Mar 2002 10:37:03 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA27879; Wed, 20 Mar 2002 10:37:02 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA22640; Wed, 20 Mar 2002 10:37:02 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2KHaxk05255; Wed, 20 Mar 2002 11:36:59 -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 B653D2EC84; Wed, 20 Mar 2002 18:36:57 +0100 (CET) To: Erik Nordmark Cc: Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft References: From: Alexandru Petrescu Date: 20 Mar 2002 18:36:57 +0100 In-Reply-To: Message-ID: Lines: 19 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 document doesn't say that the HA modify these packets - it merely > forwards then from/tom the tunnel to the MN. > > > Are you saying that there is a requirement that the HA be able to modify them? > Or is the document just unclear on the fact that they pass through > unmodified? The document is clear in that respect. No, there's no requirement that HA be able to modify them. It was just an idea that instead of applying ESP, HA might just increase j. If this doesn't bring anything valuable then that's fine. Sorry for misunderstanding, Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 18:17: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 SAA18625 for ; Wed, 20 Mar 2002 18:17:46 -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 PAA25579; Wed, 20 Mar 2002 15:17: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 PAA08001; Wed, 20 Mar 2002 15:17: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 g2KNG1KL022243 for ; Wed, 20 Mar 2002 15:16:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KNG1WB022242 for mobile-ip-dist; Wed, 20 Mar 2002 15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNFvKL022235 for ; Wed, 20 Mar 2002 15:15: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 PAA07561 for ; Wed, 20 Mar 2002 15:15:47 -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 QAA28246 for ; Wed, 20 Mar 2002 16:15:46 -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 PAA16062 for ; Wed, 20 Mar 2002 15:15:46 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2KNFjd11680 for ; Wed, 20 Mar 2002 15:15:45 -0800 X-mProtect:  Wed, 20 Mar 2002 15:15:45 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUxnQ2h; Wed, 20 Mar 2002 15:15:42 PST Message-ID: <3C99181F.FA6B5312@iprg.nokia.com> Date: Wed, 20 Mar 2002 15:15:43 -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: MIPv6 Internet Draft References: <200203192241.g2JMfoh75349@mailserver4.hushmail.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 mroe_mobileip@hushmail.com wrote: > Re-use of HoT > > I believe that it is not necessary to test HoA RR every time a BU is sent. In > particular, when the mobile's CoA changes, the MN can send a BU as soon as it > has received a COT at its new CoA. The MN does not need to wait for a new HOT, > as long as it can remember a previous recent HOT. This optimization is > important, as it makes hand-offs faster. The HOT will take longer to arrive > than the COT, because (a) it has to take a longer path through the network > (b) the MN won't be able to receive HOT messages via its home agent until the home agent has accepted a binding update for its new CoA --- in the meantime, > the HA will be forwarding HOT messages to the MN's old CoA, and they won't actually reach the MN. Agree with the above strongly. The cookie K0 (in the HoT) can be re-used for a short time (maybe a few minutes). Kbu is then derived from the new K1 and the re-used K0. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 19:09: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 TAA19815 for ; Wed, 20 Mar 2002 19:09: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 RAA22355; Wed, 20 Mar 2002 17:09:26 -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 QAA27478; Wed, 20 Mar 2002 16: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 g2L08AKL022517 for ; Wed, 20 Mar 2002 16:08:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L089FS022516 for mobile-ip-dist; Wed, 20 Mar 2002 16:08: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 g2L086KL022509 for ; Wed, 20 Mar 2002 16:08:06 -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 QAA21278 for ; Wed, 20 Mar 2002 16:08:08 -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 RAA09035 for ; Wed, 20 Mar 2002 17:08:07 -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 g2L07qu14091; Wed, 20 Mar 2002 18:07:52 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 18:07:54 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCAE6@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charlie Perkins'" Cc: "'Pete McCann'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Wed, 20 Mar 2002 18:07:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D06C.7112AFE0" Sender: owner-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_01C1D06C.7112AFE0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; We are in full agreement that any HA will never receive a RRQ message with ONLY MN-AAA authentication except in the case that this HA does not have a security association with the Mobile Node. (RFC3012bis & RFC3220 & this discussion) In reference to the backward compatibility issue: If an existing HA (RFC2002) receives a RRQ message with ONLY the MN-AAA authentication extension, it means that this HA does not have a security association with the Mobile Node (against RFC 2002 but it is considered an error scenario). It is not spilled out in RFC2002 what HA SHOULD do but it can not send a RRP message since there is no SA with the MN. I assume that this HA discards this RRQ without sending a RRP message to the MN. This makes the existing HA(RFC2002) compatible with RFC3220 after replacing the EXACTLY word with (At least) in section 3.5.2. "At least one authorization-enabling extension MUST be present in all ..." Regards; Ahmad Muhanna -----Original Message----- From: Charlie Perkins [mailto:charliep@iprg.nokia.com] Sent: Wednesday, March 20, 2002 10:36 AM To: Muhanna, Ahmad [RICH1:2Q20:EXCH] Cc: 'Pete McCann'; 'mobile-ip@sunroof.eng.sun.com' Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) Hello folks, Ahmad Muhanna wrote: > 1. It is good to preserve a sort of forward compatibility, however, we > need to keep in mind the more important issue which is backward > compatibility. I agree that we need backward compatibility, but I don't think that is at issue here. A home agent will require a MN-HA authentication extension if and only if it has a security association with the mobile node. Thus, if a home agent is built to work with dynamically created assocations, delivered by AAA, then by definition that home agent will be O.K. with the new specification. > 2. When we need to support any argument, we can not use work in > progress documentation. In other words, we can not defeat existing > standard by referencing I-D which is not a standard yet. We can fix anything in RFC 3220bis independently of RFC 3012bis, which is a better approach than having RFC 3012bis obsolete language in the yet-to-be-written RFC3220bis. On the other hand, the entire process has to be driven by working group consensus. And, I sincerely hope that there is no such thing as RFC3220bisbis in any near future timeframe. > 3. As per (RFC2002) RFC3220 & RFC3012, existing HA does the following: > > i. Expects a SA with all of its home domain Mobile Nodes. > > ii. Expecting a MN-HA authentication extension in every > RRQ. > iii. MN-AAA authentication extension does not comply with > the definition of the authorization-enabling extension and > the only extension which is defined as > authorization-enabling extension is the MN-HA authentication > extension. The intention for the "authorization-enabling" language in RFC 3220 was exactly to enable authorization by means other than the MN-HA authentication extension. It was a mistake not to change this, but nobody caught this instance of the inconsistency. I did change seemingly innumerable other instances of it. > 4. Now, with all of the above in mind, It is very dangerous to patch > the standard here and there to satisfy future forward compatibility. I don't think this is really true, as I explained above. Furthermore, I do think it is appropriate to eliminate straggling language that would have been eliminated before except that we just missed it. > 5. Interpretation of MIP standard should be done with the original and > current spirit and understanding rather than the future evolution and > understanding of MIP standard. This will only create more problems > without introducing a comprehensive solution. I agree with you, and yet I see that we should still take the corrective actions that have been discussed. > I believe, a committee needs to take charge of this task with one > objective in mind "How to evolve MIP standard to be forward combatable > with all of the new understandings while maintaining a 100% backward > combat ability". Hmm... another committee... I'm not so sure about this, but then again if there is a need I'll happily go along with the program, as long as the committee supplies the text to go along with any future recommendations. Regards, Charlie P. ------_=_NextPart_001_01C1D06C.7112AFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A proposal for resolving a very Possible = conflictbetween RFC3220 & RFC3012 (RFC3012bis)

Hello Charlie;

We are in full agreement that any HA will never = receive a RRQ message with ONLY MN-AAA authentication except in the = case that this HA does not have a security association with the Mobile = Node. (RFC3012bis & RFC3220 & this discussion)

In reference to the backward compatibility = issue:

If an existing HA (RFC2002) receives a RRQ message = with ONLY the MN-AAA authentication extension, it means that this HA = does not have a security association with the Mobile Node (against RFC = 2002 but it is considered an error scenario). It is not spilled out in = RFC2002 what HA SHOULD do but it can not send a RRP message since there = is no SA with the MN.

I assume that this HA discards this RRQ without = sending a RRP message to the MN.

This makes the existing HA(RFC2002) compatible with = RFC3220 after replacing the EXACTLY word with (At least) in section = 3.5.2.

"At least one authorization-enabling extension = MUST be present in all ..."


Regards;
Ahmad Muhanna

-----Original Message-----
From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
Sent: Wednesday, March 20, 2002 10:36 AM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: 'Pete McCann'; = 'mobile-ip@sunroof.eng.sun.com'
Subject: Re: [mobile-ip] A proposal for resolving a = very Possible
conflictbetween RFC3220 & RFC3012 = (RFC3012bis)



Hello folks,

Ahmad Muhanna wrote:

> 1. It is good to preserve a sort of forward = compatibility, however, we
> need to keep in mind the more important issue = which is backward
> compatibility.

I agree that we need backward compatibility, but I = don't think that is
at issue
here.  A home agent will require a MN-HA = authentication extension if and

only if it has a security association with the mobile = node.  Thus, if a
home agent
is built to work with dynamically created = assocations, delivered by AAA,

then by definition that home agent will be O.K. with = the new
specification.

> 2. When we need to support any argument, we can = not use work in
> progress documentation. In other words, we can = not defeat existing
> standard by referencing I-D which is not a = standard yet.

We can fix anything in RFC 3220bis independently of = RFC 3012bis, which
is a
better approach than having RFC 3012bis obsolete = language in the
yet-to-be-written
RFC3220bis.  On the other hand, the entire = process has to be driven by
working
group consensus.  And, I sincerely hope that = there is no such thing as
RFC3220bisbis
in any near future timeframe.

> 3. As per (RFC2002) RFC3220 & RFC3012, = existing HA does the following:
>
>         = i.      Expects a SA with all of its home = domain Mobile Nodes.
>
>         = ii.     Expecting a MN-HA authentication extension = in every
> RRQ.
>         = iii.    MN-AAA authentication extension does not comply = with
> the definition of the authorization-enabling = extension and
>          = ;       the only extension which is = defined as
> authorization-enabling extension is the MN-HA = authentication
> extension.

The intention for the = "authorization-enabling" language in RFC 3220 was
exactly to enable authorization by means other than = the MN-HA
authentication
extension.  It was a mistake not to change = this, but nobody caught this
instance
of the inconsistency.  I did change seemingly = innumerable other
instances of it.

> 4. Now, with all of the above in mind, It is = very dangerous to patch
> the standard here and there to satisfy future = forward compatibility.

I don't think this is really true, as I explained = above.  Furthermore, I
do think it
is appropriate to eliminate straggling language that = would have been
eliminated
before except that we just missed it.

> 5. Interpretation of MIP standard should be done = with the original and
> current spirit and understanding rather than = the future evolution and
> understanding of MIP standard. This will only = create more problems
> without introducing a comprehensive = solution.

I agree with you, and yet I see that we should still = take the corrective
actions that have
been discussed.

> I believe, a committee needs to take charge of = this task with one
> objective in mind "How to evolve MIP = standard to be forward combatable
> with all of the new understandings while = maintaining a 100% backward
> combat ability".

Hmm... another committee...  I'm not so sure = about this, but then again
if
there is a need I'll happily go along with the = program, as long as the
committee supplies the text to go along with any = future recommendations.

Regards,
Charlie P.


------_=_NextPart_001_01C1D06C.7112AFE0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 20 20:02: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 UAA20516 for ; Wed, 20 Mar 2002 20:02:34 -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 RAA12083; Wed, 20 Mar 2002 17:02:11 -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 RAA04116; Wed, 20 Mar 2002 17:02: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 g2L116KL022646 for ; Wed, 20 Mar 2002 17:01:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L116xW022645 for mobile-ip-dist; Wed, 20 Mar 2002 17:01: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 g2L113KL022638 for ; Wed, 20 Mar 2002 17:01:03 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09331 for ; Wed, 20 Mar 2002 17:01:05 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25691 for ; Wed, 20 Mar 2002 17:01:00 -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 RAA22124 for ; Wed, 20 Mar 2002 17:01:05 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2L114c08840 for ; Wed, 20 Mar 2002 17:01:04 -0800 X-mProtect:  Wed, 20 Mar 2002 17:01:04 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmTEjOk; Wed, 20 Mar 2002 17:01:02 PST Message-ID: <3C9930CE.AAC0B05C@iprg.nokia.com> Date: Wed, 20 Mar 2002 17:01:02 -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] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.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, A question regarding section 9.6 (Protecting Return Routability Packets). It says the home agent MUST protect the tunneled RR packets with an ESP header. IMO, this is pretty strong. Isnt it enough to say, "For additional security, the home agent should protect the RR packets with ESP in tunnel mode". Imagine this. A MN has binding cache entries at multiple CNs. Every time it moves, in addition to sending and receiving so many RR messages, it also has to decrypt the HoT messages from each of the CNs. Also, it now becomes more important that we do the HoTI/HoT test less often (by re-using cookie K0). regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 06:35: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 GAA09041 for ; Thu, 21 Mar 2002 06:35:41 -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 EAA05020; Thu, 21 Mar 2002 04:35: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 DAA21463; Thu, 21 Mar 2002 03:33: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 g2LBWhKL023609 for ; Thu, 21 Mar 2002 03:32:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LBWhHq023608 for mobile-ip-dist; Thu, 21 Mar 2002 03: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LBWeKL023601 for ; Thu, 21 Mar 2002 03:32: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 DAA08068 for ; Thu, 21 Mar 2002 03:32:40 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24143 for ; Thu, 21 Mar 2002 04:32:40 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA06222 for ; Thu, 21 Mar 2002 04:32:39 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id EAA07128 for ; Thu, 21 Mar 2002 04:32:39 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g2LBWZR32160 for ; Thu, 21 Mar 2002 05:32: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 1FD702EC83 for ; Thu, 21 Mar 2002 12:32:33 +0100 (CET) To: Subject: Re: [mobile-ip] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.fi> <3C9930CE.AAC0B05C@iprg.nokia.com> From: Alexandru Petrescu Date: 21 Mar 2002 12:32:33 +0100 In-Reply-To: <3C9930CE.AAC0B05C@iprg.nokia.com> Message-ID: Lines: 19 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: Vijay Devarapalli writes: > A question regarding section 9.6 (Protecting Return Routability > Packets). It says the home agent MUST protect the tunneled RR > packets with an ESP header. IMO, this is pretty strong. Isnt it > enough to say, "For additional security, the home agent should > protect the RR packets with ESP in tunnel mode". I think the above is a good remark. Moreover, it's not only about HoT-2 (the part of HoT that is sent by HA) but also HoTI-1. Both those messages should be ESP'ed optionally. IMHO. > Imagine this. A MN has binding cache entries at multiple CNs. > Every time it moves, in addition to sending and receiving so > many RR messages, it also has to decrypt the HoT messages from > each of the CNs. ...and to encrypt all HoTI messages to its HA. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 09:25:17 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 JAA11537 for ; Thu, 21 Mar 2002 09:25:16 -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 GAA16182; Thu, 21 Mar 2002 06:24:45 -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 GAA12532; Thu, 21 Mar 2002 06: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 g2LENDKL023966 for ; Thu, 21 Mar 2002 06:23:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LENCk3023965 for mobile-ip-dist; Thu, 21 Mar 2002 06:23: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEN9KL023958 for ; Thu, 21 Mar 2002 06:23:09 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14606 for ; Thu, 21 Mar 2002 06:23:12 -0800 (PST) Received: from x86unx3.comp.nus.edu.sg (x86unx3.comp.nus.edu.sg [137.132.90.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14760 for ; Thu, 21 Mar 2002 06:23:03 -0800 (PST) Received: from e500b.comp.nus.edu.sg (e500b.comp.nus.edu.sg [137.132.90.26]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id WAA17530 for ; Thu, 21 Mar 2002 22:23:02 +0800 (GMT-8) Received: from sun450-m.comp.nus.edu.sg(137.132.90.4) by e500b.comp.nus.edu.sg via csmap id 6368; Thu, 21 Mar 2002 22:21:15 +0800 (SGT) Received: from CFCIR6 (root@localhost [127.0.0.1]) pengbin(authenticated bits=0) by sun450.comp.nus.edu.sg (8.12.1/8.12.1) with ESMTP id g2LEMtUI009761 for ; Thu, 21 Mar 2002 22:22:56 +0800 (GMT-8) Message-ID: <001801c1d0e4$751d2610$77538489@CFCIR6> From: "Comp" To: Subject: [mobile-ip] A question on QoS over Mobile IP Date: Thu, 21 Mar 2002 22:26:56 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C1D127.82877650" 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_0015_01C1D127.82877650 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, I have a question on QoS over Mobile IP using RSVP. If a corresponding = node has multiple flows to a mobile node and the flows have different = QoS requirements, how can intermediate routers and mobility agents = distinguish the flows? It seems intermediate routers and mobility agents = classify packet flows based on the source address or home address. But = in this case, the source address or home address are same. I am = confused.=20 pengbin ------=_NextPart_000_0015_01C1D127.82877650 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I have a question on QoS over = Mobile IP using=20 RSVP. If a corresponding node has multiple flows to a mobile node and = the flows=20 have different QoS requirements, how can intermediate routers and = mobility=20 agents distinguish the flows? It seems intermediate routers and mobility = agents=20 classify packet flows based on the source address or home=20 address.  But in this case, the source address or home address = are=20 same. I am confused.
 
 
pengbin
------=_NextPart_000_0015_01C1D127.82877650-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 09:50: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 JAA12423 for ; Thu, 21 Mar 2002 09:50:34 -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 HAA21507; Thu, 21 Mar 2002 07:49: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 GAA20304; Thu, 21 Mar 2002 06:49: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 g2LEmLKL024121 for ; Thu, 21 Mar 2002 06:48:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEmLMW024120 for mobile-ip-dist; Thu, 21 Mar 2002 06:48: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 g2LEmIKL024113 for ; Thu, 21 Mar 2002 06:48:18 -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 GAA18485 for ; Thu, 21 Mar 2002 06:48:19 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13833 for ; Thu, 21 Mar 2002 07:48:18 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 258446A907 for ; Thu, 21 Mar 2002 16:48:02 +0200 (EET) Message-ID: <3C99ED48.1000901@piuha.net> Date: Thu, 21 Mar 2002 16:25: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: Re: [mobile-ip] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.fi> <3C9930CE.AAC0B05C@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 Alexandru Petrescu wrote: > Moreover, it's not only about > HoT-2 (the part of HoT that is sent by HA) but also HoTI-1. Both > those messages should be ESP'ed optionally. IMHO. (Note: All parts of HOTI and HOT are sent by the MN and CN, the HA just routes.) Anyway, we originally didn't include any ESP on the HOTI message because it didn't contain anything -- no cookies or anything beyond the home address. However, we have since then considered adding a cookie from the MN side, to be returned by the CN, as a means to provide very weak form of authentication of the CN's responses. If this is done, it would perhaps make sense to have ESP also for the HOTI and not just HOT. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 09:50: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 JAA12446 for ; Thu, 21 Mar 2002 09:50:58 -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 HAA22932; Thu, 21 Mar 2002 07:50: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 GAA20530; Thu, 21 Mar 2002 06:50: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 g2LEnWKL024138 for ; Thu, 21 Mar 2002 06:49:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEnWe2024137 for mobile-ip-dist; Thu, 21 Mar 2002 06:49: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 g2LEnSKL024130 for ; Thu, 21 Mar 2002 06:49:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16762 for ; Thu, 21 Mar 2002 06:49:29 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22266 for ; Thu, 21 Mar 2002 06:49:22 -0800 (PST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D228A6A901 for ; Thu, 21 Mar 2002 16:48:39 +0200 (EET) Message-ID: <3C99ED48.1000901@piuha.net> Date: Thu, 21 Mar 2002 16:25: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: Re: [mobile-ip] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.fi> <3C9930CE.AAC0B05C@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 Alexandru Petrescu wrote: > Moreover, it's not only about > HoT-2 (the part of HoT that is sent by HA) but also HoTI-1. Both > those messages should be ESP'ed optionally. IMHO. (Note: All parts of HOTI and HOT are sent by the MN and CN, the HA just routes.) Anyway, we originally didn't include any ESP on the HOTI message because it didn't contain anything -- no cookies or anything beyond the home address. However, we have since then considered adding a cookie from the MN side, to be returned by the CN, as a means to provide very weak form of authentication of the CN's responses. If this is done, it would perhaps make sense to have ESP also for the HOTI and not just HOT. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 09:51: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 JAA12478 for ; Thu, 21 Mar 2002 09:51:30 -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 HAA22339; Thu, 21 Mar 2002 07:51: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 GAA20718; Thu, 21 Mar 2002 06:50: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 g2LEnlKL024149 for ; Thu, 21 Mar 2002 06:49:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEnlPL024148 for mobile-ip-dist; Thu, 21 Mar 2002 06:49: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 g2LEngKL024141 for ; Thu, 21 Mar 2002 06:49:42 -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 GAA20353 for ; Thu, 21 Mar 2002 06:49:42 -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 HAA21443 for ; Thu, 21 Mar 2002 07:49:42 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B6C616A907 for ; Thu, 21 Mar 2002 16:48:54 +0200 (EET) Message-ID: <3C99EEE1.8020808@piuha.net> Date: Thu, 21 Mar 2002 16:32:01 +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] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.fi> <3C9930CE.AAC0B05C@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 Vijay Devarapalli wrote: > A question regarding section 9.6 (Protecting Return Routability > Packets). It says the home agent MUST protect the tunneled RR > packets with an ESP header. IMO, this is pretty strong. Isnt it > enough to say, "For additional security, the home agent should > protect the RR packets with ESP in tunnel mode". Is proposal a "should" or a "SHOULD"? > Imagine this. A MN has binding cache entries at multiple CNs. > Every time it moves, in addition to sending and receiving so > many RR messages, it also has to decrypt the HoT messages from > each of the CNs. I'm not sure about the MUST vs. SHOULD yet but a couple of comments: - I believe in most practical cases RTT and bandwidth considerations are the limiting factors, not so much (symmetric) encryption of small packets. - What is the security impact of doing or not doing encryption? Attackers can now exist also on the HA-MN path. In practise they would be on the MN's LAN, such as at a public airport WLAN or something like that. I think the question to ask in trying to figure out whether a MUST is necessary is who is going to get hurt if an attack is performed. If it's only the MN, then there are some grounds on making the MN able to make the decision itself. Which brings us to the question of use vs. implement. MUST implement sounds reasonable at least to allow the user to make the decision. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 09:52: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 JAA12520 for ; Thu, 21 Mar 2002 09:52:54 -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 HAA23031; Thu, 21 Mar 2002 07:52: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 GAA21281; Thu, 21 Mar 2002 06:52: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 g2LEpNKL024219 for ; Thu, 21 Mar 2002 06:51:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEpNWr024218 for mobile-ip-dist; Thu, 21 Mar 2002 06:51: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 g2LEpJKL024208 for ; Thu, 21 Mar 2002 06:51:19 -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 GAA19082 for ; Thu, 21 Mar 2002 06:51:19 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15320 for ; Thu, 21 Mar 2002 07:51:18 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7EE9B6A901 for ; Thu, 21 Mar 2002 16:50:13 +0200 (EET) Message-ID: <3C99EEE1.8020808@piuha.net> Date: Thu, 21 Mar 2002 16:32:01 +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] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.fi> <3C9930CE.AAC0B05C@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 Vijay Devarapalli wrote: > A question regarding section 9.6 (Protecting Return Routability > Packets). It says the home agent MUST protect the tunneled RR > packets with an ESP header. IMO, this is pretty strong. Isnt it > enough to say, "For additional security, the home agent should > protect the RR packets with ESP in tunnel mode". Is proposal a "should" or a "SHOULD"? > Imagine this. A MN has binding cache entries at multiple CNs. > Every time it moves, in addition to sending and receiving so > many RR messages, it also has to decrypt the HoT messages from > each of the CNs. I'm not sure about the MUST vs. SHOULD yet but a couple of comments: - I believe in most practical cases RTT and bandwidth considerations are the limiting factors, not so much (symmetric) encryption of small packets. - What is the security impact of doing or not doing encryption? Attackers can now exist also on the HA-MN path. In practise they would be on the MN's LAN, such as at a public airport WLAN or something like that. I think the question to ask in trying to figure out whether a MUST is necessary is who is going to get hurt if an attack is performed. If it's only the MN, then there are some grounds on making the MN able to make the decision itself. Which brings us to the question of use vs. implement. MUST implement sounds reasonable at least to allow the user to make the decision. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 10:07: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 KAA13017 for ; Thu, 21 Mar 2002 10:07: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 IAA23517; Thu, 21 Mar 2002 08:06: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 HAA25465; Thu, 21 Mar 2002 07:06: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 g2LF5FKL024432 for ; Thu, 21 Mar 2002 07:05:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LF5Eiw024431 for mobile-ip-dist; Thu, 21 Mar 2002 07:05: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 g2LF5BKL024424 for ; Thu, 21 Mar 2002 07:05:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24985 for ; Thu, 21 Mar 2002 07:05:12 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23349 for ; Thu, 21 Mar 2002 07:05:15 -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 g2LF5Bh08000 for ; Thu, 21 Mar 2002 07:05:11 -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 ABE86731; Thu, 21 Mar 2002 07:02:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09733; Thu, 21 Mar 2002 07:05:11 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15513.63142.966028.23806@thomasm-u1.cisco.com> Date: Thu, 21 Mar 2002 07:05:10 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A question on QoS over Mobile IP In-Reply-To: <001801c1d0e4$751d2610$77538489@CFCIR6> References: <001801c1d0e4$751d2610$77538489@CFCIR6> 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 > I have a question on QoS over Mobile IP using RSVP. If a corresponding = > node has multiple flows to a mobile node and the flows have different = >QoS requirements, how can intermediate routers and mobility agents = >distinguish the flows? It seems intermediate routers and mobility agents = >classify packet flows based on the source address or home address. But = >in this case, the source address or home address are same. I am = > confused.=20 Pengbin, I think you're confused, but it's perfectly understandable because this is a pretty murky subject :-) An RSVP router would definitely use the CoA to classify packets, not the home address. This is irrespective of whether this is a good or bad thing for MIP: it's simply an artifact of RSVP not having any notion of a home address option, or, say, a prefix invariant flow selector. This mainly leads to the necessesity of reestablishing the reservation along the entire path to the CN when you change CoA's. That said, I don't really understand your issue with multiple reservations. Normal RSVP handles them just fine by setting up different flow selectors bound to different tspecs. Clearly a stationary node isn't ordinarily changing its source address, so I guess I don't see what you're finding problematic. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 10:31: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 KAA13859 for ; Thu, 21 Mar 2002 10:31:06 -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 IAA12731; Thu, 21 Mar 2002 08:30: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 HAA02618; Thu, 21 Mar 2002 07:30: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 g2LFT8KL024663 for ; Thu, 21 Mar 2002 07:29:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LFT8Ur024662 for mobile-ip-dist; Thu, 21 Mar 2002 07:29: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 g2LFT5KL024655 for ; Thu, 21 Mar 2002 07:29:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24510 for ; Thu, 21 Mar 2002 07:29:06 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04885 for ; Thu, 21 Mar 2002 07:28:44 -0800 (PST) Received: from mail.ustc.edu.cn (mail.ustc.edu.cn [202.38.64.10]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id XAA22152 for ; Thu, 21 Mar 2002 23:18:01 +0800 Received: (qmail 13516 invoked by uid 1187); 21 Mar 2002 15:20:00 -0000 Date: Thu, 21 Mar 2002 23:20:00 +0800 (CST) From: Wang Hui X-X-Sender: To: Subject: Re: [mobile-ip] A question on QoS over Mobile IP In-Reply-To: <15513.63142.966028.23806@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: I think the key issue of QoS over MIP, which is different from the traditional IP network framework, is how to guarantee the QoS of a specific flow when the mobile node roams among diffrent networks. The QoS parameters have to be 'roam' around different networks due to the mobile node's moving. Any idea on this issue? On Thu, 21 Mar 2002, Michael Thomas wrote: > > > I have a question on QoS over Mobile IP using RSVP. If a corresponding = > > node has multiple flows to a mobile node and the flows have different = > >QoS requirements, how can intermediate routers and mobility agents = > >distinguish the flows? It seems intermediate routers and mobility agents = > >classify packet flows based on the source address or home address. But = > >in this case, the source address or home address are same. I am = > > confused.=20 > > Pengbin, > > I think you're confused, but it's perfectly > understandable because this is a pretty murky > subject :-) An RSVP router would definitely use > the CoA to classify packets, not the home address. > This is irrespective of whether this is a good or > bad thing for MIP: it's simply an artifact of RSVP > not having any notion of a home address option, > or, say, a prefix invariant flow selector. This > mainly leads to the necessesity of reestablishing > the reservation along the entire path to the CN > when you change CoA's. > > That said, I don't really understand your issue > with multiple reservations. Normal RSVP handles > them just fine by setting up different flow > selectors bound to different tspecs. Clearly a > stationary node isn't ordinarily changing its > source address, so I guess I don't see what you're > finding problematic. > > Mike > -- Wang Hui Next Generation Internet Research Team, InfoNet Lab, USTC http://mail.ustc.edu.cn/~whui Tel: +86-551-3603634 From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 10:44: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 KAA14146 for ; Thu, 21 Mar 2002 10:44: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 IAA22784; Thu, 21 Mar 2002 08:44:13 -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 HAA06313; Thu, 21 Mar 2002 07:44: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 g2LFhFKL024742 for ; Thu, 21 Mar 2002 07:43:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LFhF43024741 for mobile-ip-dist; Thu, 21 Mar 2002 07:43: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 g2LFhCKL024734 for ; Thu, 21 Mar 2002 07:43:12 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06021 for ; Thu, 21 Mar 2002 07:43:13 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06146 for ; Thu, 21 Mar 2002 07:43:16 -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 g2LFhAd19486 for ; Thu, 21 Mar 2002 07:43: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 ABE87327; Thu, 21 Mar 2002 07:40:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA09741; Thu, 21 Mar 2002 07:43:08 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15513.65420.381981.800842@thomasm-u1.cisco.com> Date: Thu, 21 Mar 2002 07:43:08 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A question on QoS over Mobile IP In-Reply-To: References: <15513.63142.966028.23806@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 Wang Hui writes: > I think the key issue of QoS over MIP, which is different from the > traditional IP network framework, is how to guarantee the QoS of a > specific flow when the mobile node roams among diffrent networks. > > The QoS parameters have to be 'roam' around different networks due to the > mobile node's moving. > > Any idea on this issue? Well, I have some ideas about these issue, but there isn't anything that's standard. I wrote a draft a while back which is now expired going over many of the issues with MIP/RSVP interactions. It's still available at http://www.mtcc.com/standards/draft-thomas-seamoby-rsvp-analysis-00.txt Ultimately, I believe that the general intent was to resolve these issues in NSIS. A QoS requirements from mobile IP has also been written; Hemant Chasker was the editor. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 11:36:24 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 LAA16065 for ; Thu, 21 Mar 2002 11:36:23 -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 JAA16114; Thu, 21 Mar 2002 09:35:50 -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 IAA09476; Thu, 21 Mar 2002 08:35: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 g2LGYgKL024929 for ; Thu, 21 Mar 2002 08:34:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LGYgqn024928 for mobile-ip-dist; Thu, 21 Mar 2002 08:34: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 g2LGYcKL024921 for ; Thu, 21 Mar 2002 08:34:39 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22016 for ; Thu, 21 Mar 2002 08:34:40 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27931 for ; Thu, 21 Mar 2002 08:34:33 -0800 (PST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D13D16A901; Thu, 21 Mar 2002 18:34:28 +0200 (EET) Message-ID: <3C9A090C.8020207@piuha.net> Date: Thu, 21 Mar 2002 18:23:40 +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: Mike Roe Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft References: <200203192241.g2JMfoh75349@mailserver4.hushmail.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 Thanks a lot Mike for your valuable comments. Some responses below: > We need to be able to support alternative methods for calculating K_BU (e.g. > CGA schemes, manually configured keys, IPSEC ...). This document does not need > to specify the details of these alternative mechanisms, but it does need to say > two things: > > (a) It needs to say that there might exist alternative schemes that have > most of their protocol steps in common with the protocol described in > this document, but have a different step 5. Ok. I added text to this effect. > (b) It needs to describe how a CN node knows that this particular scheme (RR) > is being used, rather than one of the others that have a different step > 5. > > The obvious way to do this is to have a field in the BU that indicates > which crypto scheme is being used. This needs to be combined with some > mechanism to prevent bidding down. We are thinking of using the Reserved field in BU and possibly also in [HC]OT{,I} messages as a place for new flags that would do this. Do you think this is sufficient? And another question: do you think we should immediately put in two algorithms such as SHA1 and MD5 for doing the hashes involved in the RR procedure? This is often done in security protocols, but in this case I'm thinking the strength of RR is not so big that we should be thinking about breaking hash functions as the easiest attack... > 4.5.5, steps 6 and 7. > > The key K_BU should not be used to protect messages from the CN to the MN. > The way in which K_BU is constructed means that it isn't suitable for > protecting messages in this direction: The MN has no reason to believe that K_BU came from the CN or that it is fresh. I recommend not authenticating > BA's - the threat of forgeed BAs is not very great. Ok. We have however considered also a nonce-scheme where the MN sends a nonce that is to be returned by the CN in all of its responses messages (HOT, COT) or included in the hash of the response messasage (BA). Do you think that would be acceptable? > 5.2.7 > > The SPI isn't necessary. At least, it isn't necessary if you're just using RR. > It might be needed in an alternative crypto scheme that used IPSEC somehow. > The SPI should be an option. Agreed. > "Any Binding Update which fails to satisfy all of these tests for any other > reason (than insufficiency of the Sequence Number) MUST be silently ignored, > and the packet carrying the Binding Update MUST be discarded." > > - There are other situations in which the CN must be sent back an error > message, rather than dropping the packet. If the nonce indices are too > old, the CN needs to tell the mobile to re-run the RR tests. Yes. > Re-use of HoT > > I believe that it is not necessary to test HoA RR every time a BU is sent. In > particular, when the mobile's CoA changes, the MN can send a BU as soon as it > has received a COT at its new CoA. The MN does not need to wait for a new HOT, > as long as it can remember a previous recent HOT. This optimization is > important, as it makes hand-offs faster. The HOT will take longer to arrive I'm starting to think so as well. We do need to think about suitable recommendations for the timers involved for home and coa cookie lifetimes and so on. Also, I think it was Erik who wondered if we might actually have a field in the [HC]OT message to describe the expected (or committed?) lifetime of the cookie, helping the MN decide whether it should redo something later or not. This would bring some additional complexity though, and the MN has no assurance in any case that the cookies really can be used anyway so perhaps we should just have a recommendation and allow MNs to optimistically try these things within those recommended limits. Or what do you think? > than the COT, because (a) it has to take a longer path through the network > (b) the MN won't be able to receive HOT messages via its home agent until the home agent has accepted a binding update for its new CoA --- in the meantime, > the HA will be forwarding HOT messages to the MN's old CoA, and they won't actually reach the MN. Interesting. By the way, when an MN arrives at a new CoA, it could send a home BU immediately followed by a HOT... hoping that there's no reordering. But I'm not sure this is a desireable activity, since I don't know how the MN would recover if the messages were indeed reorder. On the other hand, we could in theory design a home BU message that carried a sequence of CN addresses to which the HA would create and send a HOTI on the behalf of the MN. > Other points on fast hand-offs > > If a MN has two interfaces, it can send COTI and receive COT for (potential) > CoAs on both interfaces, but only send a BU for a CoA on its preferred > interface. Then, if the preferred interface dies suddenly, the MN already has > the COT response that it needs to change its CoA to the other interface. > This should be explained somewhere. (Possibly in another document). Yes. We may leave also some of this smart 'caching' of RR activity to smart implementers. > Editorial Comments Thanks, fixed now. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 11:38: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 LAA16150 for ; Thu, 21 Mar 2002 11:38:18 -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 JAA20819; Thu, 21 Mar 2002 09:37:48 -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 IAA09846; Thu, 21 Mar 2002 08:37: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 g2LGapKL024961 for ; Thu, 21 Mar 2002 08:36:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LGapMq024960 for mobile-ip-dist; Thu, 21 Mar 2002 08:36: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 g2LGalKL024950 for ; Thu, 21 Mar 2002 08:36:47 -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 IAA22714 for ; Thu, 21 Mar 2002 08:36:49 -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 JAA17226 for ; Thu, 21 Mar 2002 09:36:47 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AED816A901; Thu, 21 Mar 2002 18:36:38 +0200 (EET) Message-ID: <3C9A0C6E.3030602@piuha.net> Date: Thu, 21 Mar 2002 18:38:06 +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: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft References: <200203192241.g2JMfoh75349@mailserver4.hushmail.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 Alexandru Petrescu wrote: > The RR described in on pages 12-13 of the pdf looks sound, but there > are many issues with converting this to the actual message, the bits > and bytes. For example, HoT: > -the K0 is a HMAC-SHA1, then the output length is 96 I suppose, no SHA1 produces 160 bits I think, but usally folks are confident with cutting hash outputs to 96 bits. 96/128 really doesn't matter so we should pick the size based on alignment considerations. > reason to make it 128 as the message description on page 19, section > 5.1.5 would suggest. Ok, let's re-align and re-size the messages once we agree that we have all the fields. > -"The final 0 inside the MAC function": I think there's no need to > code it on 32 bits, 1 bit would be sufficient. At least 8 is needed to make typical implementations work well. But since that is anyway one memory operation, might as well make it the current 32. > -the HoT message has a bizzare look with the 4 reserved bytes not > being contiguous. Agreed. Changed now. > There's also place left for the HA to modify the HoTI and HoT that > pass through it. Draft says on page 20 end of section 5.1.t that "HoT > should be protected by ESP", while the true fact is that only the > tunnelled part of the HoT message (the message sent from HA to MN and > not the HoT sent from CN to HA). Similar arguments apply to HoTI. Yes, but doesn't the draft say "... between the MN and the HA"? I think that should be enough to clarify that we don't expect to run IPsec between HA and CN. > Applying ESP brings clean and much security, but involves probably > much computation on the MN that receives HoT-2; a much lesser demand > might be that HA just increases j for example. This is an interesting suggestion, the security impacts have to be thought out. I don't think changing j/i is sufficient since attackers could easily observe the progress of these values on the cn (they are same for all mns). Changing Home Cookie would do the job, but I wonder if changing == encryption? > There are many many things that need detailed consideration in the new > RR Your feedback is very much appreciated. Keep on commenting the rest as well... Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 21 13:13:16 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 NAA20425 for ; Thu, 21 Mar 2002 13:13:16 -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 KAA11593; Thu, 21 Mar 2002 10:10:39 -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 KAA22026; Thu, 21 Mar 2002 10:10: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 g2LI9WKL025333 for ; Thu, 21 Mar 2002 10:09:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LI9W9Y025332 for mobile-ip-dist; Thu, 21 Mar 2002 10: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LI9TKL025325 for ; Thu, 21 Mar 2002 10:09: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 KAA04752 for ; Thu, 21 Mar 2002 10:09: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 LAA10315 for ; Thu, 21 Mar 2002 11:09: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 KAA01398 for ; Thu, 21 Mar 2002 10:09:29 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2LI9TC32008 for ; Thu, 21 Mar 2002 10:09:29 -0800 X-mProtect:  Thu, 21 Mar 2002 10:09:29 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdq76yFb; Thu, 21 Mar 2002 10:09:27 PST Message-ID: <3C9A21D6.C2DB7CD2@iprg.nokia.com> Date: Thu, 21 Mar 2002 10:09: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] MIPv6 Internet Draft References: <3C92E7BD.8050500@kolumbus.fi> <3C9930CE.AAC0B05C@iprg.nokia.com> <3C99EEE1.8020808@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 Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > A question regarding section 9.6 (Protecting Return Routability > > Packets). It says the home agent MUST protect the tunneled RR > > packets with an ESP header. IMO, this is pretty strong. Isnt it > > enough to say, "For additional security, the home agent should > > protect the RR packets with ESP in tunnel mode". > > Is proposal a "should" or a "SHOULD"? should. > > > Imagine this. A MN has binding cache entries at multiple CNs. > > Every time it moves, in addition to sending and receiving so > > many RR messages, it also has to decrypt the HoT messages from > > each of the CNs. > > I'm not sure about the MUST vs. SHOULD yet but a couple of > comments: > > - I believe in most practical cases RTT and bandwidth considerations > are the limiting factors, not so much (symmetric) encryption > of small packets. > > - What is the security impact of doing or not doing encryption? > Attackers can now exist also on the HA-MN path. In practise > they would be on the MN's LAN, such as at a public airport WLAN > or something like that. I think the question to ask in trying > to figure out whether a MUST is necessary is who is going to get > hurt if an attack is performed. If it's only the MN, then there > are some grounds on making the MN able to make the decision itself. > Which brings us to the question of use vs. implement. > MUST implement sounds reasonable at least to allow the user to > make the decision. I agree with 'MUST implement'. but selectively used. Maybe it can be indicated by the mobile node with a flag in the BU message. If a particular wireless link is protected by IPSec ESP (between the AR and the MN) or link layer encryption, the MN indicates to the HA that it does not want to protect HoTI/HoT messages with ESP. If the MN is moving too fast, it indicates the same to the HA. And the earlier sentence now becomes "If additional security is required (indicated by the MN in HA BU??), the HA and MN should protect the RR packets with ESP in tunnel mode" Does that sound good? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 22 10:37: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 KAA23918 for ; Fri, 22 Mar 2002 10:37: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 HAA01245; Fri, 22 Mar 2002 07:36: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 HAA01933; Fri, 22 Mar 2002 07:36: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 g2MFZZKL028070 for ; Fri, 22 Mar 2002 07:35:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MFZYJ0028069 for mobile-ip-dist; Fri, 22 Mar 2002 07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFZVKL028062 for ; Fri, 22 Mar 2002 07:35:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01648 for ; Fri, 22 Mar 2002 07:35:32 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21153 for ; Fri, 22 Mar 2002 07:35:23 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2MFZUkY013359 for ; Fri, 22 Mar 2002 16:35:30 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Mar 22 16:35:29 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 16:37:00 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380373112A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com, Singh Ajoy-ASINGH1 Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Fri, 22 Mar 2002 16:35: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: > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 20, 2002 4:50 AM > To: mobile-ip@sunroof.eng.sun.com; Singh Ajoy-ASINGH1 > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Gentlemen, > > > => Agreed. So a network initiation in WLAN is > > currently not possible as far as I know. > > I read the paper that Ajoy sent and I think > > it's more thant enough for WLANs. > > > > Not so fast. > > There is a problem on the mobile side as well in that the 802.11 > standard *protocol* doesn't provide any signal prior to handover, it > just reassociates. Now, it is possible, depending on the > 802.11 card and > driver, to force handover to a particular access point, > note power level > and indicate when handover is likely and where, etc., but > this is not > the same as getting a definitive L2 trigger saying when handover is > going to occur and where the MN will go, and it is *most > definitively* > not portable. Some NIC cards/drivers support it, others don't. => Sure, but we never assumed that 802.11 was connection-oriented. The assumption was that this is an implementation issue. The paper Ajoy referred to, shows that windows already supports this. > As an example of a problem that could occur, suppose the > driver makes an > assumption, based on power levels, that the MN is going to handover > somewhere and the IP level starts performing prehandover > care of address > change. The standard has no commitment that the handover > will, in fact, > occur, and it could equally well be aborted and the MN > could handover to > another access point. => The handover is decided by the MN. So if the MN decided in the last minute (so to speak) to change AP, then maybe there will be no time for anticipation. But I think Handover failures are possible in any scenario, there is not much we can do about this on the IP layer. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 22 11:02:26 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 LAA24637 for ; Fri, 22 Mar 2002 11:02:26 -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 JAA12531; Fri, 22 Mar 2002 09:01:53 -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 IAA08962; Fri, 22 Mar 2002 08:01: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 g2MG0kKL028248 for ; Fri, 22 Mar 2002 08:00:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MG0jlT028247 for mobile-ip-dist; Fri, 22 Mar 2002 08:00: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 g2MG0gKL028240 for ; Fri, 22 Mar 2002 08:00: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 IAA19937 for ; Fri, 22 Mar 2002 08:00:43 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12939 for ; Fri, 22 Mar 2002 09:00:41 -0700 (MST) Received: from T23KEMPF (dhcp116.docomolabs-usa.com [172.21.96.116]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2MG0eI26734; Fri, 22 Mar 2002 08:00:40 -0800 (PST) Message-ID: <008d01c1d1ba$7db4d5d0$1b6015ac@T23KEMPF> From: "James Kempf" To: , "Singh Ajoy-ASINGH1" References: <4DA6EA82906FD511BE2F00508BCF05380373112A@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Fri, 22 Mar 2002 07:59:03 -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 handover is decided by the MN. So if the MN decided > in the last minute (so to speak) to change AP, then > maybe there will be no time for anticipation. But > I think Handover failures are possible in any scenario, there > is not much we can do about this on the IP layer. > Well, there is an issue in FMIPv6 about when to start forwarding packets through the tunnel to the MN on the new link. If there is no signal on the router at Link Down, then the tunnel must start when the F-BU is received by the old access router. This results in termination of packet delivery prior to the actual Layer 2 handover, and thus more lost packets than if a Link Down trigger is available. So I think having a Link Down trigger in 802.11 would be helpful for this. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 22 11:28: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 LAA25281 for ; Fri, 22 Mar 2002 11:28:28 -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 JAA27635; Fri, 22 Mar 2002 09:27: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 IAA16791; Fri, 22 Mar 2002 08:27: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 g2MGR2KL028341 for ; Fri, 22 Mar 2002 08:27:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MGR21e028340 for mobile-ip-dist; Fri, 22 Mar 2002 08:27: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 g2MGQxKL028333 for ; Fri, 22 Mar 2002 08:26: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 IAA25880 for ; Fri, 22 Mar 2002 08:26:59 -0800 (PST) Received: from penguin.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 JAA27047 for ; Fri, 22 Mar 2002 09:26:58 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2MGQvkY002509 for ; Fri, 22 Mar 2002 17:26:58 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Mar 22 17:26:52 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 17:28:23 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB60@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Singh Ajoy-ASINGH1 Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Fri, 22 Mar 2002 17:26: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: > > => The handover is decided by the MN. So if the MN decided > > in the last minute (so to speak) to change AP, then > > maybe there will be no time for anticipation. But > > I think Handover failures are possible in any scenario, there > > is not much we can do about this on the IP layer. > > > > Well, there is an issue in FMIPv6 about when to start > forwarding packets > through the tunnel to the MN on the new link. If there is > no signal on > the router at Link Down, then the tunnel must start when the F-BU is > received by the old access router. This results in > termination of packet > delivery prior to the actual Layer 2 handover, and thus more lost > packets than if a Link Down trigger is available. > => Which is one of the reasons for bicasting. > So I think having a Link Down trigger in 802.11 would be helpful for > this. > => Sure, the trigger is needed. I wanted this trigger mainly for the multi-interfaced hosts. Applying this to the single interfaced host would mean two things: - The host can be multi-homed for a short period. I.e. The host connects to two ARs at the same time (on the IP layer of course). - This connection to both ARs, is represented at the IP layer as 2 interfaces. Because you need to identify which interface is up or down. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 22 12:17: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 MAA26348 for ; Fri, 22 Mar 2002 12:17: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 KAA21539; Fri, 22 Mar 2002 10:16: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 JAA07868; Fri, 22 Mar 2002 09:16: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 g2MHEvKL028592 for ; Fri, 22 Mar 2002 09:14:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MHEvei028591 for mobile-ip-dist; Fri, 22 Mar 2002 09: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHEsKL028584 for ; Fri, 22 Mar 2002 09:14:54 -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 JAA02582 for ; Fri, 22 Mar 2002 09:14:55 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08417 for ; Fri, 22 Mar 2002 10:14:55 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA05898 for ; Fri, 22 Mar 2002 10:03:41 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA11548 for ; Fri, 22 Mar 2002 10:02:53 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 22 Mar 2002 11:14:54 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Fri, 22 Mar 2002 11:14:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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: -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Friday, March 22, 2002 9:35 AM To: mobile-ip@sunroof.eng.sun.com; Singh Ajoy-ASINGH1 Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 20, 2002 4:50 AM > To: mobile-ip@sunroof.eng.sun.com; Singh Ajoy-ASINGH1 > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Gentlemen, > > > => Agreed. So a network initiation in WLAN is > > currently not possible as far as I know. > > I read the paper that Ajoy sent and I think > > it's more thant enough for WLANs. > > > > Not so fast. > > There is a problem on the mobile side as well in that the 802.11 > standard *protocol* doesn't provide any signal prior to handover, it > just reassociates. Now, it is possible, depending on the > 802.11 card and > driver, to force handover to a particular access point, > note power level > and indicate when handover is likely and where, etc., but > this is not > the same as getting a definitive L2 trigger saying when handover is > going to occur and where the MN will go, and it is *most > definitively* > not portable. Some NIC cards/drivers support it, others don't. => Sure, but we never assumed that 802.11 was connection-oriented. The assumption was that this is an implementation issue. The paper Ajoy referred to, shows that windows already supports this. Ajoy-> The paper seems to indicate that it is possible to support this in some WLAN driver. But frankly we have not been able to realize this in our lab setup. I would still think having IEEE to provide some standard mechanism to support L2 triggers will be really helpful. > As an example of a problem that could occur, suppose the > driver makes an > assumption, based on power levels, that the MN is going to handover > somewhere and the IP level starts performing prehandover > care of address > change. The standard has no commitment that the handover > will, in fact, > occur, and it could equally well be aborted and the MN > could handover to > another access point. => The handover is decided by the MN. So if the MN decided in the last minute (so to speak) to change AP, then maybe there will be no time for anticipation. But I think Handover failures are possible in any scenario, there is not much we can do about this on the IP layer. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 22 12:37: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 MAA26996 for ; Fri, 22 Mar 2002 12:37:53 -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 KAA10565; Fri, 22 Mar 2002 10:37: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 JAA09600; Fri, 22 Mar 2002 09:37: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 g2MHaMKL028784 for ; Fri, 22 Mar 2002 09:36:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MHaMCu028783 for mobile-ip-dist; Fri, 22 Mar 2002 09:36: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 g2MHaJKL028776 for ; Fri, 22 Mar 2002 09:36:19 -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 JAA01989 for ; Fri, 22 Mar 2002 09:36:21 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21442 for ; Fri, 22 Mar 2002 10:36:20 -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 g2MHaIoq029823 for ; Fri, 22 Mar 2002 18:36:19 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 22 18:36:18 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 18:36:18 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB6B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Fri, 22 Mar 2002 18:36: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: > => Sure, but we never assumed that 802.11 was connection-oriented. > The assumption was that this is an implementation issue. > The paper Ajoy referred to, shows that windows already > supports this. > > Ajoy-> The paper seems to indicate that it is possible to support > this in some WLAN driver. But frankly we have not been able to > realize this in our lab setup. I would still think having > IEEE to provide > some standard mechanism to support L2 triggers will be > really helpful. => Ideally, yes. But I just didn't think that any SDO can mandate an API that is internal to a device. If they do then it would be great! Unless they want to go down the track of making WLANs connection-oriented, which is a major change in the WLAN design philosophy. Hesham > > > > As an example of a problem that could occur, suppose the > > driver makes an > > assumption, based on power levels, that the MN is going > to handover > > somewhere and the IP level starts performing prehandover > > care of address > > change. The standard has no commitment that the handover > > will, in fact, > > occur, and it could equally well be aborted and the MN > > could handover to > > another access point. > > => The handover is decided by the MN. So if the MN decided > in the last minute (so to speak) to change AP, then > maybe there will be no time for anticipation. But > I think Handover failures are possible in any scenario, there > is not much we can do about this on the IP layer. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 22 13:35: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 NAA28260 for ; Fri, 22 Mar 2002 13:35: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 KAA13879; Fri, 22 Mar 2002 10:34:13 -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 KAA29436; Fri, 22 Mar 2002 10:33: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 g2MIWrKL028965 for ; Fri, 22 Mar 2002 10:32:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MIWr9P028964 for mobile-ip-dist; Fri, 22 Mar 2002 10:32: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MIWoKL028957 for ; Fri, 22 Mar 2002 10:32:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06248 for ; Fri, 22 Mar 2002 10:32:50 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24950 for ; Fri, 22 Mar 2002 10:32:52 -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 g2MIWkD27321; Fri, 22 Mar 2002 12:32:46 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 12:32:47 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCAF9@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" , "'Charles E. Perkins'" , "'Pete McCann'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Fri, 22 Mar 2002 12:32:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1CF.F6932B40" Sender: owner-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_01C1D1CF.F6932B40 Content-Type: text/plain; charset="iso-8859-1" Hi Pete; With the understanding as in my response to Charlie in the previous email. There is no backward compatibility issue with existing HA (RFC2002 & RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension (see previous email) There are several places where we need to address the issue of EXACTLY vs. At least. The following are the proposed texts: 1. 8.2.1. Validity Checks Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded by the home agent. The authentication in the Registration Request MUST be checked. This involves the following operations: a) The home agent MUST check for the presence of at least one authorization-enabling extension, and perform only one of the indicated authentication(s). At least one authorization-enabling extension MUST be present in the Registration Request; and the home agent MUST either check the Authenticator value in the extension or verify that the authenticator value has been checked by another agent with which it has a security association. If no authorization-enabling extension is found, or if the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 131. The home agent MUST then discard the Request and SHOULD log the error as a security exception. If the home agent receives a Registration Request without a Mobile-Home Authentication extension from a Mobile Node that does not have a security association with this home agent, the home agent MAY discard the Mobile Node's Registration Request. b) The home agent MUST check that the registration Identification field is correct using the context selected by the SPI within the authorization-enabling extension that the home agent used to authenticate the Mobile Node's Registration Request. See Section 5.7 for a description of how this is performed. If incorrect, the home agent MUST reject the Request and SHOULD send a Registration Reply to the mobile node with Code 133, including an Identification field computed in accordance with the rules specified in Section 5.7. The home agent MUST do no further processing with such a Request, though it SHOULD log the error as a security exception. 2. A minor correction: section 3.8.2.3 should read "If the Registration Request does not satisfy all of the validity checks in Section 3.8.2.1,..." NOT "If the Registration Reply does not satisfy all of the validity checks in Section 3.8.2.1,... 3. A slight change to your proposed text for section 3.6.1.3 item (e) (e) An authorization-enabling extension other than mobile-home authentication, if present, followed by Otherwise, the text will allow the possibility of having two Mobile-Home Authentication extension in the RRQ. Thanks for consideration Regards; Ahmad Muhanna -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Wednesday, March 20, 2002 10:37 AM To: Charlie Perkins Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' Subject: Re: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) Hi, Charlie, Ok, understanding the urgency, how about the following text: Change the first paragraph of Section 3.5.2 to read: At least one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent. This requirement is intended to eliminate problems [2] which result from the uncontrolled propagation of remote redirects in the Internet. The location of the extension marks the end of the authenticated data covered by that extension. The Mobile-Home Authentication Extension is always an authorization-enabling for registration messages specified in this document; future specifications may define additional authorization-enabling extensions. And the first sentence of Section 3.6: A mobile node MUST be configured with a netmask and a mobility security association for each of its pre-assigned home agents or home agents that could be discovered on a home subnet according to procedures in Section 3.6.1.2. Also, I assume that the missing text people have been discussing covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I can't find it there now. Also, I think the text in 3.6.1.3 (section header currently missing) needs to change to: a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be useful to the foreign agent), followed by c) A mobile-home authentication extension, if present, followed by d) If present, any non-authentication Extensions used only by the foreign agent, followed by e) An authorization-enabling extension, if present, followed by f) The Mobile-Foreign Authentication Extension, if present. Note that item (a) and at least one of (c) or (e) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (f) are optional. However, item (f) MUST be included when the mobile node and the foreign agent share a mobility security association. I think that should do it. -Pete Charlie Perkins writes: > > Hello Pete, > > Pete McCann wrote: > > > I believe we will need to update the MN-HA key in the first RRQ/RRP, > > sometimes. > > > > Maybe the right approach is to update the text in 3220 to explicitly > > allow zero security associations with home agents, if some other > > "authorization enabling extension" is present in the message. > > If so, the time to do so would be this week, so that we can get it in at > the same time we supply the mysteriously vanished text, and update the > "exactly one", and relieve the possibility for misinterpretation that was > noticed during Connectathon. > > Regards, > Charlie P. > > ------_=_NextPart_001_01C1D1CF.F6932B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A proposal for resolving a very Possible = conflictbetween RFC3220 & RFC3012 (RFC3012bis)

Hi Pete;

With the understanding as in my response to Charlie = in the previous email.
There is no backward compatibility issue with = existing HA (RFC2002 & RFC3012) receiving a RRQ message with ONLY a = MN-AAA authentication extension (see previous email)

There are several places where we need to address the = issue of EXACTLY vs. At least. The following are the proposed = texts:

1.      8.2.1. Validity = Checks

   Registration Requests with an invalid, = non-zero UDP checksum MUST be
   silently discarded by the home = agent.

   The authentication in the Registration = Request MUST be checked.  This
   involves the following = operations:

      a) The home agent MUST = check for the presence of at least one
         = authorization-enabling extension, and perform only one of the = indicated
         = authentication(s).  At least one authorization-enabling = extension
         = MUST be present in the Registration Request; and the home agent
         = MUST either check the Authenticator value in the extension or
         = verify that the authenticator value has been checked by another
         = agent with which it has a security association.  If no
         = authorization-enabling extension is found, or if the
         = Authenticator is invalid, the home agent MUST reject the mobile
         = node's registration and SHOULD send a Registration Reply to the
         = mobile node with Code 131.  The home agent MUST then = discard
         the = Request and SHOULD log the error as a security exception.
         If = the home agent receives a Registration Request without a = Mobile-Home
         = Authentication extension from a Mobile Node that does not have a =
         = security association with this home agent, the home agent MAY
         = discard the Mobile Node's Registration Request.


     b) The home agent MUST check = that the registration Identification
         = field is correct using the context selected by the SPI within
         the = authorization-enabling extension that the home agent used to = authenticate the
         = Mobile Node's Registration Request.  See Section 5.7 for a = description of how this is performed. 
         If = incorrect, the home agent MUST reject the Request and SHOULD
         = send a Registration Reply to the mobile node with Code 133, including = an
         = Identification field computed in accordance with the rules
         = specified in Section 5.7.  The home agent MUST do no = further
         = processing with such a Request, though it SHOULD log the error
         as = a security exception.

2.      A minor = correction:
        section = 3.8.2.3 should read
        "If = the Registration Request does not satisfy all of the validity = checks
        in Section = 3.8.2.1,..."

        NOT =
        "If = the Registration Reply does not satisfy all of the validity = checks
        in Section = 3.8.2.1,...

3.      A slight change to = your proposed text for section 3.6.1.3 item (e)

        (e) An = authorization-enabling extension other than mobile-home authentication, = if present, followed by

        Otherwise, = the text will allow the possibility of having two Mobile-Home = Authentication extension in the RRQ.


Thanks for = consideration       

Regards;
Ahmad Muhanna



-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Wednesday, March 20, 2002 10:37 AM
To: Charlie Perkins
Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; = 'mobile-ip@sunroof.eng.sun.com'
Subject: Re: [mobile-ip] A proposal for resolving a = very Possible
conflictbetween RFC3220 & RFC3012 = (RFC3012bis)



Hi, Charlie,

Ok, understanding the urgency, how about the = following text:

Change the first paragraph of Section 3.5.2 to = read:

  At least one authorization-enabling extension = MUST be present in all
  Registration Requests, and also in all = Registration Replies generated
  by the Home Agent.  This requirement is = intended to eliminate problems
  [2] which result from the uncontrolled = propagation of remote redirects
  in the Internet.  The location of the = extension marks the end of the
  authenticated data covered by that = extension.

  The Mobile-Home Authentication Extension is = always an
  authorization-enabling for registration = messages specified in this
  document; future specifications may define add= itional
  authorization-enabling extensions.

And the first sentence of Section 3.6:

   A mobile node MUST be configured with a = netmask and a mobility
   security association for each of its = pre-assigned home agents or
   home agents that could be discovered on = a home subnet according
   to procedures in Section = 3.6.1.2.

Also, I assume that the missing text people have been = discussing
covers the subnet-directed broadcast discovery = mechanism in 3.6.1.2; I
can't find it there now.

Also, I think the text in 3.6.1.3 (section header = currently missing)
needs to change to:

      a) The IP header, = followed by the UDP header, followed by the
         = fixed-length portion of the Registration Request, followed by

      b) If present, any = non-authentication Extensions expected to be
         = used by the home agent (which may or may not also be useful to
         the = foreign agent), followed by

      c) A mobile-home = authentication extension, if present, followed by

      d) If present, any = non-authentication Extensions used only by the
         = foreign agent, followed by

      e) An = authorization-enabling extension, if present, followed by

      f) The Mobile-Foreign = Authentication Extension, if present.

   Note that item (a) and at least one of = (c) or (e) MUST appear in
   every Registration Request sent by the = mobile node.  Items (b), (d),
   and (f) are optional.  However, = item (f) MUST be included when the
   mobile node and the foreign agent share = a mobility security
   association.


I think that should do it.

-Pete






Charlie Perkins writes:
 >
 > Hello Pete,
 >
 > Pete McCann wrote:
 >
 > > I believe we will need to update the = MN-HA key in the first RRQ/RRP,
 > > sometimes.
 > >
 > > Maybe the right approach is to = update the text in 3220 to explicitly
 > > allow zero security associations = with home agents, if some other
 > > "authorization enabling = extension" is present in the message.
 >
 > If so, the time to do so would be this = week, so that we can get it in at
 > the same time we supply the mysteriously = vanished text, and update the
 > "exactly one", and relieve the = possibility for misinterpretation that was
 > noticed during Connectathon.
 >
 > Regards,
 > Charlie P.
 >
 >

------_=_NextPart_001_01C1D1CF.F6932B40-- From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 23 08:43: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 IAA21630 for ; Sat, 23 Mar 2002 08:43: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 GAA22427; Sat, 23 Mar 2002 06:43: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 FAA18732; Sat, 23 Mar 2002 05:43: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 g2NDgYKL000516 for ; Sat, 23 Mar 2002 05:42:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NDgY5t000515 for mobile-ip-dist; Sat, 23 Mar 2002 05: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NDgVKL000508 for ; Sat, 23 Mar 2002 05:42:31 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08348 for ; Sat, 23 Mar 2002 05:42:32 -0800 (PST) Received: from WS0005.indiatimes.com ([203.199.93.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29418 for ; Sat, 23 Mar 2002 05:42:23 -0800 (PST) Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id TAA13546 for ; Sat, 23 Mar 2002 19:02:46 +0530 From: "gaurav_puri98" Message-Id: <200203231332.TAA13546@WS0005.indiatimes.com> To: Subject: [mobile-ip] regarding draft 16 Date: Sat, 23 Mar 2002 19:08:42 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2002323619842846930886" MIME-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=_MAILER_ATTACH_BOUNDARY1_2002323619842846930886 Content-Type: text/plain; charset=us-ascii hi all, i just went through the draft 16. the changes which were mentioned in the differences pdf "mipv6-modified-parts-pre16.pdf" have not been reflected in the draft. for example the draft still talks about BU , BAck as destination options and not as MH messages. there are many more such changes which need to be reflected in the new draft. regards gaurav Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_2002323619842846930886 Content-Type: text/html; charset=us-ascii

hi all,

  i just went through the draft 16. the changes which were mentioned in the differences pdf  "mipv6-modified-parts-pre16.pdf" have not been reflected in the draft.  for example the draft still talks about BU , BAck as destination options and not as MH messages. there are many more such changes which need to be reflected in the new draft.

regards

  gaurav

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_2002323619842846930886-- From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 23 09:52: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 JAA22143 for ; Sat, 23 Mar 2002 09:52:34 -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 GAA23956; Sat, 23 Mar 2002 06:52: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 GAA19032; Sat, 23 Mar 2002 06:52: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 g2NEp7KL000625 for ; Sat, 23 Mar 2002 06:51:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NEp7bb000624 for mobile-ip-dist; Sat, 23 Mar 2002 06:51: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 g2NEp3KL000617 for ; Sat, 23 Mar 2002 06:51:03 -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 GAA02967 for ; Sat, 23 Mar 2002 06:51:03 -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 HAA03775 for ; Sat, 23 Mar 2002 07:51:02 -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 g2NEoTK22752; Sat, 23 Mar 2002 06:50:29 -0800 (PST) Received: from cisco.com (sjc-vpn2-229.cisco.com [10.21.112.229]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACE26001; Sat, 23 Mar 2002 06:50:03 -0800 (PST) Message-ID: <3C9C9633.8BE86C6B@cisco.com> Date: Sat, 23 Mar 2002 06:50:27 -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 CC: henrik@levkowetz.com, sami.vaarala@iki.com Subject: [mobile-ip] question on NAT traversal for MIP draft (v 01.txt) 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, For the NAT Traversal for MIP draft, I am concerned about section 4.5 Foreign Agent Considerations The last paragraph on page 16 indicates that FA may add the UDP Tunnel request extension even when FHAE is not present. I am not comfortable with this statement. It should be added only if FHAE is present or else it is a security hole - a third party can append this extension before RRQ is fowarded to HA. On the other hand, I agree that this makes it difficult to scale as it introduces the classic key distribution problem. Was this deliberate or overlooked. Can someone educate me on it. thx -a From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 23 13:12: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 NAA23790 for ; Sat, 23 Mar 2002 13:12:24 -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 LAA05265; Sat, 23 Mar 2002 11:11: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 KAA26343; Sat, 23 Mar 2002 10:11: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 g2NIAiKL001115 for ; Sat, 23 Mar 2002 10:10:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NIAhKp001114 for mobile-ip-dist; Sat, 23 Mar 2002 10: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 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 g2NIAcKL001100 for ; Sat, 23 Mar 2002 10:10:38 -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 g2NIAYx27252; Sat, 23 Mar 2002 19:10:34 +0100 (MET) Date: Sat, 23 Mar 2002 19:10:23 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: MIPv6 Internet Draft To: jari.arkko@piuha.net Cc: Mike Roe , 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: > Also, I think it was Erik who wondered if we might actually have a field > in the [HC]OT message to describe the expected (or committed?) lifetime of > the cookie, helping the MN decide whether it should redo something later or > not. This would bring some additional complexity though, and the MN has no > assurance in any case that the cookies really can be used anyway so perhaps > we should just have a recommendation and allow MNs to optimistically try > these things within those recommended limits. Or what do you think? The motivation for this was to give the MN hits to help it when retransmitting in the face of packet loss (an issue I didn't get to in the meeting - it's in the slides). Basically if the MN doesn't receive a HoT or CoT it needs to retransmit the HoTI and CoTI, respectively. And if it doesn't receive a BA (when the BU had the A bit set) it needs to retransmit the BU. For these reasons the cookies used to form the authenticator in the BU might be old. If they are too old the CN will reject it with an error. But it would see very useful to give the MN a hint for how long time it can retransmit using the old cookies. I think a time around 20-30 seconds would be reasonable. THis would allow several retransmissions with binary exponential backoff. When this time has expired, or a BA with a "too old home nonce index" or "too old care-of nonce index" error is received, the MN would need to start over with the CoTI/HoTI. An observation is that this also allows the MN to reuse the home cookie during frequent movement for this time period, which would be a useful optimization that Charlie and Jari M. suggested. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 23 19:45: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 TAA27000 for ; Sat, 23 Mar 2002 19:45:57 -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 RAA23692; Sat, 23 Mar 2002 17:45: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 QAA20530; Sat, 23 Mar 2002 16:45: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 g2O0i6KL001976 for ; Sat, 23 Mar 2002 16:44:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2O0i6mG001975 for mobile-ip-dist; Sat, 23 Mar 2002 16: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2O0i3KL001968 for ; Sat, 23 Mar 2002 16:44:03 -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 QAA28550 for ; Sat, 23 Mar 2002 16:44:04 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23384 for ; Sat, 23 Mar 2002 17:44:03 -0700 (MST) Received: from AlperVAIO (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2O0hxI28887 for ; Sat, 23 Mar 2002 16:44:00 -0800 (PST) Message-ID: <024f01c1d2cc$08e018b0$231eae42@AlperVAIO> From: "Alper E. YEGIN" To: References: <4DA6EA82906FD511BE2F00508BCF05380373112A@Esealnt861.al.sw.ericsson.se> <008d01c1d1ba$7db4d5d0$1b6015ac@T23KEMPF> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Sat, 23 Mar 2002 16:37:05 -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.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 > So I think having a Link Down trigger in 802.11 would be helpful for > this. Also AP will have to tell this information to the Access Router. This is where a "protocol" for L2 triggers is needed. alper From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 23 22:42: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 WAA00590 for ; Sat, 23 Mar 2002 22:42: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 UAA19892; Sat, 23 Mar 2002 20:41: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 TAA21941; Sat, 23 Mar 2002 19:41: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 g2O3eZKL002233 for ; Sat, 23 Mar 2002 19:40:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2O3eZcR002232 for mobile-ip-dist; Sat, 23 Mar 2002 19: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 g2O3eWKL002225 for ; Sat, 23 Mar 2002 19: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 TAA10511 for ; Sat, 23 Mar 2002 19:40:33 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA02215 for ; Sat, 23 Mar 2002 20:40:31 -0700 (MST) Received: from T23KEMPF (dhcp165.docomolabs-usa.com [172.21.96.165]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2O3eTI00767; Sat, 23 Mar 2002 19:40:29 -0800 (PST) Message-ID: <001501c1d2e5$6bef8e90$a56015ac@T23KEMPF> From: "James Kempf" To: , "Singh Ajoy-ASINGH1" References: <4DA6EA82906FD511BE2F00508BCF053802C6AB60@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Sat, 23 Mar 2002 19:38: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 > => Which is one of the reasons for bicasting. > Right, but the old AR still needs to know when to stop sending the packets and flush its neighbor cache. If the F-BU comes through prior to the MN moving, what's the signal? Also, there were some other questions raised about bicasting around the effect on reliable transports that need resolution, we're planning on looking into experimentally them soon. > > So I think having a Link Down trigger in 802.11 would be helpful for > > this. > > > > => Sure, the trigger is needed. I wanted this trigger > mainly for the multi-interfaced hosts. Applying this to > the single interfaced host would mean two things: > > - The host can be multi-homed for a short period. > I.e. The host connects to two ARs at the same time > (on the IP layer of course). > > - This connection to both ARs, is represented at > the IP layer as 2 interfaces. Because you need to > identify which interface is up or down. > How can the host connect to two ARs if there is only one interface? Are you assuming soft handover, i.e. that the host can also be connected to two ARs at layer 2? Or are you assuming that the host has a connection to the new AR through the old AR, like in FMIPv4? jak From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 23 23:02: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 XAA00792 for ; Sat, 23 Mar 2002 23:02: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 VAA22915; Sat, 23 Mar 2002 21:02: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 UAA24778; Sat, 23 Mar 2002 20:02: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 g2O41VKL002375 for ; Sat, 23 Mar 2002 20:01:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2O41VdH002374 for mobile-ip-dist; Sat, 23 Mar 2002 20:01: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 g2O41SKL002367 for ; Sat, 23 Mar 2002 20:01:28 -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 UAA04613 for ; Sat, 23 Mar 2002 20:01:29 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA28741 for ; Sat, 23 Mar 2002 21:01:28 -0700 (MST) Received: from T23KEMPF (dhcp165.docomolabs-usa.com [172.21.96.165]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2O41QI01028 for ; Sat, 23 Mar 2002 20:01:26 -0800 (PST) Message-ID: <005d01c1d2e8$592272c0$a56015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6AB6B@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Sat, 23 Mar 2002 19:59: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 Hesham, > => Ideally, yes. But I just didn't think > that any SDO can mandate an API that is internal > to a device. If they do then it would be great! > Unless they want to go down the track of making > WLANs connection-oriented, which is a major change > in the WLAN design philosophy. > I don't think this has anything to do with mandating a particular API. I should probably look more closely at the standard, but from talking to people who know it better, I don't believe the 802.11 standard has the kind of strict power levels for handoff that other radio protocols have, such that if the power dips below a certain level, then handoff to another access point with the highest power level is certain. I believe it is left up to the implementors to determine this. Anybody who knows the 802.11 standard better than I, please correct me if I am wrong. I don't believe this has anything to do with whether the WLAN is connection oriented or not, it just involves how they define a standard-conformant implementation w.r.t. handover. If that's so, then the actual implementation will vary widely and make it difficult to implement a consistent L2 trigger. Standardizing something along these lines would help proactive mobile controlled handoff. jak From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 24 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 PAA17470 for ; Sun, 24 Mar 2002 15:34:11 -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 NAA02632; Sun, 24 Mar 2002 13:33: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 MAA27768; Sun, 24 Mar 2002 12:33: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 g2OKVaKL003413 for ; Sun, 24 Mar 2002 12:31:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2OKVZkU003412 for mobile-ip-dist; Sun, 24 Mar 2002 12:31: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 g2OKVWKL003405 for ; Sun, 24 Mar 2002 12:31:32 -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 MAA11524 for ; Sun, 24 Mar 2002 12:31:32 -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 NAA15234; Sun, 24 Mar 2002 13:31: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 g2OKVSk28893; Sun, 24 Mar 2002 14:31:28 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 24 Mar 2002 14:31:37 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCAFB@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" Cc: "'Steven.Glass@Sun.COM'" , "'mchandra@cisco.com'" Subject: [mobile-ip] Question about the I Bit in the Revocation Acknowledgement Messag e Date: Sun, 24 Mar 2002 14:31:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D372.E454F4F0" Sender: owner-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_01C1D372.E454F4F0 Content-Type: text/plain; charset="iso-8859-1" Hello all; I have the following question about the I bit in the Revocation Acknowledgement Message as mentioned in section 4.3. in the recent I-D version 02: " I Inform bit. Set to '1' by the foreign agent to ask the home agent if the mobile node should be informed of the revocation. " If the Foreign Agent is sending this message to acknowledge receiving a Revocation Message what does the above text mean? Thanks for your consideration and help. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1D372.E454F4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question about the I Bit in the Revocation Acknowledgement = Message

Hello all;

I have the following question about = the I bit in the Revocation Acknowledgement Message as mentioned in = section 4.3. in the recent I-D version 02:

"
I         &n= bsp;    Inform bit.

         &nb= sp;     Set to '1' by the foreign agent to ask the = home agent
         &nb= sp;     if the mobile node should be informed of = the
         &nb= sp;     revocation.
"

If the Foreign Agent is sending this = message to acknowledge receiving a Revocation Message what does the = above text mean?


Thanks for your consideration and = help.

         &nb= sp;    
Regards;
Ahmad Muhanna


------_=_NextPart_001_01C1D372.E454F4F0-- From owner-mobile-ip@sunroof.eng.sun.com Sun Mar 24 17:47: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 RAA19387 for ; Sun, 24 Mar 2002 17:47: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 PAA24416; Sun, 24 Mar 2002 15:46: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 OAA08777; Sun, 24 Mar 2002 14:46: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 g2OMjsKL003641 for ; Sun, 24 Mar 2002 14:45:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2OMjs9J003640 for mobile-ip-dist; Sun, 24 Mar 2002 14:45: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 g2OMjoKL003633 for ; Sun, 24 Mar 2002 14:45:50 -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 OAA16499 for ; Sun, 24 Mar 2002 14:45:51 -0800 (PST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29458 for ; Sun, 24 Mar 2002 15:45:50 -0700 (MST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2OMjnJ03858 for ; Sun, 24 Mar 2002 17:45:49 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA24475; Sun, 24 Mar 2002 16:45:47 -0600 (CST) Message-ID: <3C9E56DA.5FE0F72@lucent.com> Date: Sun, 24 Mar 2002 16:44:42 -0600 From: Tom Hiller Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RR frequency and cdma2000 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, The draft states: > 14.3. Security for the Binding Updates to the Correspondent Nodes > [..] For this reason, this specification limits > the validity of RR authorized bindings to a maximum of five minutes > after the last RR check has been performed. In cdma2000 spectrum is expensive and quite a lot of attention is given to minimizing control/signaling overhead, not to mention compressing packet headers. Having to send the RR check messages every five minutes is an issue. Also, after mobile sends data it stays active some number of seconds (like 20-30) beyond the last bit sent. The five minute requirement implies that mobiles using the RR check would be active 5-10% of the time even when they have nothing to send because they have to wake up every five minutes just to do the RR check. That's a problem. If the CN is a voice gateway or conference bridge that is owned by the same carrier that owns the HA, and the route between the HA and CN resides within the carrier, the risk of an attacker being able to monitor the CN-HA route could be zero for practical purposes. Another case would be if the mobile runs TLS above MIPv6. It doesn't seem that frequent RRs buy very much. Is it really necessary to mandate a five minute lifetime for all applications? thanks, Tom Hiller From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 03:49: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 DAA05559 for ; Mon, 25 Mar 2002 03:49:44 -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 AAA27208; Mon, 25 Mar 2002 00:49: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 AAA19129; Mon, 25 Mar 2002 00:48: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 g2P8lTKL004352 for ; Mon, 25 Mar 2002 00:47:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2P8lTg7004351 for mobile-ip-dist; Mon, 25 Mar 2002 00:47: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 g2P8lPKL004344 for ; Mon, 25 Mar 2002 00:47: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 AAA09086 for ; Mon, 25 Mar 2002 00:47:25 -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 BAA11780 for ; Mon, 25 Mar 2002 01:47:23 -0700 (MST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA30824; Mon, 25 Mar 2002 09:44:27 +0100 From: "Henrik Levkowetz" To: "Alpesh S. Patel" , Cc: Subject: [mobile-ip] RE: question on NAT traversal for MIP draft (v 01.txt) Date: Mon, 25 Mar 2002 09:47:14 +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 V5.50.4910.0300 Importance: Normal In-Reply-To: <3C9C9633.8BE86C6B@cisco.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 Alpesh, Let us consider what a man-in-the-middle could accomplish by adding this extension? If he adds this extension, and changes the source address, then the HA will use UDP encapsulation, when it otherwise would not. The UDP encapsulated traffic will go to a wrong destination. This does not differ in any essential manner from changing the source address of a registration request without this extension. If the source address is not changed, the HA won't use UDP, except if the extension uses the Force bit. In this case, a reply will come back with a UDP Tunnelling extension. a)If the FA understands this, it will do de-tunnelling, and the traffic will flow normally, or it may have UDP tunnelling disabled, in which case it will not accept the reg. reply. b) If the FA does not understand this, it will reject the registration reply because it contains an extension it does not understand in the 0 to 127 range. So it seems to me that the extent of the attack is to force the use of UDP tunnelling where it is not needed, or to have the registration rejected. The latter can be done in easier ways. If this is the extent of the attack possible, I don't think it warrants requireing that this particular extension only be used with a Foreign-Home Authenticaiton-enabling Extension present. We might add text to indicate that FA's should only accept registration replies with UDP Tunnel extensions after the Mobile-Home Auth. Ext. when they are behind a NAT (and thus are advertising with the U bit set). Have I missed something? Best, Henrik > > Hi, > > For the NAT Traversal for MIP draft, I am concerned about section > 4.5 Foreign Agent Considerations > > The last paragraph on page 16 indicates that FA may add the UDP Tunnel > request extension even when FHAE is not present. I am not comfortable > with this statement. It should be added only if FHAE is present or else > it > is a security hole - a third party can append this extension before RRQ > is > fowarded to HA. > > On the other hand, I agree that this makes it difficult to scale as it > introduces > the classic key distribution problem. > > Was this deliberate or overlooked. Can someone educate me on it. > thx > -a From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 08:08:11 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 IAA08331 for ; Mon, 25 Mar 2002 08:08:10 -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 FAA03828; Mon, 25 Mar 2002 05:07: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 FAA06520; Mon, 25 Mar 2002 05: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 g2PD6QKL004653 for ; Mon, 25 Mar 2002 05:06:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PD6Qlt004652 for mobile-ip-dist; Mon, 25 Mar 2002 05:06: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 g2PD6MKL004645 for ; Mon, 25 Mar 2002 05:06:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29959 for ; Mon, 25 Mar 2002 05:06:23 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01150 for ; Mon, 25 Mar 2002 05:06:24 -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 IAA08141; Mon, 25 Mar 2002 08:06:20 -0500 (EST) Message-Id: <200203251306.IAA08141@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-ipv6-16.txt Date: Mon, 25 Mar 2002 08:06:19 -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 : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins Filename : draft-ietf-mobileip-ipv6-16.txt Pages : 146 Date : 21-Mar-02 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-16.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-ipv6-16.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-ipv6-16.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: <20020325080048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020325080048.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 11:57: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 LAA19805 for ; Mon, 25 Mar 2002 11:57: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 JAA04358; Mon, 25 Mar 2002 09:57:16 -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 IAA12285; Mon, 25 Mar 2002 08:57: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 g2PGuGKL005221 for ; Mon, 25 Mar 2002 08:56:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PGuG92005220 for mobile-ip-dist; Mon, 25 Mar 2002 08:56: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PGuCKL005213 for ; Mon, 25 Mar 2002 08:56:12 -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 IAA12068 for ; Mon, 25 Mar 2002 08:56:13 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14304 for ; Mon, 25 Mar 2002 09:56:12 -0700 (MST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2PGuEs15268 for ; Mon, 25 Mar 2002 10:56:19 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Mar 2002 10:55:55 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Mar 2002 10:55:50 -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] RR frequency and cdma2000 Date: Mon, 25 Mar 2002 10:55:50 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12A69@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] RR frequency and cdma2000 Thread-Index: AcHThfHqFR4gK0vuQhmYIut/OLgqdgAl9WPg From: "Patil Basavaraj (NET/Dallas)" To: Cc: "Tom Hiller" X-OriginalArrivalTime: 25 Mar 2002 16:55:50.0519 (UTC) FILETIME=[EB04E070:01C1D41D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2PGuDKL005214 Sender: owner-mobile-ip@sunroof.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, > >The draft states: > >> 14.3. Security for the Binding Updates to the Correspondent Nodes > >> [..] For this reason, this specification limits the validity of >> RR authorized bindings to a maximum of five minutes after the >> last RR check has been performed. > > > In cdma2000 spectrum is expensive and quite a lot of attention is > given to minimizing control/signaling overhead, not to mention > compressing packet headers. Having to send the RR check messages > every five minutes is an issue. > Also, after mobile sends data it stays active some number of seconds > (like 20-30) beyond the last bit sent. The five minute requirement > implies that mobiles using the RR check would be active 5-10% of the > time even when they have nothing to send because they have to wake up > every five minutes just to do the RR check. That's a problem. The lifetime of the entry in the BCE is 5 minutes. If the MN does not have an ongoing session (sending or receiving packets) it does not have to wake up to update the BCE in the CN. And CNs may simply let a BCE cache entry expire. CNs are not required to send a binding request to MNs for which they have a BCE. So the RR check would not be required. The RR check needs to be done only when you have an active session. The implication of the 5 minutes is that there would be additional messaging every 5 minutes in order to maintain RO between the MN and CN. > > If the CN is a voice gateway or conference bridge that is owned by > the same carrier that owns the HA, and the route between the HA and > CN resides within the carrier, the risk of an attacker being able to > monitor the CN-HA route could bezero for practical purposes. Another > case would be if the mobile runs TLS above MIPv6. It doesn't seem > that frequent RRs buy very much. > Well you have to remember that the RR based RO is for the cases where you do not have any infrastructure to verify the valdity of a home address claimed by an MN. In the above example, you would not be required to do RR at all. You could use an infrastructure based solution and establish a binding security association with the CN whose lifetime can be significantly higher. > Is it really necessary to mandate a five minute lifetime for all > applications? > RO itself is not required in all cases. If you are only doing a DNS query for example, you do not need to do RR and have RO traffic between the MN and the DNS server. > > thanks, > Tom Hiller -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 12:07: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 MAA20336 for ; Mon, 25 Mar 2002 12:07:10 -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 IAA08786; Mon, 25 Mar 2002 08:41:41 -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 HAA25914; Mon, 25 Mar 2002 07:41: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 g2PFeMKL005005 for ; Mon, 25 Mar 2002 07:40:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PFeM8k005004 for mobile-ip-dist; Mon, 25 Mar 2002 07:40: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 g2PFeIKL004997 for ; Mon, 25 Mar 2002 07:40:18 -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 HAA25736 for ; Mon, 25 Mar 2002 07:40:18 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04465 for ; Mon, 25 Mar 2002 08:40:17 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2PFeFI6018207 for ; Mon, 25 Mar 2002 07:40:15 -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 ABF43465; Mon, 25 Mar 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 HAA11098; Mon, 25 Mar 2002 07:40:14 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15519.17630.274251.283566@thomasm-u1.cisco.com> Date: Mon, 25 Mar 2002 07:40:14 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RR frequency and cdma2000 In-Reply-To: <3C9E56DA.5FE0F72@lucent.com> References: <3C9E56DA.5FE0F72@lucent.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 Tom Hiller writes: > In cdma2000 spectrum is expensive and quite a lot of attention is given to > minimizing control/signaling overhead, not to mention compressing packet > headers. Having to send the RR check messages every five minutes is an issue. > Also, after mobile sends data it stays active some number of seconds (like > 20-30) beyond the last bit sent. The five minute requirement implies that > mobiles using the RR check would be active 5-10% of the time even when they have > nothing to send because they have to wake up every five minutes just to do the > RR check. That's a problem. Let us not forget that route optimization is an _optimization_. A mobile node can be as selective as it likes about which streams it cares enough to straighten out triangular routing. For an RTP stream, this may be a completely reasonable tradeoff as the amount of RO signaling vs RTP streams @20ms packetization is miniscule. For other streams, it may not be worth it at all. Casual web browsing, IMO, probably wouldn't want to use RO at least until you hit some fairly large threshold of bandwidth or RTT. Also: you already need to be up to send and receive RTCP. Worse, the net is littered with stray packets that make the assumption of complete dormancy -- especially while the unit is active -- a tough assumption to make. I know that isn't > > If the CN is a voice gateway or conference bridge that is owned by the same > carrier that owns the HA, and the route between the HA and CN resides within the > carrier, the risk of an attacker being able to monitor the CN-HA route could be > zero for practical purposes. Another case would be if the mobile runs TLS above > MIPv6. It doesn't seem that frequent RRs buy very much. > > Is it really necessary to mandate a five minute lifetime for all applications? The problem is that the MN has absolutely no way to know for certain. A better option may be to use strong authentication (ipsec) in that case. I haven't read the current draft, but inital RR covered by strong authentication could relax the refresh period requirement, IMO. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 12:18: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 MAA20778 for ; Mon, 25 Mar 2002 12:18:24 -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 KAA03819; Mon, 25 Mar 2002 10:17: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 JAA00544; Mon, 25 Mar 2002 09:17: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 g2PHGjKL005802 for ; Mon, 25 Mar 2002 09:16:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PHGj08005801 for mobile-ip-dist; Mon, 25 Mar 2002 09:16: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 g2PHGgKL005794 for ; Mon, 25 Mar 2002 09:16:42 -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 JAA00330 for ; Mon, 25 Mar 2002 09:16:43 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25759 for ; Mon, 25 Mar 2002 10:16:42 -0700 (MST) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g2PHGfI6016399 for ; Mon, 25 Mar 2002 09:16: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 ABF45228; Mon, 25 Mar 2002 09:14:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11106; Mon, 25 Mar 2002 09:16:39 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15519.23415.546137.653362@thomasm-u1.cisco.com> Date: Mon, 25 Mar 2002 09:16:39 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RR frequency and cdma2000 In-Reply-To: <15519.17630.274251.283566@thomasm-u1.cisco.com> References: <3C9E56DA.5FE0F72@lucent.com> <15519.17630.274251.283566@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 Michael Thomas writes: > Also: you already need to be up to send and > receive RTCP. Worse, the net is littered with > stray packets that make the assumption of > complete dormancy -- especially while the unit > is active -- a tough assumption to make. I know > that isn't ... a brain fart. What I meant to say is that this isn't going to be especially popular with the connection oriented crowd, but reality is, well, reality; IP isn't connection oriented. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 13:10: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 NAA23351 for ; Mon, 25 Mar 2002 13:10:20 -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 LAA04845; Mon, 25 Mar 2002 11:09: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 KAA29498; Mon, 25 Mar 2002 10:09: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 g2PI8WKL006187 for ; Mon, 25 Mar 2002 10:08:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PI8WpZ006186 for mobile-ip-dist; Mon, 25 Mar 2002 10:08: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 g2PI8SKL006179 for ; Mon, 25 Mar 2002 10:08: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 KAA02651 for ; Mon, 25 Mar 2002 10:08:30 -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 LAA04103 for ; Mon, 25 Mar 2002 11:08:25 -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 TAA09836 for ; Mon, 25 Mar 2002 19:05:34 +0100 From: "Henrik Levkowetz" To: Subject: [mobile-ip] NAT traversal question from Minneapolis Date: Mon, 25 Mar 2002 19:08:21 +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 V5.50.4910.0300 Importance: Normal In-Reply-To: <15519.23415.546137.653362@thomasm-u1.cisco.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 Hi, There was one question posed on backward compatibility for the NAT traversal during the Mobile IP sesssion in Minneapolis. I'd like to explore the details of that, but I didn't catch the name of the questioner. Would you be kind enough to send me a mail on or off list? Best regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 13:26: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 NAA24444 for ; Mon, 25 Mar 2002 13:26:20 -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 LAA25916; Mon, 25 Mar 2002 11:25: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 KAA03986; Mon, 25 Mar 2002 10:25: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 g2PIObKL006428 for ; Mon, 25 Mar 2002 10:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PIOak0006427 for mobile-ip-dist; Mon, 25 Mar 2002 10:24: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 g2PIOXKL006420 for ; Mon, 25 Mar 2002 10:24: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 KAA23690 for ; Mon, 25 Mar 2002 10:24:33 -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 LAA25150 for ; Mon, 25 Mar 2002 11:24:33 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Mar 2002 13:22:51 -0500 Message-ID: From: Phil Roberts To: "MIP (mobile-ip@sunroof.eng.sun.com)" Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Date: Mon, 25 Mar 2002 13:22:50 -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: Hi folks, we received this note from Tony this morning. We would like to support alt 2 by generating a new draft describing the problem and incorporating the pieces from the deprecated GNAIE draft into it. They need this in a hurry, so we'd like to hear in advance if anyone has objection to this, otherwise we'll make it a working group item, and generate a WG last call on it straightaway. Phil -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Monday, March 25, 2002 1:59 AM To: proberts@megisto.com; basavaraj.patil@nokia.com Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com Subject: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil and Basavaraj, My name is Tony Johansson and as you may know I'm the new editor of the Diameter MIPv4 application. In process of solving the last remaining issue, it has been identified that the protocol is still lacking some major functionality in some cases of handoffs, since the Diameter MIPv4 application allows you to have more than one AAAH in the same subdomain of a realm. Please see, issue #299 and issue #301 at http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of the issues. During, the AAA working group meeting at IETF53 I presented the issues and two alternative ways in which we can workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. ---------------------------------------------------------------------------- -- AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this... Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. ---------------------------------------------------------------------------- - AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I would really need to get your opinion on this asap., so I know if I'm asking for the impossible or not :). Best Regards, Tony From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 13:49:35 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 NAA25949 for ; Mon, 25 Mar 2002 13:49:35 -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 LAA04860; Mon, 25 Mar 2002 11:49: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 KAA14603; Mon, 25 Mar 2002 10: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 g2PIlvKL006515 for ; Mon, 25 Mar 2002 10:47:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PIlvRo006514 for mobile-ip-dist; Mon, 25 Mar 2002 10: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PIlsKL006507 for ; Mon, 25 Mar 2002 10:47:54 -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 KAA11612 for ; Mon, 25 Mar 2002 10:47:54 -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 LAA26409 for ; Mon, 25 Mar 2002 11:47:54 -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 g2PIloa28978 for ; Mon, 25 Mar 2002 12:47:51 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 12:47:51 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCAFE@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Date: Mon, 25 Mar 2002 12:47:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D42D.8BDBF6F0" Sender: owner-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_01C1D42D.8BDBF6F0 Content-Type: text/plain; charset="iso-8859-1" Hi Phil; Please correct me if I am wrong. Tony is asking to use GAINE draft after what he thinks is a minor change. However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it. Is there any reason for this? Regards; Ahmad Muhanna -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, March 25, 2002 12:23 PM To: MIP (mobile-ip@sunroof.eng.sun.com) Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi folks, we received this note from Tony this morning. We would like to support alt 2 by generating a new draft describing the problem and incorporating the pieces from the deprecated GNAIE draft into it. They need this in a hurry, so we'd like to hear in advance if anyone has objection to this, otherwise we'll make it a working group item, and generate a WG last call on it straightaway. Phil -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Monday, March 25, 2002 1:59 AM To: proberts@megisto.com; basavaraj.patil@nokia.com Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com Subject: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil and Basavaraj, My name is Tony Johansson and as you may know I'm the new editor of the Diameter MIPv4 application. In process of solving the last remaining issue, it has been identified that the protocol is still lacking some major functionality in some cases of handoffs, since the Diameter MIPv4 application allows you to have more than one AAAH in the same subdomain of a realm. Please see, issue #299 and issue #301 at http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of the issues. During, the AAA working group meeting at IETF53 I presented the issues and two alternative ways in which we can workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. ---------------------------------------------------------------------------- -- AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this... Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. ---------------------------------------------------------------------------- - AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I would really need to get your opinion on this asap., so I know if I'm asking for the impossible or not :). Best Regards, Tony ------_=_NextPart_001_01C1D42D.8BDBF6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter = MIPv4

Hi Phil;

Please correct me if I am wrong.
Tony is asking to use GAINE draft after what he = thinks is a minor change.
However, your suggestion is to create a new draft = and to incorporate the pieces from the deprecated GANIE draft into = it.

Is there any reason for this?

Regards;
Ahmad Muhanna


-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, March 25, 2002 12:23 PM
To: MIP (mobile-ip@sunroof.eng.sun.com)
Subject: [mobile-ip] FW: Make use of the GNAIE draft = in Diameter MIPv4


Hi folks,

   we received this note from Tony this = morning.  We would like to support
alt 2 by
generating a new draft describing the problem and = incorporating the pieces
from the deprecated
GNAIE draft into it.  They need this in a = hurry, so we'd like to hear in
advance if anyone
has objection to this, otherwise we'll make it a = working group item, and
generate a WG last
call on it straightaway.

Phil


-----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericss= on.com]
Sent: Monday, March 25, 2002 1:59 AM
To: proberts@megisto.com; = basavaraj.patil@nokia.com
Cc: aboba@internaut.com; = pcalhoun@bstormnetworks.com
Subject: Make use of the GNAIE draft in Diameter = MIPv4


Hi Phil and Basavaraj,

My name is Tony Johansson and as you may know I'm the = new editor of the
Diameter MIPv4 application. In process of solving = the last remaining issue,
it has been identified that the protocol is still = lacking some major
functionality in some cases of handoffs, since the = Diameter MIPv4
application allows you to have more than one AAAH in = the same subdomain of a
realm. Please see, issue  #299 and issue #301 = at
http://www.drizzle.com/~aboba/AAA/issues.html for = a detailed description of
the issues.

During, the AAA working group meeting at IETF53 I = presented the issues and
two alternative ways in which we can workout a = solution to the open issues -
see below:

Alt1: Clarifications / new requirements without any = new dependencies to MIP.
---------------------------------------------------------------= -------------
--

AAAH
- Require that each subdomain of a realm is = authorized/authenticated by
exactly one AAAH. So while a home network may have = multiple AAAH's, each
subdomain will have exactly one AAAH.

- Or, require that, if the home realm has multiple = AAA servers to which the
same user can be routed to, then there MUST be a = synchronization mechanism
between the AAAH servers. However, the specific = synchronization mechanism is
beyond the scope of this spec.

 AAAF
- How to map HA IP address to HA FQDN is still open. = Reverse DNS look up is
not at all a straightforward solution for = this...


Alt 2: New dependencies to MIP, by requiring the = usage of the GNAIE draft.
---------------------------------------------------------------= -------------
-

AAAH
- Require that the MN support the GNAIE draft, = updated to include the
definition of a AAAH NAI.  When sending a MIP = RegReq, this AAAH NAI would be
included to guarantee that a registered user always = ends up in the same
initial AAAH.

AAAF
- The mapping of the HA IP address and HA FQDN, Host = and realm would be
automatically solved, since this would be included = in the MIP RegReq as
well.

There was a very clear and strong consensus that = alternative 2 would be by
far the best solution. However, this means more work = and dependencies to the
MIP working group and the goal is set to have the = Diameter MIPv4 appl. draft
in working group last call by the April 2nd. Looking = at the GNAIE draft, I
done see that much work needs to be done to make it = fulfill our needs, so to
me it could easily be done in time, but the big = question is how quickly
could it be pushed through the MIP working group and = go to last call?  I
would really need to get your opinion on this asap., = so I know if I'm asking
for the impossible or not :).

Best Regards,

Tony

------_=_NextPart_001_01C1D42D.8BDBF6F0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 14:10: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 OAA27065 for ; Mon, 25 Mar 2002 14:10: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 MAA08373; Mon, 25 Mar 2002 12:09: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 LAA19704; Mon, 25 Mar 2002 11:09: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 g2PJ8XKL006621 for ; Mon, 25 Mar 2002 11:08:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PJ8WGL006620 for mobile-ip-dist; Mon, 25 Mar 2002 11:08: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 g2PJ8UKL006613 for ; Mon, 25 Mar 2002 11:08:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08727 for ; Mon, 25 Mar 2002 11:08:30 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16459 for ; Mon, 25 Mar 2002 11:08:18 -0800 (PST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 25 Mar 2002 14:06:47 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Date: Mon, 25 Mar 2002 14:06:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D430.35BE83A2" Sender: owner-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_01C1D430.35BE83A2 Content-Type: text/plain Yes, of course! We're incorporating extensions into functional drafts rather than defining generalized extensions - that's the reason GNAIE was deprecated. Now we have a practical need for the extension, so the draft will describe what is needed and how it will be used and the relevant extensions will be incorporate there. -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: Monday, March 25, 2002 1:48 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil; Please correct me if I am wrong. Tony is asking to use GAINE draft after what he thinks is a minor change. However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it. Is there any reason for this? Regards; Ahmad Muhanna -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com ] Sent: Monday, March 25, 2002 12:23 PM To: MIP (mobile-ip@sunroof.eng.sun.com) Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi folks, we received this note from Tony this morning. We would like to support alt 2 by generating a new draft describing the problem and incorporating the pieces from the deprecated GNAIE draft into it. They need this in a hurry, so we'd like to hear in advance if anyone has objection to this, otherwise we'll make it a working group item, and generate a WG last call on it straightaway. Phil -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com ] Sent: Monday, March 25, 2002 1:59 AM To: proberts@megisto.com; basavaraj.patil@nokia.com Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com Subject: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil and Basavaraj, My name is Tony Johansson and as you may know I'm the new editor of the Diameter MIPv4 application. In process of solving the last remaining issue, it has been identified that the protocol is still lacking some major functionality in some cases of handoffs, since the Diameter MIPv4 application allows you to have more than one AAAH in the same subdomain of a realm. Please see, issue #299 and issue #301 at http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of the issues. During, the AAA working group meeting at IETF53 I presented the issues and two alternative ways in which we can workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. ---------------------------------------------------------------------------- -- AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this... Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. ---------------------------------------------------------------------------- - AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I would really need to get your opinion on this asap., so I know if I'm asking for the impossible or not :). Best Regards, Tony ------_=_NextPart_001_01C1D430.35BE83A2 Content-Type: text/html Message
Yes, of course!
 
We're incorporating extensions into functional drafts rather than defining generalized extensions - that's the reason
GNAIE was deprecated.  Now we have a practical need for the extension, so the draft will describe what is needed
and how it will be used and the relevant extensions will be incorporate there.
 
-----Original Message-----
From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: Monday, March 25, 2002 1:48 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4

Hi Phil;

Please correct me if I am wrong.
Tony is asking to use GAINE draft after what he thinks is a minor change.
However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it.

Is there any reason for this?

Regards;
Ahmad Muhanna


-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, March 25, 2002 12:23 PM
To: MIP (mobile-ip@sunroof.eng.sun.com)
Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4


Hi folks,

   we received this note from Tony this morning.  We would like to support
alt 2 by
generating a new draft describing the problem and incorporating the pieces
from the deprecated
GNAIE draft into it.  They need this in a hurry, so we'd like to hear in
advance if anyone
has objection to this, otherwise we'll make it a working group item, and
generate a WG last
call on it straightaway.

Phil


-----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Monday, March 25, 2002 1:59 AM
To: proberts@megisto.com; basavaraj.patil@nokia.com
Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com
Subject: Make use of the GNAIE draft in Diameter MIPv4


Hi Phil and Basavaraj,

My name is Tony Johansson and as you may know I'm the new editor of the
Diameter MIPv4 application. In process of solving the last remaining issue,
it has been identified that the protocol is still lacking some major
functionality in some cases of handoffs, since the Diameter MIPv4
application allows you to have more than one AAAH in the same subdomain of a
realm. Please see, issue  #299 and issue #301 at
http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of
the issues.

During, the AAA working group meeting at IETF53 I presented the issues and
two alternative ways in which we can workout a solution to the open issues -
see below:

Alt1: Clarifications / new requirements without any new dependencies to MIP.
----------------------------------------------------------------------------
--

AAAH
- Require that each subdomain of a realm is authorized/authenticated by
exactly one AAAH. So while a home network may have multiple AAAH's, each
subdomain will have exactly one AAAH.

- Or, require that, if the home realm has multiple AAA servers to which the
same user can be routed to, then there MUST be a synchronization mechanism
between the AAAH servers. However, the specific synchronization mechanism is
beyond the scope of this spec.

 AAAF
- How to map HA IP address to HA FQDN is still open. Reverse DNS look up is
not at all a straightforward solution for this...


Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft.
----------------------------------------------------------------------------
-

AAAH
- Require that the MN support the GNAIE draft, updated to include the
definition of a AAAH NAI.  When sending a MIP RegReq, this AAAH NAI would be
included to guarantee that a registered user always ends up in the same
initial AAAH.

AAAF
- The mapping of the HA IP address and HA FQDN, Host and realm would be
automatically solved, since this would be included in the MIP RegReq as
well.

There was a very clear and strong consensus that alternative 2 would be by
far the best solution. However, this means more work and dependencies to the
MIP working group and the goal is set to have the Diameter MIPv4 appl. draft
in working group last call by the April 2nd. Looking at the GNAIE draft, I
done see that much work needs to be done to make it fulfill our needs, so to
me it could easily be done in time, but the big question is how quickly
could it be pushed through the MIP working group and go to last call?  I
would really need to get your opinion on this asap., so I know if I'm asking
for the impossible or not :).

Best Regards,

Tony

------_=_NextPart_001_01C1D430.35BE83A2-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 14:12: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 OAA27167 for ; Mon, 25 Mar 2002 14:12: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 MAA09618; Mon, 25 Mar 2002 12:11: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 LAA20323; Mon, 25 Mar 2002 11: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 g2PJAeKL006683 for ; Mon, 25 Mar 2002 11:10:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PJAejn006682 for mobile-ip-dist; Mon, 25 Mar 2002 11:10: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 g2PJAaKL006675 for ; Mon, 25 Mar 2002 11:10:36 -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 LAA20098 for ; Mon, 25 Mar 2002 11:10:36 -0800 (PST) Received: from out001.verizon.net (out001slb.verizon.net [206.46.170.13] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15991 for ; Mon, 25 Mar 2002 12:10:35 -0700 (MST) Received: from inovate03 ([65.193.109.254]) by out001.verizon.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020325191031.UMRN6775.out001.verizon.net@inovate03> for ; Mon, 25 Mar 2002 13:10:31 -0600 From: "Haseeb Akhtar" To: Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Date: Mon, 25 Mar 2002 13:19:12 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1D3FF.A7AEB350" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCAFE@zrc2c013.us.nortel.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 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: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1D3FF.A7AEB350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4Hello Phil, I agree with Tony in that we resurrect the GNAIE draft and add the minor changes. There is no need to create another draft, is there? Regards, Haseeb -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ahmad Muhanna Sent: Monday, March 25, 2002 12:48 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil; Please correct me if I am wrong. Tony is asking to use GAINE draft after what he thinks is a minor change. However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it. Is there any reason for this? Regards; Ahmad Muhanna -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, March 25, 2002 12:23 PM To: MIP (mobile-ip@sunroof.eng.sun.com) Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi folks, we received this note from Tony this morning. We would like to support alt 2 by generating a new draft describing the problem and incorporating the pieces from the deprecated GNAIE draft into it. They need this in a hurry, so we'd like to hear in advance if anyone has objection to this, otherwise we'll make it a working group item, and generate a WG last call on it straightaway. Phil -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Monday, March 25, 2002 1:59 AM To: proberts@megisto.com; basavaraj.patil@nokia.com Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com Subject: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil and Basavaraj, My name is Tony Johansson and as you may know I'm the new editor of the Diameter MIPv4 application. In process of solving the last remaining issue, it has been identified that the protocol is still lacking some major functionality in some cases of handoffs, since the Diameter MIPv4 application allows you to have more than one AAAH in the same subdomain of a realm. Please see, issue #299 and issue #301 at http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of the issues. During, the AAA working group meeting at IETF53 I presented the issues and two alternative ways in which we can workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. -------------------------------------------------------------------------- -- -- AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this... Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. -------------------------------------------------------------------------- -- - AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I would really need to get your opinion on this asap., so I know if I'm asking for the impossible or not :). Best Regards, Tony ------=_NextPart_000_0007_01C1D3FF.A7AEB350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] FW: Make use of the GNAIE draft in = Diameter MIPv4
Hello=20 Phil,
 
I=20 agree with Tony in that we resurrect the GNAIE draft and add the minor = changes.=20
 
There=20 is no need to create another draft, is there?
 
Regards,
 
Haseeb
-----Original Message-----
From:=20 owner-mobile-ip@sunroof.eng.sun.com=20 [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ahmad=20 Muhanna
Sent: Monday, March 25, 2002 12:48 PM
To:=20 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] FW: = Make=20 use of the GNAIE draft in Diameter MIPv4

Hi Phil;

Please correct me if I am wrong.
Tony=20 is asking to use GAINE draft after what he thinks is a minor = change.=20
However, your suggestion is to create a new draft = and to=20 incorporate the pieces from the deprecated GANIE draft into = it.

Is there any reason for this?

Regards;
Ahmad = Muhanna


-----Original Message-----
From: Phil=20 Roberts [mailto:PRoberts@MEGISTO.com]=20
Sent: Monday, March 25, 2002 12:23 PM =
To: MIP (mobile-ip@sunroof.eng.sun.com)
Subject: [mobile-ip] FW: Make use of the GNAIE draft in = Diameter=20 MIPv4


Hi folks,

   we received this note from Tony this=20 morning.  We would like to support
alt = 2=20 by
generating a new draft describing the = problem and=20 incorporating the pieces
from the = deprecated=20
GNAIE draft into it.  They need this in a = hurry, so we'd=20 like to hear in
advance if anyone =
has objection to this, otherwise we'll make it a working = group item,=20 and
generate a WG last
call on=20 it straightaway.

Phil


-----Original Message-----
From: Tony=20 Johansson [mailto:tony.johansson@ericsso= n.com]=20
Sent: Monday, March 25, 2002 1:59 AM =
To: proberts@megisto.com; basavaraj.patil@nokia.com =
Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com =
Subject: Make use of the GNAIE draft in Diameter MIPv4 =


Hi Phil and Basavaraj,

My name is Tony Johansson and as you may know I'm = the new=20 editor of the
Diameter MIPv4 application. In = process=20 of solving the last remaining issue,
it has = been=20 identified that the protocol is still lacking some major =
functionality in some cases of handoffs, since the Diameter=20 MIPv4
application allows you to have more = than one=20 AAAH in the same subdomain of a
realm. = Please see,=20 issue  #299 and issue #301 at
http://www.drizzle.com/~aboba/AAA/issues.html for = a detailed=20 description of
the issues.

During, the AAA working group meeting at IETF53 I = presented=20 the issues and
two alternative ways in which = we can=20 workout a solution to the open issues -
see=20 below:

Alt1: Clarifications / new requirements without any = new=20 dependencies to MIP.
----------------------------------------------------------------= ------------=20
--

AAAH
- Require that each = subdomain of=20 a realm is authorized/authenticated by
exactly one=20 AAAH. So while a home network may have multiple AAAH's, each =
subdomain will have exactly one AAAH.

- Or, require that, if the home realm has multiple = AAA servers=20 to which the
same user can be routed to, = then there=20 MUST be a synchronization mechanism
between = the AAAH=20 servers. However, the specific synchronization mechanism is =
beyond the scope of this spec.

 AAAF
- How to map HA = IP address=20 to HA FQDN is still open. Reverse DNS look up is
not=20 at all a straightforward solution for this...


Alt 2: New dependencies to MIP, by requiring the = usage of the=20 GNAIE draft.
----------------------------------------------------------------= ------------=20
-

AAAH
- Require that the MN = support the=20 GNAIE draft, updated to include the
definition of a=20 AAAH NAI.  When sending a MIP RegReq, this AAAH NAI would = be=20
included to guarantee that a registered user always = ends up=20 in the same
initial AAAH.

AAAF
- The mapping of the = HA IP=20 address and HA FQDN, Host and realm would be
automatically solved, since this would be included in the MIP = RegReq=20 as
well.

There was a very clear and strong consensus that = alternative 2=20 would be by
far the best solution. However, = this means=20 more work and dependencies to the
MIP = working group=20 and the goal is set to have the Diameter MIPv4 appl. draft =
in working group last call by the April 2nd. Looking at the = GNAIE=20 draft, I
done see that much work needs to be = done to=20 make it fulfill our needs, so to
me it could = easily be=20 done in time, but the big question is how quickly
could it be pushed through the MIP working group and go to = last=20 call?  I
would really need to get your = opinion on=20 this asap., so I know if I'm asking
for the = impossible=20 or not :).

Best Regards,

Tony

------=_NextPart_000_0007_01C1D3FF.A7AEB350-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 14:21: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 OAA27555 for ; Mon, 25 Mar 2002 14:21: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 MAA21304; Mon, 25 Mar 2002 12:20: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 LAA22567; Mon, 25 Mar 2002 11: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 g2PJFnKL006780 for ; Mon, 25 Mar 2002 11:15:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PJFnIK006779 for mobile-ip-dist; Mon, 25 Mar 2002 11:15: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 g2PJFkKL006772 for ; Mon, 25 Mar 2002 11:15: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 LAA19669 for ; Mon, 25 Mar 2002 11:15:30 -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 MAA18602 for ; Mon, 25 Mar 2002 12:15:29 -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 g2PJFQa19060 for ; Mon, 25 Mar 2002 13:15:26 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 13:15:27 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB04@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Date: Mon, 25 Mar 2002 13:15:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D431.6655A760" Sender: owner-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_01C1D431.6655A760 Content-Type: text/plain; charset="iso-8859-1" Thanks for the info. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, March 25, 2002 1:07 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Yes, of course! We're incorporating extensions into functional drafts rather than defining generalized extensions - that's the reason GNAIE was deprecated. Now we have a practical need for the extension, so the draft will describe what is needed and how it will be used and the relevant extensions will be incorporate there. -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: Monday, March 25, 2002 1:48 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil; Please correct me if I am wrong. Tony is asking to use GAINE draft after what he thinks is a minor change. However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it. Is there any reason for this? Regards; Ahmad Muhanna -----Original Message----- From: Phil Roberts [ mailto:PRoberts@MEGISTO.com ] Sent: Monday, March 25, 2002 12:23 PM To: MIP (mobile-ip@sunroof.eng.sun.com) Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi folks, we received this note from Tony this morning. We would like to support alt 2 by generating a new draft describing the problem and incorporating the pieces from the deprecated GNAIE draft into it. They need this in a hurry, so we'd like to hear in advance if anyone has objection to this, otherwise we'll make it a working group item, and generate a WG last call on it straightaway. Phil -----Original Message----- From: Tony Johansson [ mailto:tony.johansson@ericsson.com ] Sent: Monday, March 25, 2002 1:59 AM To: proberts@megisto.com; basavaraj.patil@nokia.com Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com Subject: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil and Basavaraj, My name is Tony Johansson and as you may know I'm the new editor of the Diameter MIPv4 application. In process of solving the last remaining issue, it has been identified that the protocol is still lacking some major functionality in some cases of handoffs, since the Diameter MIPv4 application allows you to have more than one AAAH in the same subdomain of a realm. Please see, issue #299 and issue #301 at http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of the issues. During, the AAA working group meeting at IETF53 I presented the issues and two alternative ways in which we can workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. ---------------------------------------------------------------------------- -- AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this... Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. ---------------------------------------------------------------------------- - AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I would really need to get your opinion on this asap., so I know if I'm asking for the impossible or not :). Best Regards, Tony ------_=_NextPart_001_01C1D431.6655A760 Content-Type: text/html; charset="iso-8859-1" Message
Thanks for the info.
 
-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, March 25, 2002 1:07 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4

Yes, of course!
 
We're incorporating extensions into functional drafts rather than defining generalized extensions - that's the reason
GNAIE was deprecated.  Now we have a practical need for the extension, so the draft will describe what is needed
and how it will be used and the relevant extensions will be incorporate there.
 
-----Original Message-----
From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: Monday, March 25, 2002 1:48 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4

Hi Phil;

Please correct me if I am wrong.
Tony is asking to use GAINE draft after what he thinks is a minor change.
However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it.

Is there any reason for this?

Regards;
Ahmad Muhanna


-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, March 25, 2002 12:23 PM
To: MIP (mobile-ip@sunroof.eng.sun.com)
Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4


Hi folks,

   we received this note from Tony this morning.  We would like to support
alt 2 by
generating a new draft describing the problem and incorporating the pieces
from the deprecated
GNAIE draft into it.  They need this in a hurry, so we'd like to hear in
advance if anyone
has objection to this, otherwise we'll make it a working group item, and
generate a WG last
call on it straightaway.

Phil


-----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Monday, March 25, 2002 1:59 AM
To: proberts@megisto.com; basavaraj.patil@nokia.com
Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com
Subject: Make use of the GNAIE draft in Diameter MIPv4


Hi Phil and Basavaraj,

My name is Tony Johansson and as you may know I'm the new editor of the
Diameter MIPv4 application. In process of solving the last remaining issue,
it has been identified that the protocol is still lacking some major
functionality in some cases of handoffs, since the Diameter MIPv4
application allows you to have more than one AAAH in the same subdomain of a
realm. Please see, issue  #299 and issue #301 at
http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of
the issues.

During, the AAA working group meeting at IETF53 I presented the issues and
two alternative ways in which we can workout a solution to the open issues -
see below:

Alt1: Clarifications / new requirements without any new dependencies to MIP.
----------------------------------------------------------------------------
--

AAAH
- Require that each subdomain of a realm is authorized/authenticated by
exactly one AAAH. So while a home network may have multiple AAAH's, each
subdomain will have exactly one AAAH.

- Or, require that, if the home realm has multiple AAA servers to which the
same user can be routed to, then there MUST be a synchronization mechanism
between the AAAH servers. However, the specific synchronization mechanism is
beyond the scope of this spec.

 AAAF
- How to map HA IP address to HA FQDN is still open. Reverse DNS look up is
not at all a straightforward solution for this...


Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft.
----------------------------------------------------------------------------
-

AAAH
- Require that the MN support the GNAIE draft, updated to include the
definition of a AAAH NAI.  When sending a MIP RegReq, this AAAH NAI would be
included to guarantee that a registered user always ends up in the same
initial AAAH.

AAAF
- The mapping of the HA IP address and HA FQDN, Host and realm would be
automatically solved, since this would be included in the MIP RegReq as
well.

There was a very clear and strong consensus that alternative 2 would be by
far the best solution. However, this means more work and dependencies to the
MIP working group and the goal is set to have the Diameter MIPv4 appl. draft
in working group last call by the April 2nd. Looking at the GNAIE draft, I
done see that much work needs to be done to make it fulfill our needs, so to
me it could easily be done in time, but the big question is how quickly
could it be pushed through the MIP working group and go to last call?  I
would really need to get your opinion on this asap., so I know if I'm asking
for the impossible or not :).

Best Regards,

Tony

------_=_NextPart_001_01C1D431.6655A760-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 14:29: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 OAA27981 for ; Mon, 25 Mar 2002 14:29:34 -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 MAA19216; Mon, 25 Mar 2002 12:29: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 LAA25232; Mon, 25 Mar 2002 11:29: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 g2PJSBKL006945 for ; Mon, 25 Mar 2002 11:28:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PJSA1r006944 for mobile-ip-dist; Mon, 25 Mar 2002 11:28: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 g2PJS7KL006937 for ; Mon, 25 Mar 2002 11:28: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 LAA23776 for ; Mon, 25 Mar 2002 11:28:07 -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 MAA06554 for ; Mon, 25 Mar 2002 12:28: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 g2PJS3a22315 for ; Mon, 25 Mar 2002 13:28:03 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 13:28:04 -0600 Message-ID: From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Date: Mon, 25 Mar 2002 13:27:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D433.2AF2A450" Sender: owner-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_01C1D433.2AF2A450 Content-Type: text/plain; charset="iso-8859-1" Phil, Since their is enough need for the GNAI draft, we should add the minor changes and return this draft back as a working group item. MK -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ahmad Muhanna Sent: Monday, March 25, 2002 12:48 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil; Please correct me if I am wrong. Tony is asking to use GAINE draft after what he thinks is a minor change. However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it. Is there any reason for this? Regards; Ahmad Muhanna -----Original Message----- From: Phil Roberts [ mailto:PRoberts@MEGISTO.com ] Sent: Monday, March 25, 2002 12:23 PM To: MIP (mobile-ip@sunroof.eng.sun.com) Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4 Hi folks, we received this note from Tony this morning. We would like to support alt 2 by generating a new draft describing the problem and incorporating the pieces from the deprecated GNAIE draft into it. They need this in a hurry, so we'd like to hear in advance if anyone has objection to this, otherwise we'll make it a working group item, and generate a WG last call on it straightaway. Phil -----Original Message----- From: Tony Johansson [ mailto:tony.johansson@ericsson.com ] Sent: Monday, March 25, 2002 1:59 AM To: proberts@megisto.com; basavaraj.patil@nokia.com Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com Subject: Make use of the GNAIE draft in Diameter MIPv4 Hi Phil and Basavaraj, My name is Tony Johansson and as you may know I'm the new editor of the Diameter MIPv4 application. In process of solving the last remaining issue, it has been identified that the protocol is still lacking some major functionality in some cases of handoffs, since the Diameter MIPv4 application allows you to have more than one AAAH in the same subdomain of a realm. Please see, issue #299 and issue #301 at http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of the issues. During, the AAA working group meeting at IETF53 I presented the issues and two alternative ways in which we can workout a solution to the open issues - see below: Alt1: Clarifications / new requirements without any new dependencies to MIP. ---------------------------------------------------------------------------- -- AAAH - Require that each subdomain of a realm is authorized/authenticated by exactly one AAAH. So while a home network may have multiple AAAH's, each subdomain will have exactly one AAAH. - Or, require that, if the home realm has multiple AAA servers to which the same user can be routed to, then there MUST be a synchronization mechanism between the AAAH servers. However, the specific synchronization mechanism is beyond the scope of this spec. AAAF - How to map HA IP address to HA FQDN is still open. Reverse DNS look up is not at all a straightforward solution for this... Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft. ---------------------------------------------------------------------------- - AAAH - Require that the MN support the GNAIE draft, updated to include the definition of a AAAH NAI. When sending a MIP RegReq, this AAAH NAI would be included to guarantee that a registered user always ends up in the same initial AAAH. AAAF - The mapping of the HA IP address and HA FQDN, Host and realm would be automatically solved, since this would be included in the MIP RegReq as well. There was a very clear and strong consensus that alternative 2 would be by far the best solution. However, this means more work and dependencies to the MIP working group and the goal is set to have the Diameter MIPv4 appl. draft in working group last call by the April 2nd. Looking at the GNAIE draft, I done see that much work needs to be done to make it fulfill our needs, so to me it could easily be done in time, but the big question is how quickly could it be pushed through the MIP working group and go to last call? I would really need to get your opinion on this asap., so I know if I'm asking for the impossible or not :). Best Regards, Tony ------_=_NextPart_001_01C1D433.2AF2A450 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4
Phil,
 
Since their is enough need for the GNAI draft, we should add the minor changes and return this draft back as a working group item.
 
MK
-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ahmad Muhanna
Sent: Monday, March 25, 2002 12:48 PM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4

Hi Phil;

Please correct me if I am wrong.
Tony is asking to use GAINE draft after what he thinks is a minor change.
However, your suggestion is to create a new draft and to incorporate the pieces from the deprecated GANIE draft into it.

Is there any reason for this?

Regards;
Ahmad Muhanna


-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, March 25, 2002 12:23 PM
To: MIP (mobile-ip@sunroof.eng.sun.com)
Subject: [mobile-ip] FW: Make use of the GNAIE draft in Diameter MIPv4


Hi folks,

   we received this note from Tony this morning.  We would like to support
alt 2 by
generating a new draft describing the problem and incorporating the pieces
from the deprecated
GNAIE draft into it.  They need this in a hurry, so we'd like to hear in
advance if anyone
has objection to this, otherwise we'll make it a working group item, and
generate a WG last
call on it straightaway.

Phil


-----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Monday, March 25, 2002 1:59 AM
To: proberts@megisto.com; basavaraj.patil@nokia.com
Cc: aboba@internaut.com; pcalhoun@bstormnetworks.com
Subject: Make use of the GNAIE draft in Diameter MIPv4


Hi Phil and Basavaraj,

My name is Tony Johansson and as you may know I'm the new editor of the
Diameter MIPv4 application. In process of solving the last remaining issue,
it has been identified that the protocol is still lacking some major
functionality in some cases of handoffs, since the Diameter MIPv4
application allows you to have more than one AAAH in the same subdomain of a
realm. Please see, issue  #299 and issue #301 at
http://www.drizzle.com/~aboba/AAA/issues.html for a detailed description of
the issues.

During, the AAA working group meeting at IETF53 I presented the issues and
two alternative ways in which we can workout a solution to the open issues -
see below:

Alt1: Clarifications / new requirements without any new dependencies to MIP.
----------------------------------------------------------------------------
--

AAAH
- Require that each subdomain of a realm is authorized/authenticated by
exactly one AAAH. So while a home network may have multiple AAAH's, each
subdomain will have exactly one AAAH.

- Or, require that, if the home realm has multiple AAA servers to which the
same user can be routed to, then there MUST be a synchronization mechanism
between the AAAH servers. However, the specific synchronization mechanism is
beyond the scope of this spec.

 AAAF
- How to map HA IP address to HA FQDN is still open. Reverse DNS look up is
not at all a straightforward solution for this...


Alt 2: New dependencies to MIP, by requiring the usage of the GNAIE draft.
----------------------------------------------------------------------------
-

AAAH
- Require that the MN support the GNAIE draft, updated to include the
definition of a AAAH NAI.  When sending a MIP RegReq, this AAAH NAI would be
included to guarantee that a registered user always ends up in the same
initial AAAH.

AAAF
- The mapping of the HA IP address and HA FQDN, Host and realm would be
automatically solved, since this would be included in the MIP RegReq as
well.

There was a very clear and strong consensus that alternative 2 would be by
far the best solution. However, this means more work and dependencies to the
MIP working group and the goal is set to have the Diameter MIPv4 appl. draft
in working group last call by the April 2nd. Looking at the GNAIE draft, I
done see that much work needs to be done to make it fulfill our needs, so to
me it could easily be done in time, but the big question is how quickly
could it be pushed through the MIP working group and go to last call?  I
would really need to get your opinion on this asap., so I know if I'm asking
for the impossible or not :).

Best Regards,

Tony

------_=_NextPart_001_01C1D433.2AF2A450-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 16:46: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 QAA04872 for ; Mon, 25 Mar 2002 16:46: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 OAA26994; Mon, 25 Mar 2002 14:45: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 NAA29147; Mon, 25 Mar 2002 13:45: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 g2PLimKL007412 for ; Mon, 25 Mar 2002 13:44:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PLimDO007411 for mobile-ip-dist; Mon, 25 Mar 2002 13:44: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 g2PLiiKL007404 for ; Mon, 25 Mar 2002 13:44:44 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24533 for ; Mon, 25 Mar 2002 13:44:46 -0800 (PST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03848 for ; Mon, 25 Mar 2002 13:44:35 -0800 (PST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2PLiii05710; Mon, 25 Mar 2002 16:44:44 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA20476; Mon, 25 Mar 2002 15:44:43 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id PAA16745; Mon, 25 Mar 2002 15:44:43 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15519.39499.592645.87197@nwsgpb.ih.lucent.com> Date: Mon, 25 Mar 2002 15:44:43 -0600 (CST) From: Pete McCann To: "Ahmad Muhanna", mobile-ip@sunroof.eng.sun.com Cc: "'Charles E. Perkins'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCAF9@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCAF9@zrc2c013.us.nortel.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.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, Ahmad, I agree with most of your proposed text, but one comment below: Ahmad Muhanna writes: > Hi Pete; > > With the understanding as in my response to Charlie in the previous email. > There is no backward compatibility issue with existing HA (RFC2002 & > RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension > (see previous email) > > There are several places where we need to address the issue of EXACTLY vs. > At least. The following are the proposed texts: > > 1. 8.2.1. Validity Checks > > Registration Requests with an invalid, non-zero UDP checksum MUST be > silently discarded by the home agent. > > The authentication in the Registration Request MUST be checked. This > involves the following operations: > > a) The home agent MUST check for the presence of at least one > authorization-enabling extension, and perform only one of the > indicated > authentication(s). At least one authorization-enabling extension > MUST be present in the Registration Request; and the home agent > MUST either check the Authenticator value in the extension or > verify that the authenticator value has been checked by another > agent with which it has a security association. If no > authorization-enabling extension is found, or if the > Authenticator is invalid, the home agent MUST reject the mobile > node's registration and SHOULD send a Registration Reply to the > mobile node with Code 131. The home agent MUST then discard > the Request and SHOULD log the error as a security exception. > If the home agent receives a Registration Request without a > Mobile-Home > Authentication extension from a Mobile Node that does not have a > security association with this home agent, the home agent MAY > discard the Mobile Node's Registration Request. Do we really need this last sentence above? I think you are trying to account for HAs that don't know about any authorization enabling extensions other than MN-HA Authentication extension. Won't the RRQs be silently discarded in this case, simply due to normal processing for unrecognized criticial extensions? > > b) The home agent MUST check that the registration Identification > field is correct using the context selected by the SPI within > the authorization-enabling extension that the home agent used to > authenticate the > Mobile Node's Registration Request. See Section 5.7 for a > description of how this is performed. > If incorrect, the home agent MUST reject the Request and SHOULD > send a Registration Reply to the mobile node with Code 133, > including an > Identification field computed in accordance with the rules > specified in Section 5.7. The home agent MUST do no further > processing with such a Request, though it SHOULD log the error > as a security exception. > > 2. A minor correction: > section 3.8.2.3 should read > "If the Registration Request does not satisfy all of the validity > checks > in Section 3.8.2.1,..." > > NOT > "If the Registration Reply does not satisfy all of the validity > checks > in Section 3.8.2.1,... > > 3. A slight change to your proposed text for section 3.6.1.3 item (e) > > (e) An authorization-enabling extension other than mobile-home > authentication, if present, followed by > > Otherwise, the text will allow the possibility of having two > Mobile-Home Authentication extension in the RRQ. Yes, I agree. I had considered similar wording myself, but discarded it in favor of a simpler specification - perhaps it would be OK to allow this behavior, nothing is really broken. But I can agree with your wording above. -Pete > Thanks for consideration > > Regards; > Ahmad Muhanna > > > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, March 20, 2002 10:37 AM > To: Charlie Perkins > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] A proposal for resolving a very Possible > conflictbetween RFC3220 & RFC3012 (RFC3012bis) > > > > Hi, Charlie, > > Ok, understanding the urgency, how about the following text: > > Change the first paragraph of Section 3.5.2 to read: > > At least one authorization-enabling extension MUST be present in all > Registration Requests, and also in all Registration Replies generated > by the Home Agent. This requirement is intended to eliminate problems > [2] which result from the uncontrolled propagation of remote redirects > in the Internet. The location of the extension marks the end of the > authenticated data covered by that extension. > > The Mobile-Home Authentication Extension is always an > authorization-enabling for registration messages specified in this > document; future specifications may define additional > authorization-enabling extensions. > > And the first sentence of Section 3.6: > > A mobile node MUST be configured with a netmask and a mobility > security association for each of its pre-assigned home agents or > home agents that could be discovered on a home subnet according > to procedures in Section 3.6.1.2. > > Also, I assume that the missing text people have been discussing > covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I > can't find it there now. > > Also, I think the text in 3.6.1.3 (section header currently missing) > needs to change to: > > a) The IP header, followed by the UDP header, followed by the > fixed-length portion of the Registration Request, followed by > > b) If present, any non-authentication Extensions expected to be > used by the home agent (which may or may not also be useful to > the foreign agent), followed by > > c) A mobile-home authentication extension, if present, followed by > > d) If present, any non-authentication Extensions used only by the > foreign agent, followed by > > e) An authorization-enabling extension, if present, followed by > > f) The Mobile-Foreign Authentication Extension, if present. > > Note that item (a) and at least one of (c) or (e) MUST appear in > every Registration Request sent by the mobile node. Items (b), (d), > and (f) are optional. However, item (f) MUST be included when the > mobile node and the foreign agent share a mobility security > association. > > > I think that should do it. > > -Pete > > > > > > > Charlie Perkins writes: > > > > Hello Pete, > > > > Pete McCann wrote: > > > > > I believe we will need to update the MN-HA key in the first RRQ/RRP, > > > sometimes. > > > > > > Maybe the right approach is to update the text in 3220 to explicitly > > > allow zero security associations with home agents, if some other > > > "authorization enabling extension" is present in the message. > > > > If so, the time to do so would be this week, so that we can get it in at > > the same time we supply the mysteriously vanished text, and update the > > "exactly one", and relieve the possibility for misinterpretation that was > > noticed during Connectathon. > > > > Regards, > > Charlie P. > > > > > > > > > > RE: [mobile-ip] A proposal for resolving a very Possible conflictbetween RFC3220 & RFC3012 (RFC3012bis) > > > >

Hi Pete; >

> >

With the understanding as in my response to Charlie in the previous email. >
There is no backward compatibility issue with existing HA (RFC2002 & RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension (see previous email)

> >

There are several places where we need to address the issue of EXACTLY vs. At least. The following are the proposed texts:

> >

1.      8.2.1. Validity Checks >

> >

   Registration Requests with an invalid, non-zero UDP checksum MUST be >
   silently discarded by the home agent. >

> >

   The authentication in the Registration Request MUST be checked.  This >
   involves the following operations: >

> >

      a) The home agent MUST check for the presence of at least one >
         authorization-enabling extension, and perform only one of the indicated >
         authentication(s).  At least one authorization-enabling extension >
         MUST be present in the Registration Request; and the home agent >
         MUST either check the Authenticator value in the extension or >
         verify that the authenticator value has been checked by another >
         agent with which it has a security association.  If no >
         authorization-enabling extension is found, or if the >
         Authenticator is invalid, the home agent MUST reject the mobile >
         node's registration and SHOULD send a Registration Reply to the >
         mobile node with Code 131.  The home agent MUST then discard >
         the Request and SHOULD log the error as a security exception. >
         If the home agent receives a Registration Request without a Mobile-Home >
         Authentication extension from a Mobile Node that does not have a >
         security association with this home agent, the home agent MAY >
         discard the Mobile Node's Registration Request. >

>
> >

     b) The home agent MUST check that the registration Identification >
         field is correct using the context selected by the SPI within >
         the authorization-enabling extension that the home agent used to authenticate the >
         Mobile Node's Registration Request.  See Section 5.7 for a description of how this is performed.  >
         If incorrect, the home agent MUST reject the Request and SHOULD >
         send a Registration Reply to the mobile node with Code 133, including an >
         Identification field computed in accordance with the rules >
         specified in Section 5.7.  The home agent MUST do no further >
         processing with such a Request, though it SHOULD log the error >
         as a security exception. >

> >

2.      A minor correction: >
        section 3.8.2.3 should read >
        "If the Registration Request does not satisfy all of the validity checks >
        in Section 3.8.2.1,..." >

> >

        NOT >
        "If the Registration Reply does not satisfy all of the validity checks >
        in Section 3.8.2.1,... >

> >

3.      A slight change to your proposed text for section 3.6.1.3 item (e) >

> >

        (e) An authorization-enabling extension other than mobile-home authentication, if present, followed by >

> >

        Otherwise, the text will allow the possibility of having two Mobile-Home Authentication extension in the RRQ. >

>
> >

Thanks for consideration        >

> >

Regards; >
Ahmad Muhanna >

>
>
> >

-----Original Message----- >
From: Pete McCann [mailto:mccap@lucent.com] >
Sent: Wednesday, March 20, 2002 10:37 AM >
To: Charlie Perkins >
Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' >
Subject: Re: [mobile-ip] A proposal for resolving a very Possible >
conflictbetween RFC3220 & RFC3012 (RFC3012bis) >

>
>
> >

Hi, Charlie, >

> >

Ok, understanding the urgency, how about the following text: >

> >

Change the first paragraph of Section 3.5.2 to read: >

> >

  At least one authorization-enabling extension MUST be present in all >
  Registration Requests, and also in all Registration Replies generated >
  by the Home Agent.  This requirement is intended to eliminate problems >
  [2] which result from the uncontrolled propagation of remote redirects >
  in the Internet.  The location of the extension marks the end of the >
  authenticated data covered by that extension. >

> >

  The Mobile-Home Authentication Extension is always an >
  authorization-enabling for registration messages specified in this >
  document; future specifications may define additional >
  authorization-enabling extensions. >

> >

And the first sentence of Section 3.6: >

> >

   A mobile node MUST be configured with a netmask and a mobility >
   security association for each of its pre-assigned home agents or >
   home agents that could be discovered on a home subnet according >
   to procedures in Section 3.6.1.2. >

> >

Also, I assume that the missing text people have been discussing >
covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I >
can't find it there now. >

> >

Also, I think the text in 3.6.1.3 (section header currently missing) >
needs to change to: >

> >

      a) The IP header, followed by the UDP header, followed by the >
         fixed-length portion of the Registration Request, followed by >

> >

      b) If present, any non-authentication Extensions expected to be >
         used by the home agent (which may or may not also be useful to >
         the foreign agent), followed by >

> >

      c) A mobile-home authentication extension, if present, followed by >

> >

      d) If present, any non-authentication Extensions used only by the >
         foreign agent, followed by >

> >

      e) An authorization-enabling extension, if present, followed by >

> >

      f) The Mobile-Foreign Authentication Extension, if present. >

> >

   Note that item (a) and at least one of (c) or (e) MUST appear in >
   every Registration Request sent by the mobile node.  Items (b), (d), >
   and (f) are optional.  However, item (f) MUST be included when the >
   mobile node and the foreign agent share a mobility security >
   association. >

>
> >

I think that should do it. >

> >

-Pete >

>
>
>
>
>
> >

Charlie Perkins writes: >
 > >
 > Hello Pete, >
 > >
 > Pete McCann wrote: >
 > >
 > > I believe we will need to update the MN-HA key in the first RRQ/RRP, >
 > > sometimes. >
 > > >
 > > Maybe the right approach is to update the text in 3220 to explicitly >
 > > allow zero security associations with home agents, if some other >
 > > "authorization enabling extension" is present in the message. >
 > >
 > If so, the time to do so would be this week, so that we can get it in at >
 > the same time we supply the mysteriously vanished text, and update the >
 > "exactly one", and relieve the possibility for misinterpretation that was >
 > noticed during Connectathon. >
 > >
 > Regards, >
 > Charlie P. >
 > >
 > >

> > > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 16:58: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 QAA05213 for ; Mon, 25 Mar 2002 16:58:09 -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 NAA28823; Mon, 25 Mar 2002 13:57:39 -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 NAA03113; Mon, 25 Mar 2002 13:57: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 g2PLuiKL007607 for ; Mon, 25 Mar 2002 13:56:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PLui7d007606 for mobile-ip-dist; Mon, 25 Mar 2002 13:56: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 g2PLueKL007599 for ; Mon, 25 Mar 2002 13:56:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04856 for ; Mon, 25 Mar 2002 13:56:41 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07896 for ; Mon, 25 Mar 2002 13:56:43 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C211C2D45 for ; Mon, 25 Mar 2002 16:56:40 -0500 (EST) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 81CAB1759 for ; Mon, 25 Mar 2002 16:56:40 -0500 (EST) Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id QAA0001367424; Mon, 25 Mar 2002 16:56:40 -0500 (EST) Message-ID: <3C9F9D18.4CD0F608@compaq.com> Date: Mon, 25 Mar 2002 16:56:40 -0500 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 Draft-15 general issues from Connectathon-2002 References: <200203170136.g2H1aNXO389454@jurassic.eng.sun.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 Samita Chakrabarti wrote: > 5) section 9.4 of draft-15 says that HA uses routing header when it communicates > to the MN while it's not home and HA has a BCE for the MN. > The de-registration section is not clear (section 9.2), whether HA would use > routing header or not with the BACK when MN is back home. It does not make > sense to have routing header with the BACK while MN is back home. The draft > should specify the steps in this case whether HA would delete the BCE first > and then send BACK to the MN without routing header. This clarification is > highly needed in the draft, as it causes interoperability problem due to > different interpretation of the meaning of the draft. I'd like to add one more clarification regarding the CN behavior in this case - Section 8.5, Sending Binding Acknowledgements, second paragraph says: "Furthermore, if the packet is to be sent to the mobile node at any address other than the mobile node's home address, it MUST be sent using a Routing header (even if the binding was rejected)." This obviously means the CN shouldn't use a Routing Header when the MN moves back home and deletes the binding, but I think that subtlety was missed by a few implementations because it's not in the bulleted list of items on how to construct the BAck. -Brian From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 17:03: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 RAA05410 for ; Mon, 25 Mar 2002 17:03:05 -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 PAA19264; Mon, 25 Mar 2002 15:02: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 OAA07176; Mon, 25 Mar 2002 14:02: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 g2PM1rKL007707 for ; Mon, 25 Mar 2002 14:01:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PM1qh9007706 for mobile-ip-dist; Mon, 25 Mar 2002 14: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 purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PM1nKL007699 for ; Mon, 25 Mar 2002 14:01:49 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2PM1mg17723; Mon, 25 Mar 2002 17:01:48 -0500 (EST) Date: Mon, 25 Mar 2002 17:02:43 -0500 (EST) From: "Steven M. Glass" Subject: Re: [mobile-ip] Question about the I Bit in the Revocation Acknowledgement Messag e To: mobile-ip@sunroof.eng.sun.com Cc: "'Steven.Glass@Sun.COM'" , "'mchandra@cisco.com'" In-Reply-To: "Your message with ID" <6B49EDFE974BD51197D70002A56079D801AFCAFB@zrc2c013.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 Inform bit. > > Set to '1' by the foreign agent to ask the home agent > if the mobile node should be informed of the > revocation. > " > > If the Foreign Agent is sending this message to acknowledge receiving a > Revocation Message what does the above text mean? > Ahmad, There's two things that can be going on with the revocation request, and revocation acknowledge message, and I suppose the above text may need a bit of clarification in the scenario you're asking about (the answer to your question is the last half of this explanation). In the spirit of the draft (what I was intending to convey): If the FA is sending the revocation message, setting the 'I' bit to 1 means it is asking the HA to set the 'I' bit to '1' if it wants the MN to be informed of the revocation, and to set the 'I' bit ot '0' if it does NOT want the MN to be informed. If the HA sent the revocation request, and sets the 'I' bit to '1' it is requesting the FA inform the MN. If the FA does inform the MN, in the revocation acknowledgement the FA will set the 'I' bit to 1 (so the second part here is the specific answer to your question), and if the FA does NOT inform the MN, it sets the 'I' bit to 0. Another way to phrase that text would be: In the case of the FA revocing the registration, the 'I' bit is set to 1 to request the home agent instruct the FA to whether the MN should be informed of the revocation. Since this functionality is really up to the FA, it 'advertises' it MAY leave the decision to the HA in the registration phase, that is based on the 'I' bit's setting in the revocation extension. The key is how this corelates to what the FA is doing in the revocation request. Here are all the possibles (presuming both sides have implied they understand the 'I' bit int the registration phase): H-1. HA revoking registration, requests the MN be informed. In this case the HA sends a revocation message to the FA with the 'I' bit set to 1. If the FA informs the MN of it's revocation it SHOULD set the 'I' bit to 1 in the revocation acknowledgement (this is the specific case you asked about). If the FA does NOT inform the MN of the revocation, it SHOULD set the 'I' bit to 0. H-2. HA revoking registration, requests the MN NOT be informed. In this case the HA sends a revocation messasge to the FA with the 'I' bit set to 0. If the FA does NOT inform the MN, it SHOULD reply with the 'I' bit set to 0. If the FA does inform the MN of the revocation, it SHOULD set the 'I' bit to 1 (these responses by the FA are exactly as above). F-1. FA revoking registration, wants the HA to respond to whether the MN should be informed, so it sets the 'I' bit to 1. If the HA wants the MN to be informed of the revocation, in the revocation acknowledgement, it sets the 'I' bit to 1, and if it does NOT want the MN informed, it sets the 'I' bit to 0. F-2. FA revoking registration, doesn't care what the HA wants. In this case, where the policy in the foreign realm is not request what the HA wants, the FA SHOULD not imply the choice will be up to the HA in the registration phase, that is the 'I' bit should be set to 0 in the revocation extension. In this way, if the HA recieves a revocation request with the 'I' bit set to 1, it can infer the MN was informed of the revocation, and that's just the policy in the foreign realm. If the policy in the foreign realm is to always NOT inform the MN of the revocation, the FA conveys this by setting the 'I' bit to 1 in the registration phase (the revocation extension), then setting the 'I' bit to 0 in the revocation request (implying it has NOT informed the MN). I know it seems a bit complex, but (I think) all the functionality is there, and only uses essentially 2 bits, or 1 bit in each phase. Does this make sense? The other solution would be to go to a 'what the agents wants to be done in the event of a revocation' at the time of registration, but the nature of policy means that decision should be made at the time of revocation because the decision on whether to inform the MN is likely to be effected by why the revocation is happenning, which is why I propose this model. Thoughts? There may be a way to make this cleaner/clearer. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 17:45: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 RAA06848 for ; Mon, 25 Mar 2002 17:45: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 OAA08537; Mon, 25 Mar 2002 14:45: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 OAA21074; Mon, 25 Mar 2002 14:45: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 g2PMiWKL007863 for ; Mon, 25 Mar 2002 14:44:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PMiWiL007862 for mobile-ip-dist; Mon, 25 Mar 2002 14:44: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 g2PMiTKL007855 for ; Mon, 25 Mar 2002 14:44: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 OAA07627 for ; Mon, 25 Mar 2002 14:44:29 -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 PAA25157 for ; Mon, 25 Mar 2002 15:44:27 -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 g2PMiLa24111; Mon, 25 Mar 2002 16:44:22 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 16:44:23 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCB08@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Pete McCann'" , "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Charles E. Perkins'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Date: Mon, 25 Mar 2002 16:44:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D44E.97C062F0" Sender: owner-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_01C1D44E.97C062F0 Content-Type: text/plain; charset="iso-8859-1" Hi, Pete, Please see my one comment inline. Also, please let me know what you think of the following part of the proposed text: " a) The home agent MUST check for the presence of at least one authorization-enabling extension, and perform only one of the indicated authentication(s). At least one authorization-enabling extension MUST be present in the Registration Request;............... " I proposed ".., and perform only one of the indicated authentication(s)....." OVER "...., and perform at least one the indicated authentication(s) ......." for the following reason: In point (b) in the same section: " b) The home agent MUST check that the registration Identification field is correct using the context selected by the SPI within the authorization-enabling extension that the home agent used to authenticate the Mobile Node's Registration Request. .... " The standard says that the home agent MUST check that the registration Identification according to the context selected by the SPI within the authorization-enabling extension. Therefore, it makes more sense to define ONLY one authentication to be done and use the SPI of that authorization extension to reference the context which specifies the registration identification. I hope that you did not miss this part and you still agree with it. Regards; Ahmad Muhanna -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Monday, March 25, 2002 3:45 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; mobile-ip@sunroof.eng.sun.com Cc: 'Charles E. Perkins' Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) Hi, Ahmad, I agree with most of your proposed text, but one comment below: Ahmad Muhanna writes: > Hi Pete; > > With the understanding as in my response to Charlie in the previous email. > There is no backward compatibility issue with existing HA (RFC2002 & > RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension > (see previous email) > > There are several places where we need to address the issue of EXACTLY vs. > At least. The following are the proposed texts: > > 1. 8.2.1. Validity Checks > > Registration Requests with an invalid, non-zero UDP checksum MUST be > silently discarded by the home agent. > > The authentication in the Registration Request MUST be checked. This > involves the following operations: > > a) The home agent MUST check for the presence of at least one > authorization-enabling extension, and perform only one of the > indicated > authentication(s). At least one authorization-enabling extension > MUST be present in the Registration Request; and the home agent > MUST either check the Authenticator value in the extension or > verify that the authenticator value has been checked by another > agent with which it has a security association. If no > authorization-enabling extension is found, or if the > Authenticator is invalid, the home agent MUST reject the mobile > node's registration and SHOULD send a Registration Reply to the > mobile node with Code 131. The home agent MUST then discard > the Request and SHOULD log the error as a security exception. > If the home agent receives a Registration Request without a > Mobile-Home > Authentication extension from a Mobile Node that does not have a > security association with this home agent, the home agent MAY > discard the Mobile Node's Registration Request. Do we really need this last sentence above? I think you are trying to account for HAs that don't know about any authorization enabling extensions other than MN-HA Authentication extension. Won't the RRQs be silently discarded in this case, simply due to normal processing for unrecognized criticial extensions? Ahmad Muhanna: Well, according to RFC3012, forwarding MN-AAA authentication extension was forbidden in one case ONLY. If the FA did not perform authentication or in other words, before performing authentication using MN-AAA. The wording of the text in section 3.2 of RFC3012 left it optional to forward that extension. I believe, what I am trying to account for is existing HAs which recognize the MN-HA and the MN-AAA authentication extension BUT it performs only the MN-HA authentication according to RFC2002 (RFC3220). I feel it is important to leave this text to provide 100% backward compatibility and at the same time it does not affect or contradict with what RFC3220 is proposing anyway. > > b) The home agent MUST check that the registration Identification > field is correct using the context selected by the SPI within > the authorization-enabling extension that the home agent used to > authenticate the > Mobile Node's Registration Request. See Section 5.7 for a > description of how this is performed. > If incorrect, the home agent MUST reject the Request and SHOULD > send a Registration Reply to the mobile node with Code 133, > including an > Identification field computed in accordance with the rules > specified in Section 5.7. The home agent MUST do no further > processing with such a Request, though it SHOULD log the error > as a security exception. > > 2. A minor correction: > section 3.8.2.3 should read > "If the Registration Request does not satisfy all of the validity > checks > in Section 3.8.2.1,..." > > NOT > "If the Registration Reply does not satisfy all of the validity > checks > in Section 3.8.2.1,... > > 3. A slight change to your proposed text for section 3.6.1.3 item (e) > > (e) An authorization-enabling extension other than mobile-home > authentication, if present, followed by > > Otherwise, the text will allow the possibility of having two > Mobile-Home Authentication extension in the RRQ. Yes, I agree. I had considered similar wording myself, but discarded it in favor of a simpler specification - perhaps it would be OK to allow this behavior, nothing is really broken. But I can agree with your wording above. -Pete > Thanks for consideration > > Regards; > Ahmad Muhanna > > > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, March 20, 2002 10:37 AM > To: Charlie Perkins > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] A proposal for resolving a very Possible > conflictbetween RFC3220 & RFC3012 (RFC3012bis) > > > > Hi, Charlie, > > Ok, understanding the urgency, how about the following text: > > Change the first paragraph of Section 3.5.2 to read: > > At least one authorization-enabling extension MUST be present in all > Registration Requests, and also in all Registration Replies generated > by the Home Agent. This requirement is intended to eliminate problems > [2] which result from the uncontrolled propagation of remote redirects > in the Internet. The location of the extension marks the end of the > authenticated data covered by that extension. > > The Mobile-Home Authentication Extension is always an > authorization-enabling for registration messages specified in this > document; future specifications may define additional > authorization-enabling extensions. > > And the first sentence of Section 3.6: > > A mobile node MUST be configured with a netmask and a mobility > security association for each of its pre-assigned home agents or > home agents that could be discovered on a home subnet according > to procedures in Section 3.6.1.2. > > Also, I assume that the missing text people have been discussing > covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I > can't find it there now. > > Also, I think the text in 3.6.1.3 (section header currently missing) > needs to change to: > > a) The IP header, followed by the UDP header, followed by the > fixed-length portion of the Registration Request, followed by > > b) If present, any non-authentication Extensions expected to be > used by the home agent (which may or may not also be useful to > the foreign agent), followed by > > c) A mobile-home authentication extension, if present, followed by > > d) If present, any non-authentication Extensions used only by the > foreign agent, followed by > > e) An authorization-enabling extension, if present, followed by > > f) The Mobile-Foreign Authentication Extension, if present. > > Note that item (a) and at least one of (c) or (e) MUST appear in > every Registration Request sent by the mobile node. Items (b), (d), > and (f) are optional. However, item (f) MUST be included when the > mobile node and the foreign agent share a mobility security > association. > > > I think that should do it. > > -Pete > > > > > > > Charlie Perkins writes: > > > > Hello Pete, > > > > Pete McCann wrote: > > > > > I believe we will need to update the MN-HA key in the first RRQ/RRP, > > > sometimes. > > > > > > Maybe the right approach is to update the text in 3220 to explicitly > > > allow zero security associations with home agents, if some other > > > "authorization enabling extension" is present in the message. > > > > If so, the time to do so would be this week, so that we can get it in at > > the same time we supply the mysteriously vanished text, and update the > > "exactly one", and relieve the possibility for misinterpretation that was > > noticed during Connectathon. > > > > Regards, > > Charlie P. > > > > ------_=_NextPart_001_01C1D44E.97C062F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] A proposal for resolving a very Possible = conflict between RFC3220 & RFC3012 (RFC3012bis)

Hi, Pete,
Please see my one comment inline.

Also, please let me know what you think of the = following part of the proposed text:

"
        a) The = home agent MUST check for the presence of at least one
           = authorization-enabling extension, and perform only one of the = indicated
          = authentication(s).  At least one authorization-enabling = extension
          MUST be = present in the Registration Request;...............
"
I proposed  ".., and perform only one of = the indicated authentication(s)....."
OVER "...., and perform at least one the = indicated authentication(s) ......."
for the following reason:

In point (b) in the same section:
"
      b) The home agent = MUST check that the registration Identification
          field = is correct using the context selected by the SPI within
          the = authorization-enabling extension that the home agent used to
          = authenticate the Mobile Node's Registration Request. ....
"
The standard says that the home agent MUST check = that the registration Identification
according to the context selected by the SPI within = the authorization-enabling extension.

Therefore, it makes more sense to define ONLY one = authentication to be done and
use the SPI of that authorization extension to = reference the context which specifies
the registration identification.

I hope that you did not miss this part and you still = agree with it.

Regards;
Ahmad Muhanna


-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: Monday, March 25, 2002 3:45 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; = mobile-ip@sunroof.eng.sun.com
Cc: 'Charles E. Perkins'
Subject: RE: [mobile-ip] A proposal for resolving a = very Possible
conflict between RFC3220 & RFC3012 = (RFC3012bis)



Hi, Ahmad,

I agree with most of your proposed text, but one = comment below:

Ahmad Muhanna writes:
 > Hi Pete;
 >
 > With the understanding as in my response = to Charlie in the previous email.
 > There is no backward compatibility issue = with existing HA (RFC2002 &
 > RFC3012) receiving a RRQ message with = ONLY a MN-AAA authentication extension
 > (see previous email)
 >
 > There are several places where we need to = address the issue of EXACTLY vs.
 > At least. The following are the proposed = texts:
 >
 > 1.   8.2.1. Validity = Checks
 >
 >    Registration Requests = with an invalid, non-zero UDP checksum MUST be
 >    silently discarded by = the home agent.
 >
 >    The authentication in = the Registration Request MUST be checked.  This
 >    involves the following = operations:
 >
 >       a) = The home agent MUST check for the presence of at least one
 >         = ; authorization-enabling extension, and perform only one of the
 > indicated
 >         = ; authentication(s).  At least one authorization-enabling = extension
 >         = ; MUST be present in the Registration Request; and the home = agent
 >         = ; MUST either check the Authenticator value in the extension or
 >         = ; verify that the authenticator value has been checked by = another
 >         = ; agent with which it has a security association.  If no
 >         = ; authorization-enabling extension is found, or if the
 >         = ; Authenticator is invalid, the home agent MUST reject the = mobile
 >         = ; node's registration and SHOULD send a Registration Reply to = the
 >         = ; mobile node with Code 131.  The home agent MUST then = discard
 >         = ; the Request and SHOULD log the error as a security exception.

 >         = ; If the home agent receives a Registration Request without a
 > Mobile-Home
 >         = ; Authentication extension from a Mobile Node that does not have a =
 >         = ; security association with this home agent, the home agent MAY
 >         = ; discard the Mobile Node's Registration Request.

Do we really need this last sentence above?  I = think you are trying to
account for HAs that don't know about any = authorization enabling
extensions other than MN-HA Authentication = extension.  Won't the RRQs
be silently discarded in this case, simply due to = normal processing
for unrecognized criticial extensions?

Ahmad Muhanna:
Well, according to RFC3012, forwarding MN-AAA = authentication extension
was forbidden in one case ONLY. If the FA did not = perform authentication or in other words,
before performing authentication using MN-AAA. The = wording of the text in section 3.2 of RFC3012
left it optional to forward that extension.

I believe, what I am trying to account for is = existing HAs which recognize the MN-HA
and the MN-AAA authentication extension BUT it = performs only the MN-HA authentication
according to RFC2002 (RFC3220).

I feel it is important to leave this text to provide = 100% backward compatibility and at
the same time it does not affect or contradict with = what RFC3220 is proposing anyway.

 >
 >      b) The home = agent MUST check that the registration Identification
 >         = ; field is correct using the context selected by the SPI within
 >         = ; the authorization-enabling extension that the home agent used = to
 > authenticate the
 >         = ; Mobile Node's Registration Request.  See Section 5.7 for = a
 > description of how this is = performed. 
 >         = ; If incorrect, the home agent MUST reject the Request and SHOULD =
 >         = ; send a Registration Reply to the mobile node with Code 133,
 > including an
 >         = ; Identification field computed in accordance with the rules
 >         = ; specified in Section 5.7.  The home agent MUST do no = further
 >         = ; processing with such a Request, though it SHOULD log the error
 >         = ; as a security exception.
 >
 > 2.   A minor correction:
 >      section 3.8.2.3 = should read
 >      "If the = Registration Request does not satisfy all of the validity
 > checks
 >      in Section = 3.8.2.1,..."
 >
 >      NOT
 >      "If the = Registration Reply does not satisfy all of the validity
 > checks
 >      in Section = 3.8.2.1,...
 >
 > 3.   A slight change to your = proposed text for section 3.6.1.3 item (e)
 >
 >      (e) An = authorization-enabling extension other than mobile-home
 > authentication, if present, followed = by
 >
 >      Otherwise, the = text will allow the possibility of having two
 > Mobile-Home Authentication extension in = the RRQ.

Yes, I agree.  I had considered similar wording = myself, but discarded
it in favor of a simpler specification - perhaps it = would be OK to
allow this behavior, nothing is really broken.  = But I can agree with
your wording above.

-Pete


 > Thanks for = consideration    
 >
 > Regards;
 > Ahmad Muhanna
 >
 >
 >
 > -----Original Message-----
 > From: Pete McCann [mailto:mccap@lucent.com]
 > Sent: Wednesday, March 20, 2002 10:37 = AM
 > To: Charlie Perkins
 > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; = 'mobile-ip@sunroof.eng.sun.com'
 > Subject: Re: [mobile-ip] A proposal for = resolving a very Possible
 > conflictbetween RFC3220 & RFC3012 = (RFC3012bis)
 >
 >
 >
 > Hi, Charlie,
 >
 > Ok, understanding the urgency, how about = the following text:
 >
 > Change the first paragraph of Section = 3.5.2 to read:
 >
 >   At least one = authorization-enabling extension MUST be present in all
 >   Registration Requests, and = also in all Registration Replies generated
 >   by the Home Agent.  This = requirement is intended to eliminate problems
 >   [2] which result from the = uncontrolled propagation of remote redirects
 >   in the Internet.  The = location of the extension marks the end of the
 >   authenticated data covered by = that extension.
 >
 >   The Mobile-Home = Authentication Extension is always an
 >   authorization-enabling for = registration messages specified in this
 >   document; future = specifications may define additional
 >   authorization-enabling = extensions.
 >
 > And the first sentence of Section = 3.6:
 >
 >    A mobile node MUST be = configured with a netmask and a mobility
 >    security association = for each of its pre-assigned home agents or
 >    home agents that could = be discovered on a home subnet according
 >    to procedures in = Section 3.6.1.2.
 >
 > Also, I assume that the missing text = people have been discussing
 > covers the subnet-directed broadcast = discovery mechanism in 3.6.1.2; I
 > can't find it there now.
 >
 > Also, I think the text in 3.6.1.3 = (section header currently missing)
 > needs to change to:
 >
 >       a) = The IP header, followed by the UDP header, followed by the
 >         = ; fixed-length portion of the Registration Request, followed by
 >
 >       b) If = present, any non-authentication Extensions expected to be
 >         = ; used by the home agent (which may or may not also be useful to
 >         = ; the foreign agent), followed by
 >
 >       c) A = mobile-home authentication extension, if present, followed by
 >
 >       d) If = present, any non-authentication Extensions used only by the
 >         = ; foreign agent, followed by
 >
 >       e) An = authorization-enabling extension, if present, followed by
 >
 >       f) = The Mobile-Foreign Authentication Extension, if present.
 >
 >    Note that item (a) and = at least one of (c) or (e) MUST appear in
 >    every Registration = Request sent by the mobile node.  Items (b), (d),
 >    and (f) are = optional.  However, item (f) MUST be included when the
 >    mobile node and the = foreign agent share a mobility security
 >    association.
 >
 >
 > I think that should do it.
 >
 > -Pete
 >
 >
 >
 >
 >
 >
 > Charlie Perkins writes:
 >  >
 >  > Hello Pete,
 >  >
 >  > Pete McCann wrote:
 >  >
 >  > > I believe we will need to = update the MN-HA key in the first RRQ/RRP,
 >  > > sometimes.
 >  > >
 >  > > Maybe the right approach = is to update the text in 3220 to explicitly
 >  > > allow zero security = associations with home agents, if some other
 >  > > "authorization = enabling extension" is present in the message.
 >  >
 >  > If so, the time to do so would = be this week, so that we can get it in at
 >  > the same time we supply the = mysteriously vanished text, and update the
 >  > "exactly one", and = relieve the possibility for misinterpretation that was
 >  > noticed during Connectathon.
 >  >
 >  > Regards,
 >  > Charlie P.
 >  >
 >  >

------_=_NextPart_001_01C1D44E.97C062F0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 18:08: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 SAA07376 for ; Mon, 25 Mar 2002 18:08: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 QAA06395; Mon, 25 Mar 2002 16:08: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 PAA27757; Mon, 25 Mar 2002 15:08: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 g2PN7TKL008015 for ; Mon, 25 Mar 2002 15:07:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PN7SRF008014 for mobile-ip-dist; Mon, 25 Mar 2002 15:07: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 g2PN7NKL008004 for ; Mon, 25 Mar 2002 15:07:24 -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 PAA15213 for ; Mon, 25 Mar 2002 15:07:24 -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 QAA20697 for ; Mon, 25 Mar 2002 16:07:24 -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 EC9BE285D for ; Mon, 25 Mar 2002 15:07:09 -0800 (PST) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 1011C2214 for ; Mon, 25 Mar 2002 17:07:23 -0600 (CST) Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id SAA0000807397; Mon, 25 Mar 2002 18:07:22 -0500 (EST) Message-ID: <3C9FADAA.5DDFD408@compaq.com> Date: Mon, 25 Mar 2002 18:07:22 -0500 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile ip Subject: [mobile-ip] Comments on Draft 16 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, Here are my initial comments on mipv6 draft 16 changes, I will do a more thorough reading later... -Brian ------------------------------------------------------------------------ 4.5.4 Securing Binding Updates to Home Agents > Both the mobile node and the home agent MUST use non-volatile memory > to store the sequence number so that a reboot does not prevent the > acceptance of new Binding Updates. Why is this a MUST and not a SHOULD (or MAY)? A reboot of the Home Agent will not prevent it from accepting a Binding Update from a Mobile Node with *any* sequence number, and we already have an error code (141 - Sequence number out of window) to re-synchronize the sequence number, since the last-used number is sent in the BAck. This section also incorrectly assumes a sequence number is 32-bits, but it's only 16. ------------------------------------------------------------------------ 5.1.4 Care-of Test Init (CoTI) Message > If no actual parameters are present in this message, no padding is necessary. This isn't correct, there are 4 bytes of padding necessary. BTW, the HoTI Message section has this right. ------------------------------------------------------------------------ 5.1.7 Binding Update (BU) Message > If no actual parameters are present in this message, 4 bytes of Pad1 or > PadN parameters are needed to make the length of the message a multiple > of 8. I don't believe any padding is necessary. ------------------------------------------------------------------------ 5.1.8 Binding Acknowledgement (BA) Message > Lifetime section > Correspondent nodes SHOULD also retain a BCE entry for the purposes of > accepting Home Address Options somewhat longer than they keep on using > the entry for Route Optimization of outgoing packets. This helps to > avoid dropped packets, particularly when clock drift can be a problem. This can be problematic, and is in disagreement with Section 8.3 - "Any Binding Cache entry MUST be deleted after the expiration of this lifetime in the Binding Cache entry." I would propose: "Mobile Nodes SHOULD send a new Binding Update before the expiration of this period in order to extend the lifetime and not cause a disruption in communications". And regarding the Refresh field, I'm the one that proposed removing this field, since the onus should be on the Mobile Node to choose an adequate amount of time before the lifetime expires, account for RTTs, etc., to refresh the binding. Charlie asked if it could be moved into a sub-option if removed, and that is fine with me - I guess it could be a way for a CN to implement an LRU cache replacement policy. Same section: > The Binding Acknowledgement is sent to the source address of the > Binding Update message, regardless of whether the Binding Update > succeeded or failed. No Routing Headers are inserted to the message. This looks wrong, the BAck should be sent to the home address via the care-of address with a Routing Header, which accomodates use of the Alternate COA option. This is a change from draft 15. ------------------------------------------------------------------------ General comment about Section 5.1.* - it would be nice if every Message description section included the length (or minimum length) requirement for the Mobility Header "Header Len" field, this way it's obvious to implementors. For example in Section 5.1.7: "The Header Length field in the Mobility Header for the Binding Update message MUST be set to 32 plus the total length of all parameters present." ------------------------------------------------------------------------ 5.3 Home Address Option > A packet MUST NOT contain more than one Home Address option, except that an > encapsulated packet [?] MAY contain a separate Home Address option associated > with each encapsulating IP header. Ok, I'll go down this path again - it was found at Connectathon 2001 (yes, 2001) that "conformance" tests that sent a packet with two back-to-back HAOs caused some vendors to send an ICMPv6 Parameter Problem message, and others to accept it, over-writing the old HAO with the new. Now that we must lookup a BCE to accept the HAO, it seems prudent that we should reject this case. ------------------------------------------------------------------------ 10.3 Receiving Packets While Away from Home This section mentions "Routing header", but should be specific that it's a type 2 Routing header that's to be used for CN->MN RO communications. From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 18:10: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 SAA07467 for ; Mon, 25 Mar 2002 18:10:48 -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 PAA13153; Mon, 25 Mar 2002 15:08: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 PAA27910; Mon, 25 Mar 2002 15:08: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 g2PN7PKL008012 for ; Mon, 25 Mar 2002 15:07:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PN7Oua008005 for mobile-ip-dist; Mon, 25 Mar 2002 15:07: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 g2PN7KKL007995 for ; Mon, 25 Mar 2002 15:07:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15173 for ; Mon, 25 Mar 2002 15:07:21 -0800 (PST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27178 for ; Mon, 25 Mar 2002 15:07:22 -0800 (PST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2PN7A819126; Mon, 25 Mar 2002 18:07:10 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA26212; Mon, 25 Mar 2002 17:07:09 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id RAA29948; Mon, 25 Mar 2002 17:07:09 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15519.44445.528253.830631@nwsgpb.ih.lucent.com> Date: Mon, 25 Mar 2002 17:07:09 -0600 (CST) From: Pete McCann To: "Ahmad Muhanna" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'Charles E. Perkins'" Subject: RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCB08@zrc2c013.us.nortel.com> References: <6B49EDFE974BD51197D70002A56079D801AFCB08@zrc2c013.us.nortel.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-mobile-ip@sunroof.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, Ahmad, Yes, I think I understand the reasoning that went into this. I agree with your proposal. -Pete Ahmad Muhanna writes: > Hi, Pete, > Please see my one comment inline. > > Also, please let me know what you think of the following part of the > proposed text: > > " > a) The home agent MUST check for the presence of at least one > authorization-enabling extension, and perform only one of the > indicated > authentication(s). At least one authorization-enabling extension > MUST be present in the Registration Request;............... > " > I proposed ".., and perform only one of the indicated > authentication(s)....." > OVER "...., and perform at least one the indicated authentication(s) > ......." > for the following reason: > > In point (b) in the same section: > " > b) The home agent MUST check that the registration Identification > field is correct using the context selected by the SPI within > the authorization-enabling extension that the home agent used to > authenticate the Mobile Node's Registration Request. .... > " > The standard says that the home agent MUST check that the registration > Identification > according to the context selected by the SPI within the > authorization-enabling extension. > > Therefore, it makes more sense to define ONLY one authentication to be done > and > use the SPI of that authorization extension to reference the context which > specifies > the registration identification. > > I hope that you did not miss this part and you still agree with it. > > Regards; > Ahmad Muhanna > > > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Monday, March 25, 2002 3:45 PM > To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; mobile-ip@sunroof.eng.sun.com > Cc: 'Charles E. Perkins' > Subject: RE: [mobile-ip] A proposal for resolving a very Possible > conflict between RFC3220 & RFC3012 (RFC3012bis) > > > > Hi, Ahmad, > > I agree with most of your proposed text, but one comment below: > > Ahmad Muhanna writes: > > Hi Pete; > > > > With the understanding as in my response to Charlie in the previous > email. > > There is no backward compatibility issue with existing HA (RFC2002 & > > RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication > extension > > (see previous email) > > > > There are several places where we need to address the issue of EXACTLY > vs. > > At least. The following are the proposed texts: > > > > 1. 8.2.1. Validity Checks > > > > Registration Requests with an invalid, non-zero UDP checksum MUST be > > silently discarded by the home agent. > > > > The authentication in the Registration Request MUST be checked. This > > involves the following operations: > > > > a) The home agent MUST check for the presence of at least one > > authorization-enabling extension, and perform only one of the > > indicated > > authentication(s). At least one authorization-enabling > extension > > MUST be present in the Registration Request; and the home agent > > MUST either check the Authenticator value in the extension or > > verify that the authenticator value has been checked by another > > agent with which it has a security association. If no > > authorization-enabling extension is found, or if the > > Authenticator is invalid, the home agent MUST reject the mobile > > node's registration and SHOULD send a Registration Reply to the > > mobile node with Code 131. The home agent MUST then discard > > the Request and SHOULD log the error as a security exception. > > > If the home agent receives a Registration Request without a > > Mobile-Home > > Authentication extension from a Mobile Node that does not have a > > > security association with this home agent, the home agent MAY > > discard the Mobile Node's Registration Request. > > Do we really need this last sentence above? I think you are trying to > account for HAs that don't know about any authorization enabling > extensions other than MN-HA Authentication extension. Won't the RRQs > be silently discarded in this case, simply due to normal processing > for unrecognized criticial extensions? > > Ahmad Muhanna: > Well, according to RFC3012, forwarding MN-AAA authentication extension > was forbidden in one case ONLY. If the FA did not perform authentication or > in other words, > before performing authentication using MN-AAA. The wording of the text in > section 3.2 of RFC3012 > left it optional to forward that extension. > > I believe, what I am trying to account for is existing HAs which recognize > the MN-HA > and the MN-AAA authentication extension BUT it performs only the MN-HA > authentication > according to RFC2002 (RFC3220). > > I feel it is important to leave this text to provide 100% backward > compatibility and at > the same time it does not affect or contradict with what RFC3220 is > proposing anyway. > > > > > b) The home agent MUST check that the registration Identification > > field is correct using the context selected by the SPI within > > the authorization-enabling extension that the home agent used to > > authenticate the > > Mobile Node's Registration Request. See Section 5.7 for a > > description of how this is performed. > > If incorrect, the home agent MUST reject the Request and SHOULD > > send a Registration Reply to the mobile node with Code 133, > > including an > > Identification field computed in accordance with the rules > > specified in Section 5.7. The home agent MUST do no further > > processing with such a Request, though it SHOULD log the error > > as a security exception. > > > > 2. A minor correction: > > section 3.8.2.3 should read > > "If the Registration Request does not satisfy all of the validity > > checks > > in Section 3.8.2.1,..." > > > > NOT > > "If the Registration Reply does not satisfy all of the validity > > checks > > in Section 3.8.2.1,... > > > > 3. A slight change to your proposed text for section 3.6.1.3 item (e) > > > > (e) An authorization-enabling extension other than mobile-home > > authentication, if present, followed by > > > > Otherwise, the text will allow the possibility of having two > > Mobile-Home Authentication extension in the RRQ. > > Yes, I agree. I had considered similar wording myself, but discarded > it in favor of a simpler specification - perhaps it would be OK to > allow this behavior, nothing is really broken. But I can agree with > your wording above. > > -Pete > > > > Thanks for consideration > > > > Regards; > > Ahmad Muhanna > > > > > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Wednesday, March 20, 2002 10:37 AM > > To: Charlie Perkins > > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' > > Subject: Re: [mobile-ip] A proposal for resolving a very Possible > > conflictbetween RFC3220 & RFC3012 (RFC3012bis) > > > > > > > > Hi, Charlie, > > > > Ok, understanding the urgency, how about the following text: > > > > Change the first paragraph of Section 3.5.2 to read: > > > > At least one authorization-enabling extension MUST be present in all > > Registration Requests, and also in all Registration Replies generated > > by the Home Agent. This requirement is intended to eliminate problems > > [2] which result from the uncontrolled propagation of remote redirects > > in the Internet. The location of the extension marks the end of the > > authenticated data covered by that extension. > > > > The Mobile-Home Authentication Extension is always an > > authorization-enabling for registration messages specified in this > > document; future specifications may define additional > > authorization-enabling extensions. > > > > And the first sentence of Section 3.6: > > > > A mobile node MUST be configured with a netmask and a mobility > > security association for each of its pre-assigned home agents or > > home agents that could be discovered on a home subnet according > > to procedures in Section 3.6.1.2. > > > > Also, I assume that the missing text people have been discussing > > covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I > > can't find it there now. > > > > Also, I think the text in 3.6.1.3 (section header currently missing) > > needs to change to: > > > > a) The IP header, followed by the UDP header, followed by the > > fixed-length portion of the Registration Request, followed by > > > > b) If present, any non-authentication Extensions expected to be > > used by the home agent (which may or may not also be useful to > > the foreign agent), followed by > > > > c) A mobile-home authentication extension, if present, followed by > > > > d) If present, any non-authentication Extensions used only by the > > foreign agent, followed by > > > > e) An authorization-enabling extension, if present, followed by > > > > f) The Mobile-Foreign Authentication Extension, if present. > > > > Note that item (a) and at least one of (c) or (e) MUST appear in > > every Registration Request sent by the mobile node. Items (b), (d), > > and (f) are optional. However, item (f) MUST be included when the > > mobile node and the foreign agent share a mobility security > > association. > > > > > > I think that should do it. > > > > -Pete > > > > > > > > > > > > > > Charlie Perkins writes: > > > > > > Hello Pete, > > > > > > Pete McCann wrote: > > > > > > > I believe we will need to update the MN-HA key in the first RRQ/RRP, > > > > sometimes. > > > > > > > > Maybe the right approach is to update the text in 3220 to explicitly > > > > allow zero security associations with home agents, if some other > > > > "authorization enabling extension" is present in the message. > > > > > > If so, the time to do so would be this week, so that we can get it in > at > > > the same time we supply the mysteriously vanished text, and update the > > > "exactly one", and relieve the possibility for misinterpretation that > was > > > noticed during Connectathon. > > > > > > Regards, > > > Charlie P. > > > > > > > > > > > > RE: [mobile-ip] A proposal for resolving a very Possible conflict between RFC3220 & RFC3012 (RFC3012bis) > > > >

Hi, Pete, >
Please see my one comment inline. >

> >

Also, please let me know what you think of the following part of the proposed text: >

> >

" >
        a) The home agent MUST check for the presence of at least one >
           authorization-enabling extension, and perform only one of the indicated >
          authentication(s).  At least one authorization-enabling extension >
          MUST be present in the Registration Request;............... >
" >
I proposed  ".., and perform only one of the indicated authentication(s)....." >
OVER "...., and perform at least one the indicated authentication(s) ......." >
for the following reason: >

> >

In point (b) in the same section: >
" >
      b) The home agent MUST check that the registration Identification >
          field is correct using the context selected by the SPI within >
          the authorization-enabling extension that the home agent used to >
          authenticate the Mobile Node's Registration Request. .... >
" >
The standard says that the home agent MUST check that the registration Identification >
according to the context selected by the SPI within the authorization-enabling extension. >

> >

Therefore, it makes more sense to define ONLY one authentication to be done and >
use the SPI of that authorization extension to reference the context which specifies >
the registration identification. >

> >

I hope that you did not miss this part and you still agree with it. >

> >

Regards; >
Ahmad Muhanna >

>
> >

-----Original Message----- >
From: Pete McCann [mailto:mccap@lucent.com] >
Sent: Monday, March 25, 2002 3:45 PM >
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; mobile-ip@sunroof.eng.sun.com >
Cc: 'Charles E. Perkins' >
Subject: RE: [mobile-ip] A proposal for resolving a very Possible >
conflict between RFC3220 & RFC3012 (RFC3012bis) >

>
>
> >

Hi, Ahmad, >

> >

I agree with most of your proposed text, but one comment below: >

> >

Ahmad Muhanna writes: >
 > Hi Pete; >
 > >
 > With the understanding as in my response to Charlie in the previous email. >
 > There is no backward compatibility issue with existing HA (RFC2002 & >
 > RFC3012) receiving a RRQ message with ONLY a MN-AAA authentication extension >
 > (see previous email) >
 > >
 > There are several places where we need to address the issue of EXACTLY vs. >
 > At least. The following are the proposed texts: >
 > >
 > 1.   8.2.1. Validity Checks >
 > >
 >    Registration Requests with an invalid, non-zero UDP checksum MUST be >
 >    silently discarded by the home agent. >
 > >
 >    The authentication in the Registration Request MUST be checked.  This >
 >    involves the following operations: >
 > >
 >       a) The home agent MUST check for the presence of at least one >
 >          authorization-enabling extension, and perform only one of the >
 > indicated >
 >          authentication(s).  At least one authorization-enabling extension >
 >          MUST be present in the Registration Request; and the home agent >
 >          MUST either check the Authenticator value in the extension or >
 >          verify that the authenticator value has been checked by another >
 >          agent with which it has a security association.  If no >
 >          authorization-enabling extension is found, or if the >
 >          Authenticator is invalid, the home agent MUST reject the mobile >
 >          node's registration and SHOULD send a Registration Reply to the >
 >          mobile node with Code 131.  The home agent MUST then discard >
 >          the Request and SHOULD log the error as a security exception. >

> >

 >          If the home agent receives a Registration Request without a >
 > Mobile-Home >
 >          Authentication extension from a Mobile Node that does not have a >
 >          security association with this home agent, the home agent MAY >
 >          discard the Mobile Node's Registration Request. >

> >

Do we really need this last sentence above?  I think you are trying to >
account for HAs that don't know about any authorization enabling >
extensions other than MN-HA Authentication extension.  Won't the RRQs >
be silently discarded in this case, simply due to normal processing >
for unrecognized criticial extensions? >

> >

Ahmad Muhanna: >
Well, according to RFC3012, forwarding MN-AAA authentication extension >
was forbidden in one case ONLY. If the FA did not perform authentication or in other words, >
before performing authentication using MN-AAA. The wording of the text in section 3.2 of RFC3012 >
left it optional to forward that extension. >

> >

I believe, what I am trying to account for is existing HAs which recognize the MN-HA >
and the MN-AAA authentication extension BUT it performs only the MN-HA authentication >
according to RFC2002 (RFC3220). >

> >

I feel it is important to leave this text to provide 100% backward compatibility and at >
the same time it does not affect or contradict with what RFC3220 is proposing anyway. >

> >

 > >
 >      b) The home agent MUST check that the registration Identification >
 >          field is correct using the context selected by the SPI within >
 >          the authorization-enabling extension that the home agent used to >
 > authenticate the >
 >          Mobile Node's Registration Request.  See Section 5.7 for a >
 > description of how this is performed.  >
 >          If incorrect, the home agent MUST reject the Request and SHOULD >
 >          send a Registration Reply to the mobile node with Code 133, >
 > including an >
 >          Identification field computed in accordance with the rules >
 >          specified in Section 5.7.  The home agent MUST do no further >
 >          processing with such a Request, though it SHOULD log the error >
 >          as a security exception. >
 > >
 > 2.   A minor correction: >
 >      section 3.8.2.3 should read >
 >      "If the Registration Request does not satisfy all of the validity >
 > checks >
 >      in Section 3.8.2.1,..." >
 > >
 >      NOT >
 >      "If the Registration Reply does not satisfy all of the validity >
 > checks >
 >      in Section 3.8.2.1,... >
 > >
 > 3.   A slight change to your proposed text for section 3.6.1.3 item (e) >
 > >
 >      (e) An authorization-enabling extension other than mobile-home >
 > authentication, if present, followed by >
 > >
 >      Otherwise, the text will allow the possibility of having two >
 > Mobile-Home Authentication extension in the RRQ. >

> >

Yes, I agree.  I had considered similar wording myself, but discarded >
it in favor of a simpler specification - perhaps it would be OK to >
allow this behavior, nothing is really broken.  But I can agree with >
your wording above. >

> >

-Pete >

>
> >

 > Thanks for consideration     >
 > >
 > Regards; >
 > Ahmad Muhanna >
 > >
 > >
 > >
 > -----Original Message----- >
 > From: Pete McCann [mailto:mccap@lucent.com] >
 > Sent: Wednesday, March 20, 2002 10:37 AM >
 > To: Charlie Perkins >
 > Cc: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'mobile-ip@sunroof.eng.sun.com' >
 > Subject: Re: [mobile-ip] A proposal for resolving a very Possible >
 > conflictbetween RFC3220 & RFC3012 (RFC3012bis) >
 > >
 > >
 > >
 > Hi, Charlie, >
 > >
 > Ok, understanding the urgency, how about the following text: >
 > >
 > Change the first paragraph of Section 3.5.2 to read: >
 > >
 >   At least one authorization-enabling extension MUST be present in all >
 >   Registration Requests, and also in all Registration Replies generated >
 >   by the Home Agent.  This requirement is intended to eliminate problems >
 >   [2] which result from the uncontrolled propagation of remote redirects >
 >   in the Internet.  The location of the extension marks the end of the >
 >   authenticated data covered by that extension. >
 > >
 >   The Mobile-Home Authentication Extension is always an >
 >   authorization-enabling for registration messages specified in this >
 >   document; future specifications may define additional >
 >   authorization-enabling extensions. >
 > >
 > And the first sentence of Section 3.6: >
 > >
 >    A mobile node MUST be configured with a netmask and a mobility >
 >    security association for each of its pre-assigned home agents or >
 >    home agents that could be discovered on a home subnet according >
 >    to procedures in Section 3.6.1.2. >
 > >
 > Also, I assume that the missing text people have been discussing >
 > covers the subnet-directed broadcast discovery mechanism in 3.6.1.2; I >
 > can't find it there now. >
 > >
 > Also, I think the text in 3.6.1.3 (section header currently missing) >
 > needs to change to: >
 > >
 >       a) The IP header, followed by the UDP header, followed by the >
 >          fixed-length portion of the Registration Request, followed by >
 > >
 >       b) If present, any non-authentication Extensions expected to be >
 >          used by the home agent (which may or may not also be useful to >
 >          the foreign agent), followed by >
 > >
 >       c) A mobile-home authentication extension, if present, followed by >
 > >
 >       d) If present, any non-authentication Extensions used only by the >
 >          foreign agent, followed by >
 > >
 >       e) An authorization-enabling extension, if present, followed by >
 > >
 >       f) The Mobile-Foreign Authentication Extension, if present. >
 > >
 >    Note that item (a) and at least one of (c) or (e) MUST appear in >
 >    every Registration Request sent by the mobile node.  Items (b), (d), >
 >    and (f) are optional.  However, item (f) MUST be included when the >
 >    mobile node and the foreign agent share a mobility security >
 >    association. >
 > >
 > >
 > I think that should do it. >
 > >
 > -Pete >
 > >
 > >
 > >
 > >
 > >
 > >
 > Charlie Perkins writes: >
 >  > >
 >  > Hello Pete, >
 >  > >
 >  > Pete McCann wrote: >
 >  > >
 >  > > I believe we will need to update the MN-HA key in the first RRQ/RRP, >
 >  > > sometimes. >
 >  > > >
 >  > > Maybe the right approach is to update the text in 3220 to explicitly >
 >  > > allow zero security associations with home agents, if some other >
 >  > > "authorization enabling extension" is present in the message. >
 >  > >
 >  > If so, the time to do so would be this week, so that we can get it in at >
 >  > the same time we supply the mysteriously vanished text, and update the >
 >  > "exactly one", and relieve the possibility for misinterpretation that was >
 >  > noticed during Connectathon. >
 >  > >
 >  > Regards, >
 >  > Charlie P. >
 >  > >
 >  > >

> > > From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 19:51: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 TAA09493 for ; Mon, 25 Mar 2002 19:51: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 RAA18489; Mon, 25 Mar 2002 17:50: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 QAA09033; Mon, 25 Mar 2002 16:50: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 g2Q0ncKL008418 for ; Mon, 25 Mar 2002 16:49:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2Q0ncS7008417 for mobile-ip-dist; Mon, 25 Mar 2002 16:49: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 g2Q0nYKL008410 for ; Mon, 25 Mar 2002 16:49:34 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05374 for ; Mon, 25 Mar 2002 16:49:36 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23894 for ; Mon, 25 Mar 2002 16:49:24 -0800 (PST) Received: from yokote (dhcp52.docomolabs-usa.com [172.21.96.52]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with ESMTP id g2Q0nZI14622 for ; Mon, 25 Mar 2002 16:49:35 -0800 (PST) Message-Id: <4.2.0.58.J.20020325164131.00bca0a8@172.21.96.233> X-Sender: yokote@172.21.96.233 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 25 Mar 2002 16:41:47 -0800 To: mobile-ip@sunroof.eng.sun.com From: Aki Yokote Subject: [mobile-ip] draft-yokote-mobileip-api-00.txt 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, I submitted draft-yokote-mobileip-api-00.txt, But I didn't see the announcement on the mobile IP mailing list. Could you please announce this draft? And I look forward to get comments on this. Thank you. >----- Original Message ----- >From: "Aki Yokote" >To: >Cc: "Alper Yegin" ; ; >; ; > >Sent: Thursday, February 21, 2002 2:55 PM >Subject: Individual IETF draft submission > > > > Dear IETF draft editors, > > > > > > This is a request for an individual draft submission. If you can process > > this request and publish this work in the IETF draft directory, we'll > > appreciate. > > > > > > Title: Mobile IP API > > Authors: A. Yokote, A. E. Yegin, M. Tariq, C.Williams, A. Takeshita > > Filename: draft-yokote-mobileip-api-00.txt > > Pages: 8 > > Date: 21 February 2002 > > Interested working group: Mobileip. > > > > > > Abstract > > > > The Mobile IP API is an interface between the mobility management and the > > application layer. Using Mobile IP API, the applications can extract the > > mobility information that is already maintained by the mobility management > > module. API simply provides awareness of mobility for applications. This > > document describes application scenarios followed by requirements for > > Mobile IP API. Application scenarios are example applications that can > > take advantage of the mobility information. The requirements are intended > > to define the scope of a Mobile IP API and guide the design of API > > implementation. > > > > > > Best Regards, > > Aki Yokote > > DoCoMo Labs USA From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 20:04: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 UAA09768 for ; Mon, 25 Mar 2002 20:04: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 SAA20201; Mon, 25 Mar 2002 18:03: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 RAA11679; Mon, 25 Mar 2002 17:03: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 g2Q12mKL008541 for ; Mon, 25 Mar 2002 17:02:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2Q12mEt008540 for mobile-ip-dist; Mon, 25 Mar 2002 17:02: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 purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2Q12jKL008533 for ; Mon, 25 Mar 2002 17:02:45 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2Q12kg28060 for ; Mon, 25 Mar 2002 20:02:46 -0500 (EST) Date: Mon, 25 Mar 2002 20:03:41 -0500 (EST) From: "Steven M. Glass" Subject: [mobile-ip] Posting size limit reminder 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: There have been a few rather large posts to the list recently (as large as 211K), so I wanted to remind people that there's [currently] a 40K (40000B) limit on posts; anything more is bounced. Thoughts: Text is cheap, proprietary doc format are usually not. -even those dual-mode txt/html emailers are more pricey than you think. Just because you think you're pasting in text doesn't mean you are. Some 'widely deployed' editors have non-printable characters mixed in. Don't include the *entire* message if you're just replying to a piece. Especially if you see text that looks like it came from the above! If, for some reason all of what you're sending *needs* to go to the list, e.g. this *needs* to be in the archive in it's raw form, not just a pointer, let me know (preferably before you send it). Cheers, your friendly, but strict, list admin From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 20:05: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 UAA09782 for ; Mon, 25 Mar 2002 20:05: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 SAA24133; Mon, 25 Mar 2002 18:04: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 RAA11982; Mon, 25 Mar 2002 17:04: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 g2Q13sKL008558 for ; Mon, 25 Mar 2002 17:03:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2Q13sNP008557 for mobile-ip-dist; Mon, 25 Mar 2002 17:03: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 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 g2Q13qKL008550 for ; Mon, 25 Mar 2002 17:03:52 -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 UAA26947 for ; Mon, 25 Mar 2002 20:03:54 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id UAA19555 for mobile-ip@sunroof.eng.sun.com; Mon, 25 Mar 2002 20:04:49 -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 g2IIZSKL009681 for ; Mon, 18 Mar 2002 10:35: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 KAA14485 for ; Mon, 18 Mar 2002 10:35:28 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25383 for ; Mon, 18 Mar 2002 10:35:28 -0800 (PST) Received: from blind (blind [128.111.49.140]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g2IIZRJ20586; Mon, 18 Mar 2002 10:35:27 -0800 (PST) Date: Mon, 18 Mar 2002 10:35:27 -0800 (PST) From: MobiHoc 2002 X-Sender: mobihoc@blind To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobiHoc 2002: Call for Participation 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: --------------------------------------------------------------------------- ANNOUNCEMENT AND CALL FOR PARTICIPATION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. PAPERS: There will be approximately seven technical paper sessions on a wide range of ad hoc networking topics. The list of accepted papers can be found at http://www.acm.org/sigmobile/mobihoc/2002/program.html. Paper topics include routing, sensor networks, scalability, multicast, energy consumption, TCP, and priority scheduling. POSTERS: There will also be a poster session, describing innovative and recent research on ad hoc networks. TUTORIALS: This year there is a new component to MobiHoc: technical tutorials. On June 9th there will be two tutorials. "Design and Modeling of Medium Access Control Protocols for Wireless Ad Hoc Networks" will be held in the morning, and "Routing & Multicasting in Ad hoc Networks" will be held in the afternoon. HOTEL and REGISTRATION: Hotel information is currently available on-line, and the symposium is open for registration. Register by April 22, 2002 to get the early registration rates. IMPORTANT DATES: Early Registration Deadline: April 22, 2002 Tutorials: June 9, 2002 Conference: June 10-11, 2002 FOR MORE INFORMATION: Please visit the MobiHoc 2002 Home Page at http://www.acm.org/sigmobile/mobihoc/2002/ or send email to mobihoc@epfl.ch for any questions or for more information about the symposium. ORGANIZING COMMITTEE: General Chair Jean-Pierre Hubaux EPFL (CH) jean-pierre.hubaux@epfl.ch Program Co-Chairs J.J. Garcia-Luna-Aceves David B. Johnson Univ. California, Santa Cruz (US) Rice University (US) jj@cs.ucsc.edu dbj@cs.rice.edu Tutorials Co-Chairs Adam Wolisz Mario Gerla Technical Univ. of Berlin (DE) Univ. California, Los Angeles (US) wolisz@ee.tu-berlin.de gerla@cs.ucla.edu Finance Chair Local Arrangements Chair Rachid Guerraoui Silvia Giordano EPFL (CH) EPFL (CH) rachid.guerraoui@epfl.ch silvia.giordano@epfl.ch Publicity Chair Publication Chair Elizabeth M. Belding-Royer Robin Kravets Univ. Calif., Santa Barbara (US) Univ. Illinois, Urbana-Champaign (US) ebelding@cs.ucsb.edu rhk@cs.uiuc.edu Steering Committee Andrew T. Campbell Charles E. Perkins J.J. Garcia-Luna-Aceves Ram Ramanathan Mario Gerla Martha Steenstrup Joseph P. Macker Nitin H. Vaidya ACM Program Director Ginger Ignatoff --------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 20:18:11 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 UAA10134 for ; Mon, 25 Mar 2002 20:18: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 RAA03320; Mon, 25 Mar 2002 17:17:41 -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 RAA14556; Mon, 25 Mar 2002 17:17: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 g2Q1GdKL008765 for ; Mon, 25 Mar 2002 17:16:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2Q1GdRe008764 for mobile-ip-dist; Mon, 25 Mar 2002 17:16: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 g2Q1GaKL008757 for ; Mon, 25 Mar 2002 17:16:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06357 for ; Mon, 25 Mar 2002 17:16:38 -0800 (PST) Received: from mta1-3.us4.outblaze.com (205-158-62-44.outblaze.com [205.158.62.44]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28444 for ; Mon, 25 Mar 2002 17:16:39 -0800 (PST) Received: from ws3-3.us4.outblaze.com (205-158-62-93.outblaze.com [205.158.62.93]) by mta1-3.us4.outblaze.com (8.11.6/8.11.6-srs) with SMTP id g2Q1GcN11089 for ; Tue, 26 Mar 2002 01:16:38 GMT Received: (qmail 31763 invoked by uid 1001); 26 Mar 2002 01:16:37 -0000 Message-ID: <20020326011637.31762.qmail@email.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from [165.213.0.2] by ws3-3.us4.outblaze.com with http for sharma_raj@email.com; Mon, 25 Mar 2002 20:16:37 -0500 From: "Rajesh Sharma" To: mobile-ip@sunroof.eng.sun.com Date: Mon, 25 Mar 2002 20:16:37 -0500 Subject: [mobile-ip] Mobility Header X-Originating-Ip: 165.213.0.2 X-Originating-Server: ws3-3.us4.outblaze.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 Hi, I was just looking at the draft 16. As I understood from it, MH will be a seperate protocol runing over IPv6 like ICMPv6. But in that case, what about piggybacking, specially since piggybacking is mentioned as future work... I did not understand the association. Please correct me if I have incorrectly interprated the draft... regards, Raj -- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Email.com http://www.email.com/?sr=signup Win the Ultimate Hawaiian Experience from Travelocity. http://ad.doubleclick.net/clk;4018363;6991039;n?http://svc.travelocity.com/promos/winhawaii/ From owner-mobile-ip@sunroof.eng.sun.com Mon Mar 25 21:41: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 VAA12714 for ; Mon, 25 Mar 2002 21:41:19 -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 TAA10541; Mon, 25 Mar 2002 19:40:58 -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 SAA26005; Mon, 25 Mar 2002 18: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 g2Q2d9KL009101 for ; Mon, 25 Mar 2002 18:39:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2Q2d91H009100 for mobile-ip-dist; Mon, 25 Mar 2002 18:39: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 g2Q2d6KL009093 for ; Mon, 25 Mar 2002 18:39:06 -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 SAA28395 for ; Mon, 25 Mar 2002 18:39:06 -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 TAA22123 for ; Mon, 25 Mar 2002 19:39:06 -0700 (MST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2Q2d4Y06986; Mon, 25 Mar 2002 18:39:04 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-187.cisco.com [128.107.163.187]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACF33560; Mon, 25 Mar 2002 18:38:36 -0800 (PST) Message-ID: <3C9FDF47.1B24B60C@cisco.com> Date: Mon, 25 Mar 2002 18:39:04 -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: mchandra@cisco.com Subject: Re: [mobile-ip] Question about the I Bit in the Revocation Acknowledgement Messag e 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 Steve, Is there a reason not to inform the MN? Isn't it better to always inform the MN and let MN decide what to do with the information? Not sure if this has already been addressed, so not including WG alias. Kent "Steven M. Glass" wrote: > > " > > I Inform bit. > > > > Set to '1' by the foreign agent to ask the home agent > > if the mobile node should be informed of the > > revocation. > > " > > > > If the Foreign Agent is sending this message to acknowledge receiving a > > Revocation Message what does the above text mean? > > > Ahmad, > > There's two things that can be going on with the revocation request, and > revocation acknowledge message, and I suppose the above text may need a bit of > clarification in the scenario you're asking about (the answer to your question > is the last half of this explanation). > > In the spirit of the draft (what I was intending to convey): > > If the FA is sending the revocation message, setting the 'I' bit to 1 > means it is asking the HA to set the 'I' bit to '1' if it wants the MN to be > informed of the revocation, and to set the 'I' bit ot '0' if it does NOT want > the MN to be informed. > > If the HA sent the revocation request, and sets the 'I' bit to '1' it is > requesting the FA inform the MN. If the FA does inform the MN, in the > revocation acknowledgement the FA will set the 'I' bit to 1 (so the second > part here is the specific answer to your question), and if the FA does NOT > inform the MN, it sets the 'I' bit to 0. > > Another way to phrase that text would be: > > In the case of the FA revocing the registration, the 'I' bit is set to 1 > to request the home agent instruct the FA to whether the MN should be informed > of the revocation. > > Since this functionality is really up to the FA, it 'advertises' it MAY > leave the decision to the HA in the registration phase, that is based on the > 'I' bit's setting in the revocation extension. The key is how this corelates > to what the FA is doing in the revocation request. Here are all the possibles > (presuming both sides have implied they understand the 'I' bit int the > registration phase): > > H-1. HA revoking registration, requests the MN be informed. In this case > the HA sends a revocation message to the FA with the 'I' bit set to 1. If the > FA informs the MN of it's revocation it SHOULD set the 'I' bit to 1 in the > revocation acknowledgement (this is the specific case you asked about). If > the FA does NOT inform the MN of the revocation, it SHOULD set the 'I' bit to > 0. > > H-2. HA revoking registration, requests the MN NOT be informed. In this > case the HA sends a revocation messasge to the FA with the 'I' bit set to 0. > If the FA does NOT inform the MN, it SHOULD reply with the 'I' bit set to 0. > If the FA does inform the MN of the revocation, it SHOULD set the 'I' bit to 1 > (these responses by the FA are exactly as above). > > F-1. FA revoking registration, wants the HA to respond to whether the MN > should be informed, so it sets the 'I' bit to 1. If the HA wants the MN to be > informed of the revocation, in the revocation acknowledgement, it sets the 'I' > bit to 1, and if it does NOT want the MN informed, it sets the 'I' bit to 0. > > F-2. FA revoking registration, doesn't care what the HA wants. In this > case, where the policy in the foreign realm is not request what the HA wants, > the FA SHOULD not imply the choice will be up to the HA in the registration > phase, that is the 'I' bit should be set to 0 in the revocation extension. In > this way, if the HA recieves a revocation request with the 'I' bit set to 1, > it can infer the MN was informed of the revocation, and that's just the policy > in the foreign realm. If the policy in the foreign realm is to always NOT > inform the MN of the revocation, the FA conveys this by setting the 'I' bit to > 1 in the registration phase (the revocation extension), then setting the 'I' > bit to 0 in the revocation request (implying it has NOT informed the MN). > > I know it seems a bit complex, but (I think) all the functionality is > there, and only uses essentially 2 bits, or 1 bit in each phase. Does this > make sense? The other solution would be to go to a 'what the agents wants to > be done in the event of a revocation' at the time of registration, but the > nature of policy means that decision should be made at the time of revocation > because the decision on whether to inform the MN is likely to be effected by > why the revocation is happenning, which is why I propose this model. > Thoughts? There may be a way to make this cleaner/clearer. > > Cheers, > Steve -- | | 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 Tue Mar 26 01:13: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 BAA17645 for ; Tue, 26 Mar 2002 01:13:44 -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 WAA03718; Mon, 25 Mar 2002 22:12: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 WAA18390; Mon, 25 Mar 2002 22: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 g2Q6C8KL009542 for ; Mon, 25 Mar 2002 22:12:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2Q6C8G8009541 for mobile-ip-dist; Mon, 25 Mar 2002 22:12: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 g2Q6C5KL009534 for ; Mon, 25 Mar 2002 22:12:05 -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 WAA25947 for ; Mon, 25 Mar 2002 22:12:06 -0800 (PST) Received: from WS0005.indiatimes.com ([203.199.93.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25547 for ; Mon, 25 Mar 2002 23:11:39 -0700 (MST) Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id LAA22633 for ; Tue, 26 Mar 2002 11:30:38 +0530 From: "gaurav_puri98" Message-Id: <200203260600.LAA22633@WS0005.indiatimes.com> To: Subject: [mobile-ip] DAD with 'S'bit not set Date: Tue, 26 Mar 2002 14:05:10 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2002326214510318561886" MIME-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=_MAILER_ATTACH_BOUNDARY1_2002326214510318561886 Content-Type: text/plain; charset=us-ascii hello all, When a HA receives a BU with 'D' bitset and 'S' bit not set, then does HA have to perform DAD for each and every possible home address of MN(i.e . link local and global addresses using all the advertised prefixes) or doing it for link local will be sufficient? reagrds gaurav Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_2002326214510318561886 Content-Type: text/html; charset=us-ascii

hello all,

  When a HA receives a BU with 'D' bitset and 'S' bit not set, then does HA have to perform DAD for each and every possible home address of MN(i.e . link local and global addresses using all the advertised prefixes) or doing it for link local will be sufficient?

reagrds

gaurav 

 

Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy Music, Video, CD-ROM, Audio-Books and Music Accessories from http://www.planetm.co.in --=_MAILER_ATTACH_BOUNDARY1_2002326214510318561886-- From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 07:35: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 HAA00507 for ; Tue, 26 Mar 2002 07:35: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 EAA11447; Tue, 26 Mar 2002 04:35:04 -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 EAA14093; Tue, 26 Mar 2002 04:34: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 g2QCXwKL010131 for ; Tue, 26 Mar 2002 04:33:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QCXv1a010130 for mobile-ip-dist; Tue, 26 Mar 2002 04:33: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 g2QCXsKL010123 for ; Tue, 26 Mar 2002 04:33: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 EAA03742 for ; Tue, 26 Mar 2002 04:33:55 -0800 (PST) Received: from penguin.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 FAA24213 for ; Tue, 26 Mar 2002 05:33:53 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2QCXqkY020789 for ; Tue, 26 Mar 2002 13:33:52 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 26 13:33:19 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 13:31:21 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB6E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Singh Ajoy-ASINGH1 Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 26 Mar 2002 13:33: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: > > Right, but the old AR still needs to know when to stop sending the > packets and flush its neighbor cache. > If the F-BU comes through prior to the MN moving, what's the signal? => Actually, we've addressed this in the bicasting draft. It doesn't need to do anything except let the BU cache entry time out. There should be enough time so that all new traffic will be directed to the nAR. 2-3 seconds is all you need. > > Also, there were some other questions raised about > bicasting around the > effect on reliable transports that need resolution, we're > planning on > looking into experimentally them soon. => I haven't seen any substantial proof of that. In fact I saw a paper that proved the opposite (and neither me or Karim had anything to do with it :) ). Also the Eifel algorithm can solve any potential problems. > > How can the host connect to two ARs if there is only one > interface? Are > you assuming soft handover, i.e. that the host can also be > connected to > two ARs at layer 2? Or are you assuming that the host has a > connection > to the new AR through the old AR, like in FMIPv4? => Some link layers _can_ allow for make before break handovers. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 13:27: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 NAA17556 for ; Tue, 26 Mar 2002 13:27: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 LAA23361; Tue, 26 Mar 2002 11:27: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 KAA03616; Tue, 26 Mar 2002 10:27: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 g2QIQAKL010826 for ; Tue, 26 Mar 2002 10:26:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QIQANR010825 for mobile-ip-dist; Tue, 26 Mar 2002 10:26: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 g2QIQ6KL010818 for ; Tue, 26 Mar 2002 10:26:06 -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 KAA28694 for ; Tue, 26 Mar 2002 10:26:06 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22630 for ; Tue, 26 Mar 2002 11:26:05 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2QIQ5I04839; Tue, 26 Mar 2002 10:26:05 -0800 (PST) Message-ID: <011a01c1d4f3$77719b40$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Singh Ajoy-ASINGH1" References: <4DA6EA82906FD511BE2F00508BCF053802C6AB6E@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 26 Mar 2002 10:24:28 -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 > > Also, there were some other questions raised about > > bicasting around the > > effect on reliable transports that need resolution, we're > > planning on > > looking into experimentally them soon. > > => I haven't seen any substantial proof of that. > In fact I saw a paper that proved the opposite > (and neither me or Karim had anything to do > with it :) ). > Also the Eifel algorithm can solve any potential > problems. > Right, that's what I said. We are going to attempt to either provide some proof or refute the concern. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 14:57:52 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 OAA20892 for ; Tue, 26 Mar 2002 14:57:51 -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 MAA12011; Tue, 26 Mar 2002 12:57:26 -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 LAA01280; Tue, 26 Mar 2002 11:57: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 g2QJuOKL011499 for ; Tue, 26 Mar 2002 11:56:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QJuOmb011498 for mobile-ip-dist; Tue, 26 Mar 2002 11:56: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 g2QJuLKL011491 for ; Tue, 26 Mar 2002 11:56:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27497 for ; Tue, 26 Mar 2002 11:56:22 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04288 for ; Tue, 26 Mar 2002 11:56:10 -0800 (PST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2QJuMK22830 for ; Tue, 26 Mar 2002 11:56:22 -0800 (PST) Received: from gdommety-w2k9.cisco.com ([171.71.129.90]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AEH32843; Tue, 26 Mar 2002 11:56:14 -0800 (PST) Message-Id: <4.3.2.7.2.20020326110425.02dee148@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 26 Mar 2002 11:56:20 -0800 To: mobile-ip@sunroof.eng.sun.com, From: Gopal Dommety Subject: [mobile-ip] New Version: draft-ietf-mobileip-fast-mipv6-04.txt In-Reply-To: <011a01c1d4f3$77719b40$7e6015ac@T23KEMPF> References: <4DA6EA82906FD511BE2F00508BCF053802C6AB6E@Esealnt861.al.sw.ericsson.se> 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: I have submitted ver 04 of draft-ietf-mobileip-fast-mipv6-04.txt to the internet-drafts. You can also download it from http://www.employees.org/~gdommety/pub/draft-ietf-mobileip-fast-mipv6-04.txt Thanks Gopal From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 15:52: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 PAA23046 for ; Tue, 26 Mar 2002 15:52: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 MAA18498; Tue, 26 Mar 2002 12:52: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 MAA12877; Tue, 26 Mar 2002 12:52: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 g2QKoBKL011733 for ; Tue, 26 Mar 2002 12:50:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QKoAkB011732 for mobile-ip-dist; Tue, 26 Mar 2002 12:50: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 g2QKo7KL011725 for ; Tue, 26 Mar 2002 12:50:07 -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 MAA11447 for ; Tue, 26 Mar 2002 12:50:09 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24740 for ; Tue, 26 Mar 2002 13:50:08 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id ED1EB6A904 for ; Tue, 26 Mar 2002 22:49:56 +0200 (EET) Message-ID: <3CA0DF53.10309@piuha.net> Date: Tue, 26 Mar 2002 22:51:31 +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] Comments on Draft 16 References: <3C9FADAA.5DDFD408@compaq.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 Thanks Brian for your comments! Some answer below: >>Both the mobile node and the home agent MUST use non-volatile memory >>to store the sequence number so that a reboot does not prevent the >>acceptance of new Binding Updates. > > Why is this a MUST and not a SHOULD (or MAY) The nv memory allows for protection against replays. If there's no nv memory, we'll have to provide a resynch procedure, which could be used by attackers in a replay too. But I'm not sure either whether this should be a MUST. Perhaps a SHOULD would be sufficient? > This isn't correct, there are 4 bytes of padding necessary. BTW, the > HoTI > Message section has this right. Thanks for pointing this out. But isn't it the other way around? HoTI and CoTI are 2 bytes, MH has a fixed overhead of 6, total is 8 => ok? > 5.1.7 Binding Update (BU) Message > I don't believe any padding is necessary. This too. > ------------------------------------------------------------------------ > > 5.1.8 Binding Acknowledgement (BA) Message > > This can be problematic, and is in disagreement with Section 8.3 - "Any > Binding Cache entry MUST be deleted after the expiration of this > lifetime > in the Binding Cache entry." I would propose: > > "Mobile Nodes SHOULD send a new Binding Update before the expiration of > this > period in order to extend the lifetime and not cause a disruption in > communications". Sounds good. > And regarding the Refresh field, I'll let Charlie and others comment on this. >>The Binding Acknowledgement is sent to the source address of the >>Binding Update message, regardless of whether the Binding Update >>succeeded or failed. No Routing Headers are inserted to the message. > > This looks wrong, the BAck should be sent to the home address via the > care-of > address with a Routing Header, which accomodates use of the Alternate > COA > option. This is a change from draft 15. I understand your issue, but the change was done in an effort to make MIPv6 reflection-proof by eliminating all messages that are replied to another address than they were sent from. By the way, the use of Alt-CoA is still an open issue. But perhaps you could help me in understanding it. If Alt-CoA is used from a new CoA to refer to the old-CoA, this kind of use seems fine. However, if it is used from the old CoA to refer to some activity that should be done towards a new, yet untested CoA then there may bombing attack concerns. Which kind of use is the Alt-CoA designed for? > ------------------------------------------------------------------------ > > General comment about Section 5.1.* - it would be nice if every Message > description section included the length (or minimum length) requirement > for the Mobility Header "Header Len" field, this way it's obvious to > implementors. For example in Section 5.1.7: Good suggestion. > ------------------------------------------------------------------------ > > 5.3 Home Address Option > >>A packet MUST NOT contain more than one Home Address option, except that an >>encapsulated packet [?] MAY contain a separate Home Address option > associated with each encapsulating IP header. > > Ok, I'll go down this path again - it was found at Connectathon 2001 > (yes, 2001) > that "conformance" tests that sent a packet with two back-to-back HAOs > caused > some vendors to send an ICMPv6 Parameter Problem message, and others to > accept > it, over-writing the old HAO with the new. Now that we must lookup a > BCE to > accept the HAO, it seems prudent that we should reject this case. Hmm... is the problem in using multiple HAOs in the same packet, or multiple HAOs at different layers in a tunneled packet? What if an MN and a CN would be running an IP-in-IP tunnel for some reason, and then someone sends a packet with a HAO to this tunnel? Shouldn't it work? > 10.3 Receiving Packets While Away from Home > > This section mentions "Routing header", but should be specific that it's > a type 2 Routing header that's to be used for CN->MN RO communications. Right. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 16:37: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 QAA25838 for ; Tue, 26 Mar 2002 16:37: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 OAA20389; Tue, 26 Mar 2002 14:37: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 NAA28848; Tue, 26 Mar 2002 13:36: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 g2QLa7KL011944 for ; Tue, 26 Mar 2002 13:36:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QLa63Q011943 for mobile-ip-dist; Tue, 26 Mar 2002 13: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 g2QLa2KL011936 for ; Tue, 26 Mar 2002 13:36:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22587 for ; Tue, 26 Mar 2002 13:36:04 -0800 (PST) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02889 for ; Tue, 26 Mar 2002 13:36:05 -0800 (PST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 742333C6C; Tue, 26 Mar 2002 15:36:03 -0600 (CST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 7DDAE10BA; Tue, 26 Mar 2002 13:36:02 -0800 (PST) Received: from compaq.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id QAA0001988028; Tue, 26 Mar 2002 16:36:01 -0500 (EST) Message-ID: <3CA0E9C1.1D45178@compaq.com> Date: Tue, 26 Mar 2002 16:36:01 -0500 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko Subject: Re: [mobile-ip] Comments on Draft 16 References: <3C9FADAA.5DDFD408@compaq.com> <3CA0DF53.10309@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 Jari, Jari Arkko wrote: > >>Both the mobile node and the home agent MUST use non-volatile memory > >>to store the sequence number so that a reboot does not prevent the > >>acceptance of new Binding Updates. > > > > Why is this a MUST and not a SHOULD (or MAY) > > The nv memory allows for protection against replays. If there's > no nv memory, we'll have to provide a resynch procedure, which could > be used by attackers in a replay too. > > But I'm not sure either whether this should be a MUST. Perhaps a SHOULD > would be sufficient? Ok, I understand the reason now, it's because we could be using manually-configured IPsec keys. But later on in that section it says you don't have to update the nv memory every time you get a BU, which itself could lead to a replay attack if the HA crashes. I'm fine with a SHOULD. > > This isn't correct, there are 4 bytes of padding necessary. BTW, the > > HoTI > > Message section has this right. > > Thanks for pointing this out. But isn't it the other way around? HoTI > and CoTI are 2 bytes, MH has a fixed overhead of 6, total is 8 => ok? Yes, you're right. I knew I was going to screw-up one of these... > >>The Binding Acknowledgement is sent to the source address of the > >>Binding Update message, regardless of whether the Binding Update > >>succeeded or failed. No Routing Headers are inserted to the message. > > > > This looks wrong, the BAck should be sent to the home address via the > > care-of > > address with a Routing Header, which accomodates use of the Alternate > > COA > > option. This is a change from draft 15. > > I understand your issue, but the change was done in an effort to make > MIPv6 reflection-proof by eliminating all messages that are replied to > another address than they were sent from. > > By the way, the use of Alt-CoA is still an open issue. But perhaps you > could help me in understanding it. If Alt-CoA is used from a new CoA > to refer to the old-CoA, this kind of use seems fine. However, if it > is used from the old CoA to refer to some activity that should be done > towards a new, yet untested CoA then there may bombing attack concerns. > Which kind of use is the Alt-CoA designed for? I believe it was the latter, where you are moving to a new location, but I'm not exactly sure of Charlie's intention. > > 5.3 Home Address Option > > > >>A packet MUST NOT contain more than one Home Address option, except that an > >>encapsulated packet [?] MAY contain a separate Home Address option > > associated with each encapsulating IP header. > > > > Ok, I'll go down this path again - it was found at Connectathon 2001 > > (yes, 2001) > > that "conformance" tests that sent a packet with two back-to-back HAOs > > caused > > some vendors to send an ICMPv6 Parameter Problem message, and others to > > accept > > it, over-writing the old HAO with the new. Now that we must lookup a > > BCE to > > accept the HAO, it seems prudent that we should reject this case. > > Hmm... is the problem in using multiple HAOs in the same packet, or > multiple HAOs at different layers in a tunneled packet? What if an > MN and a CN would be running an IP-in-IP tunnel for some reason, and > then someone sends a packet with a HAO to this tunnel? Shouldn't it > work? Using multiple HAOs without an intervening tunnel is the problem, i.e. both in the same Destination Option. Thanks, -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 17:25: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 RAA27864 for ; Tue, 26 Mar 2002 17:25:54 -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 PAA19934; Tue, 26 Mar 2002 15:25: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 OAA06900; Tue, 26 Mar 2002 14:25: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 g2QMOWKL012124 for ; Tue, 26 Mar 2002 14:24:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QMOWCL012123 for mobile-ip-dist; Tue, 26 Mar 2002 14:24: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 g2QMOTKL012116 for ; Tue, 26 Mar 2002 14:24: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 OAA09481 for ; Tue, 26 Mar 2002 14:24:30 -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 PAA19202 for ; Tue, 26 Mar 2002 15:24:29 -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 OAA12845 for ; Tue, 26 Mar 2002 14:24:28 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2QMOR813374 for ; Tue, 26 Mar 2002 14:24:27 -0800 X-mProtect:  Tue, 26 Mar 2002 14:24:27 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdn0rd5o; Tue, 26 Mar 2002 14:24:25 PST Message-ID: <3CA0F519.1C2CADBF@iprg.nokia.com> Date: Tue, 26 Mar 2002 14:24:25 -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] Comments on Draft 16 References: <3C9FADAA.5DDFD408@compaq.com> <3CA0DF53.10309@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 Jari Arkko wrote: > > Thanks Brian for your comments! Some answer below: > > >>Both the mobile node and the home agent MUST use non-volatile memory > >>to store the sequence number so that a reboot does not prevent the > >>acceptance of new Binding Updates. > > > > Why is this a MUST and not a SHOULD (or MAY) > > The nv memory allows for protection against replays. If there's > no nv memory, we'll have to provide a resynch procedure, which could > be used by attackers in a replay too. > > But I'm not sure either whether this should be a MUST. Perhaps a SHOULD > would be sufficient? > There was something in draft 15 to handle the case when the MN reboots. If the MN sends a BU with a sequence number smaller than the one it had sent before the reboot, the HA rejects the BU and sends a BAck with error status 141 (sequence number too small). In addition to this, the HA includes the sequence number from its binding cache in the BAck. For the next BU, the MN chooses a sequence number greater than the sequence number in the returned BAck. When the HA reboots and comes up, it accepts whatever sequence number the MN sends. We have tested this. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Mar 26 21:10: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 VAA03342 for ; Tue, 26 Mar 2002 21:10:15 -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 TAA25379; Tue, 26 Mar 2002 19:09:29 -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 SAA08562; Tue, 26 Mar 2002 18:09: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 g2R28CKL012498 for ; Tue, 26 Mar 2002 18:08:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2R28CAh012497 for mobile-ip-dist; Tue, 26 Mar 2002 18:08: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 g2R288KL012490 for ; Tue, 26 Mar 2002 18:08:09 -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 SAA08423 for ; Tue, 26 Mar 2002 18:08:09 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04404 for ; Tue, 26 Mar 2002 19:08:09 -0700 (MST) Received: from docomocarl (dhcp104.docomolabs-usa.com [172.21.96.104]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2R289I20842; Tue, 26 Mar 2002 18:08:09 -0800 (PST) Message-ID: <001701c1d534$ae22b390$686015ac@docomocarl> From: "Carl Williams" To: Cc: "Kaori Murakami" Subject: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Date: Tue, 26 Mar 2002 18:11:17 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C1D4F1.9FEEAAB0" 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_0014_01C1D4F1.9FEEAAB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Below is a pointer to a 3GPP2/TSG-P document=20 recording the IPv6 Mobility Discussion at the=20 recent TSG-P meeting in Kobe, Japan on March 11. Pete McCann, Tom Hillar and Paul Francis put together this 3GPP2 TSGP document. Pointer is: ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ The file name is: P00-20020311-006 luc IPv6 mobility.doc Discussion regarding MIPv6, requirements, WLAN, DIAMETER, and other topics (PANA working group, EAP, etc) were discussed at the meeting. I am sending the pointer to the doc as a fyi.... Carl ------=_NextPart_000_0014_01C1D4F1.9FEEAAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Below is a pointer to a 3GPP2/TSG-P = document=20
recording the IPv6 Mobility Discussion = at the=20
recent TSG-P meeting in Kobe, Japan on = March=20 11.
 
Pete McCann, Tom Hillar and Paul = Francis=20 put
together this 3GPP2 TSGP = document.
 
 
Pointer is:

ftp://ftp.3= gpp2.org/TSGP/Working/2002/20020311-Kobe/
The=20 file name is:
P00-20020311-006 luc IPv6 = mobility.doc

Discussion=20 regarding MIPv6, requirements, WLAN, DIAMETER,
and other topics=20 (PANA working group, EAP, etc) were
discussed at the meeting.
 
I am sending the pointer to the doc as = a=20 fyi....
 
Carl
 
------=_NextPart_000_0014_01C1D4F1.9FEEAAB0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 09:17: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 JAA28994 for ; Wed, 27 Mar 2002 09:17: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 GAA10589; Wed, 27 Mar 2002 06:17: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 GAA07865; Wed, 27 Mar 2002 06:16: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 g2REEmKL013404 for ; Wed, 27 Mar 2002 06:14:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2REEm56013403 for mobile-ip-dist; Wed, 27 Mar 2002 06: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2REEYKL013386 for ; Wed, 27 Mar 2002 06:14:35 -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 GAA10399 for ; Wed, 27 Mar 2002 06:14:37 -0800 (PST) Received: from penguin.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 HAA12363 for ; Wed, 27 Mar 2002 07:14:36 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2REEZkY000995 for ; Wed, 27 Mar 2002 15:14:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 14:46:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C0741C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 14:46: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: Alper, > Also AP will have to tell this information to the Access Router. > This is where a "protocol" for L2 triggers is needed. > => In this case the handover can be MN initiated. A 'protocol' thaty transfers L2 triggers is really going down the path of the L7 L2! Let's not go there Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 09:17: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 JAA29045 for ; Wed, 27 Mar 2002 09:17:58 -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 HAA11395; Wed, 27 Mar 2002 07:17:03 -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 GAA07857; Wed, 27 Mar 2002 06:16: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 g2REEdKL013401 for ; Wed, 27 Mar 2002 06:14:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2REEcWi013400 for mobile-ip-dist; Wed, 27 Mar 2002 06: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2REEZKL013389 for ; Wed, 27 Mar 2002 06:14: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 GAA09079 for ; Wed, 27 Mar 2002 06:14:38 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12329 for ; Wed, 27 Mar 2002 07:14:37 -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 g2REEaoq015085 for ; Wed, 27 Mar 2002 15:14:36 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 14:46:21 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 14:36:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C0741D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 14:46: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: > > => Ideally, yes. But I just didn't think > > that any SDO can mandate an API that is internal > > to a device. If they do then it would be great! > > Unless they want to go down the track of making > > WLANs connection-oriented, which is a major change > > in the WLAN design philosophy. > > > > I don't think this has anything to do with mandating a > particular API. I > should probably look more closely at the standard, but from > talking to > people who know it better, I don't believe the 802.11 > standard has the > kind of strict power levels for handoff that other radio > protocols have, > such that if the power dips below a certain level, then handoff to > another access point with the highest power level is > certain. I believe > it is left up to the implementors to determine this. > Anybody who knows > the 802.11 standard better than I, please correct me if I > am wrong. I > don't believe this has anything to do with whether the WLAN is > connection oriented or not, it just involves how they define a > standard-conformant implementation w.r.t. handover. > > If that's so, then the actual implementation will vary > widely and make > it difficult to implement a consistent L2 trigger. Standardizing > something along these lines would help proactive mobile controlled > handoff. => This *is* why you need the API. L2 can simply send a trigger saying a handover is about to take place. No need to transfer power levels. The trigger will be sent based on the implementors' assumptions of when the handover should take place. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:14: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 NAA13091 for ; Wed, 27 Mar 2002 13:14: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 LAA25567; Wed, 27 Mar 2002 11:13: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 KAA25129; Wed, 27 Mar 2002 10: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 g2RICkKL013871 for ; Wed, 27 Mar 2002 10:12:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RICkhY013870 for mobile-ip-dist; Wed, 27 Mar 2002 10:12: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 g2RIChKL013863 for ; Wed, 27 Mar 2002 10:12: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 KAA14597 for ; Wed, 27 Mar 2002 10:12:46 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25040 for ; Wed, 27 Mar 2002 11:12:45 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA11047 for ; Wed, 27 Mar 2002 11:12:45 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA23940 for ; Wed, 27 Mar 2002 11:12:44 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 27 Mar 2002 12:12:45 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 12:12:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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: Hesham, I think even in case of Mobile initiated trigger, providing L2 trigger information (Link UP and Link Down) at AR will definitely make the handover better. Probably this is what Alper is referring to. I think this should be doable by extending the existing IAPP protocol or defining a new protocol. Am I missing anything ? regards, ajoy -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 7:46 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Alper, > Also AP will have to tell this information to the Access Router. > This is where a "protocol" for L2 triggers is needed. > => In this case the handover can be MN initiated. A 'protocol' thaty transfers L2 triggers is really going down the path of the L7 L2! Let's not go there Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:18:16 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 NAA13471 for ; Wed, 27 Mar 2002 13:18:16 -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 KAA06609; Wed, 27 Mar 2002 10:17: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 KAA27187; Wed, 27 Mar 2002 10:17: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 g2RIGwKL013957 for ; Wed, 27 Mar 2002 10:16:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIGwVM013956 for mobile-ip-dist; Wed, 27 Mar 2002 10:16: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 g2RIGsKL013949 for ; Wed, 27 Mar 2002 10:16:55 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16362 for ; Wed, 27 Mar 2002 10:16:58 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12246 for ; Wed, 27 Mar 2002 10:16:58 -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.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIGukY016054 for ; Wed, 27 Mar 2002 19:16:56 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:16:48 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:16:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 19:16:39 +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 think even in case of Mobile initiated trigger, > providing L2 trigger information (Link UP and Link Down) > at AR will definitely make the handover better. Probably > this is what Alper is referring to. I think this should > be doable by extending the existing IAPP protocol or defining > a new protocol. Am I missing anything ? => But I didn't think 802.11 allowed the AP to know whether a MN has 'left' its coverage area. So I always assume that link up or down is only relevant to the MN itself. I see no reason to send this info to the AR. I get the feeling we're talking about different things :) are we? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:35: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 NAA14880 for ; Wed, 27 Mar 2002 13:35: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 LAA03339; Wed, 27 Mar 2002 11:35: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 KAA06451; Wed, 27 Mar 2002 10: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 g2RIYJKL014143 for ; Wed, 27 Mar 2002 10:34:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIYJb9014142 for mobile-ip-dist; Wed, 27 Mar 2002 10:34: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 g2RIYFKL014135 for ; Wed, 27 Mar 2002 10:34:16 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05928 for ; Wed, 27 Mar 2002 10:34:17 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23719 for ; Wed, 27 Mar 2002 10:34:03 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id LAA02864 for ; Wed, 27 Mar 2002 11:23:00 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA09606 for ; Wed, 27 Mar 2002 11:34:16 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 27 Mar 2002 12:34:16 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 12:33:56 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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: But I didn't think 802.11 allowed the AP to know whether a MN has 'left' its coverage area. So I always assume that link up or down is only relevant to the MN itself. I see no reason to send this info to the AR. I get the feeling we're talking about different things :) are we? -> If I remember correctly, new AP does send IAPP(?) message to old AP after MN is re-associated with new AP. Can't we extend IAPP to inform AR about the Mobile node's re-association with new AP ? Can some one comment about this ? regards, ajoy -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 27, 2002 12:17 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > I think even in case of Mobile initiated trigger, > providing L2 trigger information (Link UP and Link Down) > at AR will definitely make the handover better. Probably > this is what Alper is referring to. I think this should > be doable by extending the existing IAPP protocol or defining > a new protocol. Am I missing anything ? => But I didn't think 802.11 allowed the AP to know whether a MN has 'left' its coverage area. So I always assume that link up or down is only relevant to the MN itself. I see no reason to send this info to the AR. I get the feeling we're talking about different things :) are we? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:35: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 NAA14898 for ; Wed, 27 Mar 2002 13:35:58 -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 LAA03542; Wed, 27 Mar 2002 11:35: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 KAA06698; Wed, 27 Mar 2002 10:35: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 g2RIYuKL014160 for ; Wed, 27 Mar 2002 10:34:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIYuSd014159 for mobile-ip-dist; Wed, 27 Mar 2002 10:34: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 g2RIYqKL014152 for ; Wed, 27 Mar 2002 10:34:52 -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 KAA23873 for ; Wed, 27 Mar 2002 10:34:53 -0800 (PST) Received: from penguin.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 LAA07511 for ; Wed, 27 Mar 2002 11:34:53 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIYpkY018690 for ; Wed, 27 Mar 2002 19:34:52 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:34:51 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:34:51 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Comments on Draft 16 Date: Wed, 27 Mar 2002 19:34:49 +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: Jari, > By the way, the use of Alt-CoA is still an open issue. But > perhaps you > could help me in understanding it. If Alt-CoA is used from a new CoA > to refer to the old-CoA, this kind of use seems fine. However, if it > is used from the old CoA to refer to some activity that > should be done > towards a new, yet untested CoA then there may bombing > attack concerns. > Which kind of use is the Alt-CoA designed for? => Does it matter? I mean if the COTI is always done on the intended CoA then wouldn't it always work? So if a BU is sent with an Alt-CoA then the COTI is done on the Alt-CoA. As for the use, well a multihomed MN may choose (for whatever reason) to send a BU from one interface to forward traffic to another interface. I can't think of a good case right now (apart from HMIPv6 :) ). Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:39: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 NAA15125 for ; Wed, 27 Mar 2002 13:39: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 KAA11728; Wed, 27 Mar 2002 10:39:24 -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 KAA08369; Wed, 27 Mar 2002 10: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 g2RIcdKL014309 for ; Wed, 27 Mar 2002 10:38:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIcd0m014308 for mobile-ip-dist; Wed, 27 Mar 2002 10:38: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 g2RIcZKL014301 for ; Wed, 27 Mar 2002 10:38:35 -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 KAA14120 for ; Wed, 27 Mar 2002 10:38:36 -0800 (PST) Received: from penguin.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 LAA09853 for ; Wed, 27 Mar 2002 11:38:35 -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.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIcYkY019124 for ; Wed, 27 Mar 2002 19:38:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 27 19:38:34 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:38:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Jari Arkko Subject: RE: [mobile-ip] Comments on Draft 16 Date: Wed, 27 Mar 2002 19:38:32 +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: BTW, I haven't been keeping up with email so sorry if this was already discussed. Glenn Morrow brought up the issue (ipv6 list) of reverse tunnelling to the HA when the HoA is a Site-local address. He suggested that tunnel must be authenticated. I don't remember if this was in the draft already, but I think it has to be added. The draft (15) said that the HA SHOULD tunnel Site-local (unicast and mcast) packets to the CoA, so we can expect reverse tunnelling to take place if the MN was communicating to another node within the home site. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13: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 NAA15467 for ; Wed, 27 Mar 2002 13:44:54 -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 KAA12872; Wed, 27 Mar 2002 10:44:36 -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 KAA10898; Wed, 27 Mar 2002 10:44: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 g2RIhrKL014436 for ; Wed, 27 Mar 2002 10:43:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIhrHf014435 for mobile-ip-dist; Wed, 27 Mar 2002 10:43: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RIhoKL014428 for ; Wed, 27 Mar 2002 10:43:50 -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 KAA08979 for ; Wed, 27 Mar 2002 10:43:51 -0800 (PST) Received: from penguin.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 LAA12777 for ; Wed, 27 Mar 2002 11:43:50 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2RIhnkY022966 for ; Wed, 27 Mar 2002 19:43:49 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 27 19:43:48 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 19:33:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABA8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 19:43:46 +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: > -> If I remember correctly, new AP does send IAPP(?) message > to old AP after MN is re-associated with new AP. Can't > we extend IAPP to inform AR about the Mobile node's > re-association with new AP ? Can some one comment > about this ? => But this works within the same subnet. We're dealing with inter-subnet handovers. Of course one could argue that it can be used across subnets, but I'm not sure I agree with that. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:49: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 NAA15770 for ; Wed, 27 Mar 2002 13:49: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 KAA13885; Wed, 27 Mar 2002 10:49:02 -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 KAA12949; Wed, 27 Mar 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 g2RIm8KL014526 for ; Wed, 27 Mar 2002 10:48:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIm8SY014525 for mobile-ip-dist; Wed, 27 Mar 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 g2RIm5KL014518 for ; Wed, 27 Mar 2002 10:48:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10721 for ; Wed, 27 Mar 2002 10:48:06 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28413 for ; Wed, 27 Mar 2002 10:47:52 -0800 (PST) Received: from mkulkarn-u10.cisco.com (mkulkarn-u10.cisco.com [128.107.162.246]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2RIlXY08412; Wed, 27 Mar 2002 10:47:33 -0800 (PST) Received: from cisco.com (localhost [127.0.0.1]) by mkulkarn-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA26188; Wed, 27 Mar 2002 10:47:27 -0800 (PST) Message-ID: <3CA213BF.EC4AA3ED@cisco.com> Date: Wed, 27 Mar 2002 10:47:27 -0800 From: Milind Kulkarni 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, Henrik Levkowetz Subject: Re: [mobile-ip] NAT traversal question from Minneapolis 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 Henrik, It was me. I had a doubt in backward compatibility for the draft. The scenario I am considering is similar to first item in section 4.6.1. Consider HA doesn't support NAT draft and skips the UDP Tunnel Request Extension with U bit set. HA will accept the registration assuming authentication etc. is good. So there is ambiguity in following places which I think should be addressed in the draft. (1) Per Sec 3.1.1: Since HA accepted the RRQ, MN is expecting UDP Reply extension, but the HA never sent one. MN's behavior should be made clear in this case. HA will not send failed RRQ with code 129. (2) If MN is not behind a NAT, HA will set proper tunnel and Mobile IP will work. Hence MN should work in this case also. (3) Sec. 3.2 - Description of F flag: Will this flag be set only when U bit was set and NAT was not detected? How about NAT was detected and U bit was set? This flag will not be set in this case? In other words, is this flag set in response to U bit in RRQ, irrespective of NAT detection? Thanks, Milind Henrik Levkowetz wrote: > > Hi, > > There was one question posed on backward compatibility for the > NAT traversal during the Mobile IP sesssion in Minneapolis. I'd like > to explore the details of that, but I didn't catch the name of the > questioner. Would you be kind enough to send me a mail on or off list? > > Best regards, > Henrik From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 13:58: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 NAA16291 for ; Wed, 27 Mar 2002 13:58:35 -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 LAA15684; Wed, 27 Mar 2002 11:58: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 KAA16846; Wed, 27 Mar 2002 10:58: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 g2RIvSKL014644 for ; Wed, 27 Mar 2002 10:57:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RIvS3v014643 for mobile-ip-dist; Wed, 27 Mar 2002 10: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 g2RIvOKL014635 for ; Wed, 27 Mar 2002 10:57:24 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16491 for ; Wed, 27 Mar 2002 10:57:26 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01646 for ; Wed, 27 Mar 2002 10:57:12 -0800 (PST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 27 Mar 2002 10:57:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5C1.39C883A0" Subject: RE: [mobile-ip] Comments on Draft 16 Date: Wed, 27 Mar 2002 10:57:21 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF194@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Comments on Draft 16 Thread-Index: AcHVFVInYBwEelVQSY2SLSkZC4y4FgAqbomA From: "Mohan Parthasarathy" To: X-OriginalArrivalTime: 27 Mar 2002 18:57:22.0309 (UTC) FILETIME=[3A173B50:01C1D5C1] Sender: owner-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_01C1D5C1.39C883A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 > Sent: Tuesday, March 26, 2002 2:24 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Comments on Draft 16 >=20 >=20 > Jari Arkko wrote: > >=20 > > Thanks Brian for your comments! Some answer below: > >=20 > > >>Both the mobile node and the home agent MUST use=20 > non-volatile memory=20 > > >>to store the sequence number so that a reboot does not=20 > prevent the=20 > > >>acceptance of new Binding Updates. > > > > > > Why is this a MUST and not a SHOULD (or MAY) > >=20 > > The nv memory allows for protection against replays. If=20 > there's no nv=20 > > memory, we'll have to provide a resynch procedure, which=20 > could be used=20 > > by attackers in a replay too. > >=20 > > But I'm not sure either whether this should be a MUST. Perhaps a=20 > > SHOULD would be sufficient? > >=20 >=20 > There was something in draft 15 to handle the case when the=20 > MN reboots. If the MN sends a BU with a sequence number=20 > smaller than the one it had sent before the reboot, the HA=20 > rejects the BU and sends a BAck with error status 141=20 > (sequence number too=20 > small). In addition to this, the HA includes the sequence number=20 > from its binding cache in the BAck. For the next BU, the MN=20 > chooses a sequence number greater than the sequence number in=20 > the returned BAck. >=20 > When the HA reboots and comes up, it accepts whatever=20 > sequence number the MN sends. >=20 Or if the binding cache entry is removed/expired, a replayed binding update will be accepted (assuming nonces are still valid). I am not sure how bad is this. But requiring the implementors to store it in NV might be a overkill because you have to store one per MN plus the home address and how do you know when to ever remove them from NV ? -mohan > We have tested this. >=20 > Vijay >=20 ------_=_NextPart_001_01C1D5C1.39C883A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Comments on Draft 16

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] =
> Sent: Tuesday, March 26, 2002 2:24 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Comments on Draft = 16
>
>
> Jari Arkko wrote:
> >
> > Thanks Brian for your comments! Some answer = below:
> >
> > >>Both the mobile node and the home = agent MUST use
> non-volatile memory
> > >>to store the sequence number so = that a reboot does not
> prevent the
> > >>acceptance of new Binding = Updates.
> > >
> > > Why is this a MUST and not a SHOULD = (or MAY)
> >
> > The nv memory allows for protection against = replays. If
> there's no nv
> > memory, we'll have to provide a resynch = procedure, which
> could be used
> > by attackers in a replay too.
> >
> > But I'm not sure either whether this should = be a MUST. Perhaps a
> > SHOULD would be sufficient?
> >
>
> There was something in draft 15 to handle the = case when the
> MN reboots. If the MN sends a BU with a sequence = number
> smaller than the one it had sent before the = reboot, the HA
> rejects the BU and sends a BAck with error = status 141
> (sequence number too
> small). In addition to this, the HA includes the = sequence number
> from its binding cache in the BAck. For the next = BU, the MN
> chooses a sequence number greater than the = sequence number in
> the returned BAck.
>
> When the HA reboots and comes up, it accepts = whatever
> sequence number the MN sends.
>
Or if the binding cache entry is removed/expired, a = replayed binding update
will be accepted (assuming nonces are still valid). I = am not sure
how bad is this. But requiring the implementors to = store it in NV might
be a overkill because you have to store one per MN = plus the home
address and how do you know when to ever remove them = from NV ?

-mohan

> We have tested this.
>
> Vijay
>

------_=_NextPart_001_01C1D5C1.39C883A0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 15:04: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 PAA19567 for ; Wed, 27 Mar 2002 15:04:21 -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 NAA25086; Wed, 27 Mar 2002 13:03: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 MAA15312; Wed, 27 Mar 2002 12:03: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 g2RK2xKL014845 for ; Wed, 27 Mar 2002 12:02:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RK2xUa014844 for mobile-ip-dist; Wed, 27 Mar 2002 12:02: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 g2RK2uKL014837 for ; Wed, 27 Mar 2002 12:02:56 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10240 for ; Wed, 27 Mar 2002 12:02:58 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21379 for ; Wed, 27 Mar 2002 12:02:43 -0800 (PST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1758A6A905; Wed, 27 Mar 2002 22:02:49 +0200 (EET) Message-ID: <3CA225C8.5080001@piuha.net> Date: Wed, 27 Mar 2002 22:04:24 +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: "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6ABA6@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: > => Does it matter? I mean if the COTI is always > done on the intended CoA then wouldn't it always > work? So if a BU is sent with an Alt-CoA then > the COTI is done on the Alt-CoA. Ah, if this is done then it does indeed work. (But see also below.) > As for the use, well a multihomed MN may choose > (for whatever reason) to send a BU from one interface > to forward traffic to another interface. > I can't think of a good case right now (apart from > HMIPv6 :) ). So, in the multihomed case you'd still have to send the COT/COTI from the real interface, even if the BU could be sent from elsewhere. Ok for everybody? Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 15:14: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 PAA19917 for ; Wed, 27 Mar 2002 15:14:27 -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 NAA24017; Wed, 27 Mar 2002 13:14: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 MAA19354; Wed, 27 Mar 2002 12:14: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 g2RKDGKL014990 for ; Wed, 27 Mar 2002 12:13:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RKDG8u014989 for mobile-ip-dist; Wed, 27 Mar 2002 12:13: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 g2RKDCKL014982 for ; Wed, 27 Mar 2002 12:13:12 -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 MAA18999 for ; Wed, 27 Mar 2002 12:13:15 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23546 for ; Wed, 27 Mar 2002 13:13:14 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2RKDEI13263 for ; Wed, 27 Mar 2002 12:13:14 -0800 (PST) Message-ID: <02d401c1d5cb$99a836a0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 12:11: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 Ajoy, You are right, it doesn't What we would like to do is modify the 802.11 standard, perhaps via IAPP, so that this information is made available to the AR. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: Sent: Wednesday, March 27, 2002 10:33 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > But I didn't think 802.11 allowed the AP to > know whether a MN has 'left' its coverage area. > So I always assume that link up or down > is only relevant to the MN itself. > I see no reason to send this info to the AR. > I get the feeling we're talking about different > things :) are we? > > -> If I remember correctly, new AP does send IAPP(?) message > to old AP after MN is re-associated with new AP. Can't > we extend IAPP to inform AR about the Mobile node's > re-association with new AP ? Can some one comment > about this ? > > regards, > ajoy > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 12:17 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > I think even in case of Mobile initiated trigger, > > providing L2 trigger information (Link UP and Link Down) > > at AR will definitely make the handover better. Probably > > this is what Alper is referring to. I think this should > > be doable by extending the existing IAPP protocol or defining > > a new protocol. Am I missing anything ? > > => But I didn't think 802.11 allowed the AP to > know whether a MN has 'left' its coverage area. > So I always assume that link up or down > is only relevant to the MN itself. > I see no reason to send this info to the AR. > I get the feeling we're talking about different > things :) are we? > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 15:21: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 PAA20653 for ; Wed, 27 Mar 2002 15:21:10 -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 NAA03006; Wed, 27 Mar 2002 13:20:53 -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 MAA22017; Wed, 27 Mar 2002 12:20: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 g2RKK0KL015088 for ; Wed, 27 Mar 2002 12:20:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RKK01E015087 for mobile-ip-dist; Wed, 27 Mar 2002 12:20: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 g2RKJvKL015080 for ; Wed, 27 Mar 2002 12:19:57 -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 MAA15440 for ; Wed, 27 Mar 2002 12:19:59 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27034 for ; Wed, 27 Mar 2002 13:19:59 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA15673 for ; Wed, 27 Mar 2002 13:19:59 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA26951 for ; Wed, 27 Mar 2002 13:19:58 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 27 Mar 2002 14:19:58 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 14:19:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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 like the idea of extending IAPP to provide L2 trigger to oAR and nAR. regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, March 27, 2002 2:12 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Ajoy, You are right, it doesn't What we would like to do is modify the 802.11 standard, perhaps via IAPP, so that this information is made available to the AR. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: Sent: Wednesday, March 27, 2002 10:33 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > But I didn't think 802.11 allowed the AP to > know whether a MN has 'left' its coverage area. > So I always assume that link up or down > is only relevant to the MN itself. > I see no reason to send this info to the AR. > I get the feeling we're talking about different > things :) are we? > > -> If I remember correctly, new AP does send IAPP(?) message > to old AP after MN is re-associated with new AP. Can't > we extend IAPP to inform AR about the Mobile node's > re-association with new AP ? Can some one comment > about this ? > > regards, > ajoy > > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 27, 2002 12:17 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > I think even in case of Mobile initiated trigger, > > providing L2 trigger information (Link UP and Link Down) > > at AR will definitely make the handover better. Probably > > this is what Alper is referring to. I think this should > > be doable by extending the existing IAPP protocol or defining > > a new protocol. Am I missing anything ? > > => But I didn't think 802.11 allowed the AP to > know whether a MN has 'left' its coverage area. > So I always assume that link up or down > is only relevant to the MN itself. > I see no reason to send this info to the AR. > I get the feeling we're talking about different > things :) are we? > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 18:04: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 SAA28830 for ; Wed, 27 Mar 2002 18:04:51 -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 QAA13956; Wed, 27 Mar 2002 16:04: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 PAA19085; Wed, 27 Mar 2002 15:04: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 g2RN3WKL015476 for ; Wed, 27 Mar 2002 15:03:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RN3WP3015475 for mobile-ip-dist; Wed, 27 Mar 2002 15:03: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 g2RN3SKL015468 for ; Wed, 27 Mar 2002 15:03:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00209 for ; Wed, 27 Mar 2002 15:03:30 -0800 (PST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12587 for ; Wed, 27 Mar 2002 15:03:16 -0800 (PST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2RN3TW21106 for ; Wed, 27 Mar 2002 18:03:29 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA27280; Wed, 27 Mar 2002 17:03:27 -0600 (CST) Message-ID: <3CA24F79.89A1FB75@lucent.com> Date: Wed, 27 Mar 2002 17:02:17 -0600 From: Tom Hiller Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 References: <001701c1d534$ae22b390$686015ac@docomocarl> 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 To all - This is a contribution from Lucent and Tahoe in 3GPP2, and does not represent consensus in 3GPP2. There may be a need in cdma2000 carriers to integrate MIPv6 with network access control mechanisms. In the contribution we are analyzing different solutions to meet these requirements. 3GPP2 has not yet come to any conclusions about which particular set of IETF drafts are needed, or which solutions 3GPP2 will pursue. Thanks, Tom > Below is a pointer to a 3GPP2/TSG-P document > recording the IPv6 Mobility Discussion at the > recent TSG-P meeting in Kobe, Japan on March 11. > > Pete McCann, Tom Hillar and Paul Francis put > together this 3GPP2 TSGP document. > > > Pointer is: > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > The file name is: > P00-20020311-006 luc IPv6 mobility.doc > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > and other topics (PANA working group, EAP, etc) were > discussed at the meeting. > > I am sending the pointer to the doc as a fyi.... > > Carl > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 19:35: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 TAA00727 for ; Wed, 27 Mar 2002 19:35:54 -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 RAA19311; Wed, 27 Mar 2002 17:35: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 QAA27338; Wed, 27 Mar 2002 16: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 g2S0XqKL015725 for ; Wed, 27 Mar 2002 16:33:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S0XqsI015724 for mobile-ip-dist; Wed, 27 Mar 2002 16:33: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 g2S0XnKL015717 for ; Wed, 27 Mar 2002 16:33: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 QAA22641 for ; Wed, 27 Mar 2002 16:33:51 -0800 (PST) From: Ernie.Tacsik@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 RAA18536 for ; Wed, 27 Mar 2002 17:33:51 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2S0aE108481 for ; Wed, 27 Mar 2002 18:36:15 -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, 27 Mar 2002 18:33:47 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Mar 2002 18:33:02 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Mar 2002 18:33:02 -0600 Message-ID: <8F698F0DD0B49A48BDA9F451A7A68CAE09C4A9@daebe001.NOE.Nokia.com> Thread-Topic: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Thread-Index: AcHV480vw+eimDcbQJqt4880SgJjFgAApDbw To: X-OriginalArrivalTime: 28 Mar 2002 00:33:02.0239 (UTC) FILETIME=[1E6CAAF0:01C1D5F0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2S0XnKL015718 Sender: owner-mobile-ip@sunroof.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 THIS "UNAPPROVED" CONTRIBUTION CERTAINLY DOES NOT REPRESENT ANY CONSENSUS IN 3GPP2! In fact the very first sentence: "There are two solutions, MIPv6 and IPv6 over MIPv4, under consideration for IPv6 mobility" - is FALSE, and does not represent the consensus of the working group. Although 3GPP2 does have requirements to support mobility for IPv6, there has been no decision made on an approach, or even which of the possible approaches (beyond MIPv6) to pursue. 3GPP2 (Third Generation Partnership Project 2) is a collaborative third generation (3G) telecommunications standards-setting project that is driven by the contributions of its corporate members. Statements/thoughts/ideas expressed in "UNACCEPTED" contributions have no basis. I believe that propagating this contribution (submitted into 3GPP2) into the IETF attempts to derail the acceptance of the IETF Mobile IP Working Group's MIPv6 in favor of an alternative work around (possibly IPR encumbered). ernie -----Original Message----- From: ext Tom Hiller [mailto:tomhiller@lucent.com] Sent: Wednesday, 27 March, 2002 5:02 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 To all - This is a contribution from Lucent and Tahoe in 3GPP2, and does not represent consensus in 3GPP2. There may be a need in cdma2000 carriers to integrate MIPv6 with network access control mechanisms. In the contribution we are analyzing different solutions to meet these requirements. 3GPP2 has not yet come to any conclusions about which particular set of IETF drafts are needed, or which solutions 3GPP2 will pursue. Thanks, Tom > Below is a pointer to a 3GPP2/TSG-P document > recording the IPv6 Mobility Discussion at the > recent TSG-P meeting in Kobe, Japan on March 11. > > Pete McCann, Tom Hillar and Paul Francis put > together this 3GPP2 TSGP document. > > > Pointer is: > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > The file name is: > P00-20020311-006 luc IPv6 mobility.doc > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > and other topics (PANA working group, EAP, etc) were > discussed at the meeting. > > I am sending the pointer to the doc as a fyi.... > > Carl > > From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 20:25: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 UAA01461 for ; Wed, 27 Mar 2002 20:25:10 -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 SAA05513; Wed, 27 Mar 2002 18:24: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 RAA20102; Wed, 27 Mar 2002 17: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 g2S1NkKL015912 for ; Wed, 27 Mar 2002 17:23:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S1Nk1Y015911 for mobile-ip-dist; Wed, 27 Mar 2002 17:23: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 jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S1NhKL015904 for ; Wed, 27 Mar 2002 17:23:43 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g2S1Nk7p741947; Wed, 27 Mar 2002 17:23:46 -0800 (PST) Message-Id: <200203280123.g2S1Nk7p741947@jurassic.eng.sun.com> Date: Wed, 27 Mar 2002 17:26:00 -0800 (PST) From: Samita Chakrabarti Subject: Re: [mobile-ip] Comments on Draft 16 To: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Cc: hesham.soliman@era.ericsson.se MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZtEf8Y5bkiOnu+5cOodNgg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-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) wrote: > > > > => Does it matter? I mean if the COTI is always > > done on the intended CoA then wouldn't it always > > work? So if a BU is sent with an Alt-CoA then > > the COTI is done on the Alt-CoA. > > > Ah, if this is done then it does indeed work. > > (But see also below.) > I agree. Alt-COA should correspond with COTI COA. May be we should clarify that in the draft, if not done yet. > > > As for the use, well a multihomed MN may choose > > (for whatever reason) to send a BU from one interface > > to forward traffic to another interface. > > I can't think of a good case right now (apart from > > HMIPv6 :) ). > > > So, in the multihomed case you'd still have to send > the COT/COTI from the real interface, even if the BU > could be sent from elsewhere. Ok for everybody? IMHO, HMIPV6 example seems more real when src-addr of BU is not same as the COA (alt-COA) addr. In that case, the above COTI rule applies. The other example of multihomed hosts seem to be implementation specific. A implementation may choose to set a particular source address corresponding to it's transmitting interface. But the COT message is always sent to the COA of the MN, so the receiving physical interface must have the COA or it could be one of the interfaces of a multihomed MN. Is that what you mean ? Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 21: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 VAA02422 for ; Wed, 27 Mar 2002 21: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 TAA24971; Wed, 27 Mar 2002 19:29:10 -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 SAA29106; Wed, 27 Mar 2002 18:29: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 g2S2SIKL016106 for ; Wed, 27 Mar 2002 18:28:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S2SI8B016105 for mobile-ip-dist; Wed, 27 Mar 2002 18:28: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 g2S2SEKL016098 for ; Wed, 27 Mar 2002 18:28: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 SAA21077 for ; Wed, 27 Mar 2002 18:28:16 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24676 for ; Wed, 27 Mar 2002 19:28:16 -0700 (MST) Received: from pyegani-w2k2.cisco.com ([171.71.129.58] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id SAA04951 for ; Wed, 27 Mar 2002 18:28:15 -0800 (PST) Message-Id: <4.3.2.7.2.20020327174117.01db3f00@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Mar 2002 18:28:14 -0800 To: mobile-ip@sunroof.eng.sun.com From: Parviz Yegani Subject: RE: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 In-Reply-To: <8F698F0DD0B49A48BDA9F451A7A68CAE09C4A9@daebe001.NOE.Nokia. com> 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: I agree with Ernie that IPv6 mobility is a new feature planned for the next release of the 3GPP2 wireless IP network standard. The IPv6 over MIPv4 has been proposed as an interim solution and has not been carefully reviewed even within the TSG-P working group. The group will continue to evaluate the technical merits of this proposal along with other alternatives (eg MIPv6 solution) during the next round of standards development process. Obviously, 3GPP2 member companies are obliged to follow the general guidelines for cooperation between 3GPP2 and IETF as outlined in RFC 3131. According to these guidelines any duplication of work (eg re-inventing protocols/extensions similar to those already been worked out in IETF) should be avoided. Having said that, I don't think posting any unapproved 3GPP2 contributions on IETF mailing lists would serve any purpose. -Parviz At 06:33 PM 3/27/2002 -0600, Ernie.Tacsik@nokia.com wrote: >THIS "UNAPPROVED" CONTRIBUTION CERTAINLY DOES NOT REPRESENT ANY CONSENSUS >IN 3GPP2! In fact the very first sentence: "There are two solutions, >MIPv6 and IPv6 over MIPv4, under consideration for IPv6 mobility" - is >FALSE, and does not represent the >consensus of the working group. Although 3GPP2 does have requirements to >support mobility for IPv6, there has been no decision made on an approach, >or even which of the possible approaches (beyond MIPv6) to pursue. > >3GPP2 (Third Generation Partnership Project 2) is a collaborative third >generation (3G) telecommunications standards-setting project that is >driven by the contributions of its corporate members. >Statements/thoughts/ideas expressed in "UNACCEPTED" contributions have no >basis. > >I believe that propagating this contribution (submitted into 3GPP2) into >the IETF attempts to derail the acceptance of the IETF Mobile IP Working >Group's MIPv6 in favor of an alternative work around (possibly IPR encumbered). > >ernie > >-----Original Message----- >From: ext Tom Hiller [mailto:tomhiller@lucent.com] >Sent: Wednesday, 27 March, 2002 5:02 PM >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting >March 11-15, 2002 > > >To all - > >This is a contribution from Lucent and Tahoe in 3GPP2, and does not represent >consensus in 3GPP2. There may be a need in cdma2000 carriers to integrate >MIPv6 >with network access control mechanisms. In the contribution we are analyzing >different solutions to meet these requirements. 3GPP2 has not yet come to any >conclusions about which particular set of IETF drafts are needed, or which >solutions 3GPP2 will pursue. > >Thanks, >Tom > > > > Below is a pointer to a 3GPP2/TSG-P document > > recording the IPv6 Mobility Discussion at the > > recent TSG-P meeting in Kobe, Japan on March 11. > > > > Pete McCann, Tom Hillar and Paul Francis put > > together this 3GPP2 TSGP document. > > > > > > Pointer is: > > > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > > The file name is: > > P00-20020311-006 luc IPv6 mobility.doc > > > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > > and other topics (PANA working group, EAP, etc) were > > discussed at the meeting. > > > > I am sending the pointer to the doc as a fyi.... > > > > Carl > > > > _________________ Parviz Yegani, Ph.D. Mobile Wireless Group Cisco Systems 3625 Cisco Way San Jose, CA 95134 (408) 853-9018 (voice) (408) 832-5729 (mobile) (408) 853-3543 (fax) Email: pyegani@cisco.com From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 21:31: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 VAA02490 for ; Wed, 27 Mar 2002 21:31:09 -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 SAA29446; Wed, 27 Mar 2002 18:30: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 SAA29620; Wed, 27 Mar 2002 18:30: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 g2S2TfKL016132 for ; Wed, 27 Mar 2002 18:29:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S2Tf9a016131 for mobile-ip-dist; Wed, 27 Mar 2002 18:29: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 g2S2TbKL016121 for ; Wed, 27 Mar 2002 18:29:37 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00089 for ; Wed, 27 Mar 2002 18:29:39 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29924 for ; Wed, 27 Mar 2002 18:29:25 -0800 (PST) Received: from AlperVAIO (dhcp115.docomolabs-usa.com [172.21.96.115]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2S2TdI26445 for ; Wed, 27 Mar 2002 18:29:39 -0800 (PST) Message-ID: <02ad01c1d5ff$72e1ec30$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <4DA6EA82906FD511BE2F00508BCF053803C0741C@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Wed, 27 Mar 2002 18:22:46 -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.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 > Alper, > > > Also AP will have to tell this information to the Access Router. > > This is where a "protocol" for L2 triggers is needed. > > > > => In this case the handover can be MN > initiated. A 'protocol' thaty transfers > L2 triggers is really going down the path > of the L7 L2! Let's not go there Even when this is a mobile-initiated/controlled handover, the access point might know the mobile is gone (through disassociation, etc.). Passing this piece of information to the access router is useful in many aspects. One is, as mentioned in the FMIPv6 draft, this can be used as a signal to oldAR to start forwarding traffic through tunnel to newCoA. We can think of this as "delayed binding update". F-BU doesn't change the forwarding immediately. oldAR waits until it receives a positive confirmation that MN is gone (when this feature is available). (and so that you don't need to bi-cast ;) alper From owner-mobile-ip@sunroof.eng.sun.com Wed Mar 27 22:00: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 WAA03868 for ; Wed, 27 Mar 2002 22:00: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 TAA03243; Wed, 27 Mar 2002 19:59: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 SAA04689; Wed, 27 Mar 2002 18:59: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 g2S2wsKL016263 for ; Wed, 27 Mar 2002 18:58:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S2wsFo016262 for mobile-ip-dist; Wed, 27 Mar 2002 18:58: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 g2S2wpKL016255 for ; Wed, 27 Mar 2002 18:58: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 SAA27576 for ; Wed, 27 Mar 2002 18:58:53 -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 TAA09388 for ; Wed, 27 Mar 2002 19:58:53 -0700 (MST) Received: from pyegani-w2k2.cisco.com ([171.71.129.58] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id SAA27977; Wed, 27 Mar 2002 18:58:52 -0800 (PST) Message-Id: <4.3.2.7.2.20020327183553.01db0600@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Mar 2002 18:58:51 -0800 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Parviz Yegani Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 In-Reply-To: <3CA24F79.89A1FB75@lucent.com> References: <001701c1d534$ae22b390$686015ac@docomocarl> 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: At 05:02 PM 3/27/2002 -0600, Tom Hiller wrote: >To all - > >This is a contribution from Lucent and Tahoe in 3GPP2, and does not represent >consensus in 3GPP2. There may be a need in cdma2000 carriers to integrate >MIPv6 >with network access control mechanisms. In the contribution we are analyzing >different solutions to meet these requirements. 3GPP2 has not yet come to any >conclusions about which particular set of IETF drafts are needed, or which >solutions 3GPP2 will pursue. Tom, I can not agree with your following statement: "3GPP2 has not yet come to any conclusions about which particular set of IETF drafts are needed, or which solutions 3GPP2 will pursue. " As a principle 3GPP2 has agreed to use IETF-based protocols (to the extent possible) for developing wireless IP network standards. Support for IPv6 mobility is no exception! Of course, we can always propose 3GPP2 specific extensions to any existing protocols if necessary. Currently, I am unaware of any such extensions/enhancements needed to support IPv6 mobility in 3GPP2 carriers networks. -Parviz >Thanks, >Tom > > > > Below is a pointer to a 3GPP2/TSG-P document > > recording the IPv6 Mobility Discussion at the > > recent TSG-P meeting in Kobe, Japan on March 11. > > > > Pete McCann, Tom Hillar and Paul Francis put > > together this 3GPP2 TSGP document. > > > > > > Pointer is: > > > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > > The file name is: > > P00-20020311-006 luc IPv6 mobility.doc > > > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > > and other topics (PANA working group, EAP, etc) were > > discussed at the meeting. > > > > I am sending the pointer to the doc as a fyi.... > > > > Carl > > > > _________________ Parviz Yegani, Ph.D. Mobile Wireless Group Cisco Systems 3625 Cisco Way San Jose, CA 95134 (408) 853-9018 (voice) (408) 832-5729 (mobile) (408) 853-3543 (fax) Email: pyegani@cisco.com From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 02:59: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 CAA17647 for ; Thu, 28 Mar 2002 02:59:35 -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 AAA18325; Thu, 28 Mar 2002 00:58: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 XAA13031; Wed, 27 Mar 2002 23: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 g2S7uSKL016857 for ; Wed, 27 Mar 2002 23:56:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S7uSUZ016856 for mobile-ip-dist; Wed, 27 Mar 2002 23:56: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 g2S7uNKL016846 for ; Wed, 27 Mar 2002 23:56:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26768 for ; Wed, 27 Mar 2002 23:56:24 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05358 for ; Wed, 27 Mar 2002 23:56:09 -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 g2S7uJoq014189 for ; Thu, 28 Mar 2002 08:56:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 08:56:18 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 08:46:10 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABB1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'jari.arkko@piuha.net'" , "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Comments on Draft 16 Date: Thu, 28 Mar 2002 08:56: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: > > As for the use, well a multihomed MN may choose > > (for whatever reason) to send a BU from one interface > > to forward traffic to another interface. > > I can't think of a good case right now (apart from > > HMIPv6 :) ). > > > So, in the multihomed case you'd still have to send > the COT/COTI from the real interface, even if the BU > could be sent from elsewhere. Ok for everybody? > => Yes I think you would have to. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 03:43: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 DAA18816 for ; Thu, 28 Mar 2002 03:43:50 -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 BAA11961; Thu, 28 Mar 2002 01:43: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 AAA06409; Thu, 28 Mar 2002 00:43: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 g2S8gfKL017451 for ; Thu, 28 Mar 2002 00:42:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S8geFg017450 for mobile-ip-dist; Thu, 28 Mar 2002 00:42: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 g2S8gbKL017443 for ; Thu, 28 Mar 2002 00:42:37 -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 AAA13145 for ; Thu, 28 Mar 2002 00:42:39 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26456 for ; Thu, 28 Mar 2002 01:42:38 -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 g2S8gboq011586 for ; Thu, 28 Mar 2002 09:42:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 09:42:29 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 09:32:21 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABB8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 09:42:26 +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: > Even when this is a mobile-initiated/controlled > handover, the access point might know the > mobile is gone (through disassociation, etc.). => I don't think this can be done in a real-time-like manner. > > Passing this piece of information to the access > router is useful in many aspects. One is, as > mentioned in the FMIPv6 draft, this can be used > as a signal to oldAR to start forwarding traffic > through tunnel to newCoA. We can think > of this as "delayed binding update". F-BU > doesn't change the forwarding immediately. => Here we go again :). So do we need to go around fixing every link layer to get FMIPv6 to work over all L2s? I think it is much cleaner to have a generic L3 solution that works. > oldAR waits until it receives a positive confirmation > that MN is gone (when this feature is available). > (and so that you don't need to bi-cast ;) => Yeah, at what cost! I mean you want to change IEEE 802.11, or alternatively design a new protocol to transfer non-existent L2 information between the AP and the AR, why? to avoid bicasting! What can I say, if you succeed in doing all this then you've earnt it :) Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:03:26 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 HAA21978 for ; Thu, 28 Mar 2002 07:03:25 -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 FAA27970; Thu, 28 Mar 2002 05:03: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 EAA27571; Thu, 28 Mar 2002 04:02: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 g2SC2GKL018284 for ; Thu, 28 Mar 2002 04:02:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SC2Flc018283 for mobile-ip-dist; Thu, 28 Mar 2002 04:02: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SC2CKL018276 for ; Thu, 28 Mar 2002 04:02:12 -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 EAA16580 for ; Thu, 28 Mar 2002 04:02:14 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08988 for ; Thu, 28 Mar 2002 05:02:12 -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 g2SC2Boq025266 for ; Thu, 28 Mar 2002 13:02:11 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 28 13:00:58 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 12:50:50 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABBD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 Date: Thu, 28 Mar 2002 13:00: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: > > => Does it matter? I mean if the COTI is always > > done on the intended CoA then wouldn't it always > > work? So if a BU is sent with an Alt-CoA then > > the COTI is done on the Alt-CoA. > > The question is really if alt-coa is still useful for > its intended purpose, which is something that the design team > doesn't understand. > > So let me spell things out in detail to see if something jumps out. > Assume a MN has two CoAs: C1 and C2. > It wants to create the binding to C2 but (for whatever > reason) it wants to send the actual BU packet with C1 as a source. > > It would then do HoTI/HoT as normal. > Send a CoTI with C2 as the source, and receive the CoT with C2 as > the destination. > Then it has the cookies necessary to send a BU for CoA=C2 > and it can use any source address for that BU by including > the alt-coa > option. > Thus the MN needs to be able to both send and receive packets > on the alt-coa address in order to get the right Care-of cookie. > > As long as this is still useful things are fine. > But if folks where intending to use alt-coa for cases when > the MN can't > (yet) send and/or receive on that address there is a > problem to combine > this with RR. => Agreed. The screnario that you mention where there could be problems (forwarding to an address that the MN is not in yet) is more relevant to the Fast Handoffs draft, which is why I think there needs to be some serious security work for that draft. Hesham > > Erik > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:08: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 HAA22405 for ; Thu, 28 Mar 2002 07:08:29 -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 FAA00016; Thu, 28 Mar 2002 05:08: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 EAA28940; Thu, 28 Mar 2002 04:07: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 g2SC7OKL018386 for ; Thu, 28 Mar 2002 04:07:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SC7Ow0018385 for mobile-ip-dist; Thu, 28 Mar 2002 04:07: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 g2SC7KKL018378 for ; Thu, 28 Mar 2002 04:07:20 -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 EAA16492 for ; Thu, 28 Mar 2002 04:07:22 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29734 for ; Thu, 28 Mar 2002 05:07:21 -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 HAA22178; Thu, 28 Mar 2002 07:07:18 -0500 (EST) Message-Id: <200203281207.HAA22178@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-fast-mipv6-04.txt Date: Thu, 28 Mar 2002 07:07:17 -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 : Fast Handovers for Mobile IPv6 Author(s) : G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. Malki, M. Khalil Filename : draft-ietf-mobileip-fast-mipv6-04.txt Pages : 62 Date : 27-Mar-02 Mobile IPv6 describes how a Mobile Node can change its point of attachment from one AR to another, a process referred to as handover. During this process, there is a time period during which the Mobile Node is unable to send or receive IPv6 packets. This time period is referred to as handover latency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-04.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-fast-mipv6-04.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-fast-mipv6-04.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: <20020327152105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-fast-mipv6-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-fast-mipv6-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020327152105.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:21: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 HAA22867 for ; Thu, 28 Mar 2002 07:21: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 FAA00063; Thu, 28 Mar 2002 05:21:18 -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 EAA02392; Thu, 28 Mar 2002 04:21: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 g2SCKTKL018519 for ; Thu, 28 Mar 2002 04:20:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCKShi018518 for mobile-ip-dist; Thu, 28 Mar 2002 04:20: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 g2SCKPKL018511 for ; Thu, 28 Mar 2002 04:20:25 -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 EAA19043 for ; Thu, 28 Mar 2002 04:20:27 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29789 for ; Thu, 28 Mar 2002 05:20:26 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 07:20:25 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC6F@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-ietf-mobileip-fast-mipv6-04.txt Date: Thu, 28 Mar 2002 07:20:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: All, Just not to confuse people this is not really new. This was edited long before the last IETF meeting but somehow failed to appear in the directory so Gopal resubmitted. George -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 28, 2002 12:07 PM Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-fast-mipv6-04.txt 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 : Fast Handovers for Mobile IPv6 Author(s) : G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. Malki, M. Khalil Filename : draft-ietf-mobileip-fast-mipv6-04.txt Pages : 62 Date : 27-Mar-02 Mobile IPv6 describes how a Mobile Node can change its point of attachment from one AR to another, a process referred to as handover. During this process, there is a time period during which the Mobile Node is unable to send or receive IPv6 packets. This time period is referred to as handover latency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-04.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-fast-mipv6-04.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-fast-mipv6-04.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. From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:24: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 HAA23000 for ; Thu, 28 Mar 2002 07:24: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 FAA22257; Thu, 28 Mar 2002 05:23: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 EAA02849; Thu, 28 Mar 2002 04:23: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 g2SCMTKL018566 for ; Thu, 28 Mar 2002 04:22:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCMT8a018565 for mobile-ip-dist; Thu, 28 Mar 2002 04:22: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 g2SCMPKL018552 for ; Thu, 28 Mar 2002 04:22: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 EAA19201 for ; Thu, 28 Mar 2002 04:22:27 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05225 for ; Thu, 28 Mar 2002 05:22:26 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 07:22:25 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC70@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] non-security comments to Draft-16 Date: Thu, 28 Mar 2002 07:22:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: I hope the working group is still interested for a couple of non-security comments on this draft. I am reading this after long time and a lot of things are still not clear to me but I thought the following points may be useful. 1. Reverse Tunneling In section 9.5. "Handling Reverse Tunneled Packets from a Mobile Node" There is a statement: " A home agent MUST support decapsulating reverse tunneled packets sent to it from a mobile node's home address. " ...which I think it is absolutely correct although the justification that follows is not as strong as I think the requirement is...but anyway, this is not important. What is important is that section 7.2. "Requirements for IPv6 Home Agents" does not include the above....I think that if this is a MUST then it should be listed in 7.2. 2. Triangular routing Just checking but is this still possible? It seems that it is if the MN does not send a BU to the CN. i.e.: there is nothing in the spec that says that the MN MUST send a BU, is it? Regards George From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:32:19 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 HAA23224 for ; Thu, 28 Mar 2002 07:32:19 -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 FAA24973; Thu, 28 Mar 2002 05:31: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 EAA05290; Thu, 28 Mar 2002 04:31: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 g2SCV4KL018684 for ; Thu, 28 Mar 2002 04:31:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCV4hm018683 for mobile-ip-dist; Thu, 28 Mar 2002 04: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCV1KL018676 for ; Thu, 28 Mar 2002 04:31:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05123 for ; Thu, 28 Mar 2002 04:31:03 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24758 for ; Thu, 28 Mar 2002 04:31:03 -0800 (PST) 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 g2SCV0oq008690 for ; Thu, 28 Mar 2002 13:31:01 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 28 13:29:49 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 13:19:41 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABC2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] non-security comments to Draft-16 Date: Thu, 28 Mar 2002 13:29:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: > 2. Triangular routing > Just checking but is this still possible? It seems that it > is if the MN does > not send a BU to the CN. i.e.: there is nothing in the spec > that says that > the MN MUST send a BU, is it? => No more triangular routing. You must do RO or reverse tunnel. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:34: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 HAA23255 for ; Thu, 28 Mar 2002 07:34:00 -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 FAA25801; Thu, 28 Mar 2002 05:33: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 EAA05838; Thu, 28 Mar 2002 04:33: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 g2SCWmKL018719 for ; Thu, 28 Mar 2002 04:32:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCWmZX018718 for mobile-ip-dist; Thu, 28 Mar 2002 04:32: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 g2SCWjKL018711 for ; Thu, 28 Mar 2002 04:32:45 -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 EAA20407 for ; Thu, 28 Mar 2002 04:32:46 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08394 for ; Thu, 28 Mar 2002 05:32:45 -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 g2SCWioq009831 for ; Thu, 28 Mar 2002 13:32:44 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 13:26:38 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 13:26:39 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABC1@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 13:26:32 +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: Just a question, are you guys aware that this trigger happens _after_ the handover? I can't see how this helps fast handoffs. Hesham > -----Original Message----- > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, March 27, 2002 9:20 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > James, > I like the idea of extending IAPP to provide > L2 trigger to oAR and nAR. > regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 27, 2002 2:12 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Ajoy, > > You are right, it doesn't > > What we would like to do is modify the 802.11 standard, perhaps via > IAPP, so that this information is made available to the AR. > > jak > > ----- Original Message ----- > From: "Singh Ajoy-ASINGH1" > To: > Sent: Wednesday, March 27, 2002 10:33 AM > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > But I didn't think 802.11 allowed the AP to > > know whether a MN has 'left' its coverage area. > > So I always assume that link up or down > > is only relevant to the MN itself. > > I see no reason to send this info to the AR. > > I get the feeling we're talking about different > > things :) are we? > > > > -> If I remember correctly, new AP does send IAPP(?) message > > to old AP after MN is re-associated with new AP. Can't > > we extend IAPP to inform AR about the Mobile node's > > re-association with new AP ? Can some one comment > > about this ? > > > > regards, > > ajoy > > > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, March 27, 2002 12:17 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > I think even in case of Mobile initiated trigger, > > > providing L2 trigger information (Link UP and Link Down) > > > at AR will definitely make the handover better. Probably > > > this is what Alper is referring to. I think this should > > > be doable by extending the existing IAPP protocol or defining > > > a new protocol. Am I missing anything ? > > > > => But I didn't think 802.11 allowed the AP to > > know whether a MN has 'left' its coverage area. > > So I always assume that link up or down > > is only relevant to the MN itself. > > I see no reason to send this info to the AR. > > I get the feeling we're talking about different > > things :) are we? > > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:34: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 HAA23285 for ; Thu, 28 Mar 2002 07:34:27 -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 FAA04570; Thu, 28 Mar 2002 05:34:13 -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 EAA06087; Thu, 28 Mar 2002 04:34: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 g2SCXHKL018750 for ; Thu, 28 Mar 2002 04:33:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCXHTe018749 for mobile-ip-dist; Thu, 28 Mar 2002 04: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCXAKL018732 for ; Thu, 28 Mar 2002 04:33: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 EAA23412 for ; Thu, 28 Mar 2002 04:33:12 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20864 for ; Thu, 28 Mar 2002 05:33:10 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 07:33:05 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC71@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: [mobile-ip] Reverse tunneling issues Date: Thu, 28 Mar 2002 07:33:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: There is a general problem with reverse tunneling and packet loss, which applies to MIPv4 and I think MIPv6 also. Draft-oneill-mip-revtun-ho-00.txt exposed the problem that we faced while trying to implement reverse tunneling in MIPv4. It boils down to the fact that there is no "smooth" handoff equivalent when the MN operates in reverse tunneling mode. The above draft talks about how packets can be lost during handoff and lists a number of different ways of solving the problem from simple configuration changes in the HA, to possible extensions to Mobile IP signaling. As I said, the above work has been done in the context of MIPv4 but similar issues may apply to MIPv6, I am still trying to determine this... Is the WG interested in working on this issue? Has anyone else faced or thought of similar problems with packet loss in reverse tunneling? I would appreciate your feedback/thoughts. Ragards George From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 07:48: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 HAA23666 for ; Thu, 28 Mar 2002 07:48: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 EAA12941; Thu, 28 Mar 2002 04:47:48 -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 EAA23109; Thu, 28 Mar 2002 04:47: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 g2SCknKL019003 for ; Thu, 28 Mar 2002 04:46:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCknR1019002 for mobile-ip-dist; Thu, 28 Mar 2002 04:46: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 g2SCkjKL018995 for ; Thu, 28 Mar 2002 04:46:45 -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 EAA23876 for ; Thu, 28 Mar 2002 04:46:47 -0800 (PST) Received: from penguin.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 FAA00903 for ; Thu, 28 Mar 2002 05:46:46 -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.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SCkkkY002193 for ; Thu, 28 Mar 2002 13:46:46 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 28 13:46:44 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 13:36:36 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABC3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: [mobile-ip] Reverse tunneling issues Date: Thu, 28 Mar 2002 13:46:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: George, Haven't read the draft, but do the problems disappear with triangular routing? Or would you still have the same problem for inbound traffic? Another question, for MIPv4, is it more due to the fact that reverse tunnelling is done by the FA? Because this doesn't exist in v6. Sorry I don't mean to hammer you with questions but I'm just curious about the main reasons. Hesham > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Thursday, March 28, 2002 1:33 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' > Subject: [mobile-ip] Reverse tunneling issues > > > There is a general problem with reverse tunneling and > packet loss, which > applies to MIPv4 and I think MIPv6 also. > Draft-oneill-mip-revtun-ho-00.txt > exposed the problem that we faced while trying to implement reverse > tunneling in MIPv4. > > It boils down to the fact that there is no "smooth" handoff > equivalent when > the MN operates in reverse tunneling mode. The above draft > talks about how > packets can be lost during handoff and lists a number of > different ways of > solving the problem from simple configuration changes in > the HA, to possible > extensions to Mobile IP signaling. > > As I said, the above work has been done in the context of > MIPv4 but similar > issues may apply to MIPv6, I am still trying to determine this... > > Is the WG interested in working on this issue? Has anyone > else faced or > thought of similar problems with packet loss in reverse tunneling? > > I would appreciate your feedback/thoughts. > > Ragards > George > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 08:00: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 IAA23970 for ; Thu, 28 Mar 2002 08:00:53 -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 GAA14380; Thu, 28 Mar 2002 06:00: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 FAA24940; Thu, 28 Mar 2002 05:00: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 g2SCxhKL019141 for ; Thu, 28 Mar 2002 04:59:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCxhxv019140 for mobile-ip-dist; Thu, 28 Mar 2002 04:59: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 g2SCxeKL019133 for ; Thu, 28 Mar 2002 04:59:40 -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 EAA24756 for ; Thu, 28 Mar 2002 04:59:42 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18210 for ; Thu, 28 Mar 2002 05:59:42 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 07:59:41 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC72@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: RE: [mobile-ip] Reverse tunneling issues Date: Thu, 28 Mar 2002 07:59:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Thursday, March 28, 2002 12:47 PM To: 'mobile-ip@sunroof.eng.sun.com' Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' Subject: RE: [mobile-ip] Reverse tunneling issues George, Haven't read the draft, but do the problems disappear with triangular routing? Or would you still have the same problem for inbound traffic? GT> Inbound traffic is ok because of PFANE in MIPv4 and BU to oldAR in MIPv6 so, yes this is only when you do reverse tunneling. Actually the packet loss is mostly at the HA side. For example if the HA has a reverse tunnel entry from CoAx it can accept packets coming from that CoA. If now the MN moves, it will send a new reverse registration for CoAy. If this reaches the HA while packets from the oldCoAx are still on their way to the HA, these packets will thrown on the floor (because the HA replaces old binding with new one). And there is a bit more loss if the CoAy registration is immediately followed by data packets because of difference between fast and slow paths in the HA... Another question, for MIPv4, is it more due to the fact that reverse tunnelling is done by the FA? Because this doesn't exist in v6. GT> As I said this is mostly a problem at the HA side... Sorry I don't mean to hammer you with questions but I'm just curious about the main reasons. GT> No problem...have a look at the draft and do not let the too many options of how to solve the problem confuse you ...this is not complex...it is just that it has to be dealt with. George > -----Original Message----- > From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > Sent: Thursday, March 28, 2002 1:33 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Cc: 'PRoberts@MEGISTO.com'; 'Basavaraj.Patil@nokia.com' > Subject: [mobile-ip] Reverse tunneling issues > > > There is a general problem with reverse tunneling and > packet loss, which > applies to MIPv4 and I think MIPv6 also. > Draft-oneill-mip-revtun-ho-00.txt > exposed the problem that we faced while trying to implement reverse > tunneling in MIPv4. > > It boils down to the fact that there is no "smooth" handoff > equivalent when > the MN operates in reverse tunneling mode. The above draft > talks about how > packets can be lost during handoff and lists a number of > different ways of > solving the problem from simple configuration changes in > the HA, to possible > extensions to Mobile IP signaling. > > As I said, the above work has been done in the context of > MIPv4 but similar > issues may apply to MIPv6, I am still trying to determine this... > > Is the WG interested in working on this issue? Has anyone > else faced or > thought of similar problems with packet loss in reverse tunneling? > > I would appreciate your feedback/thoughts. > > Ragards > George > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 11:19:15 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 LAA02839 for ; Thu, 28 Mar 2002 11:19:14 -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 JAA18284; Thu, 28 Mar 2002 09:18:44 -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 IAA00916; Thu, 28 Mar 2002 08:18: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 g2SGHdKL019559 for ; Thu, 28 Mar 2002 08:17:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SGHcvH019558 for mobile-ip-dist; Thu, 28 Mar 2002 08:17: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 g2SGHZKL019551 for ; Thu, 28 Mar 2002 08:17:35 -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 IAA00734 for ; Thu, 28 Mar 2002 08:17:37 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17531 for ; Thu, 28 Mar 2002 09:17:34 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SGHXI14465 for ; Thu, 28 Mar 2002 08:17:33 -0800 (PST) Message-ID: <002e01c1d673$d7e90400$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <001701c1d534$ae22b390$686015ac@docomocarl> <4.3.2.7.2.20020327183553.01db0600@franklin.cisco.com> Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Date: Thu, 28 Mar 2002 08:15:57 -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 Tom/Parviz/Ernie, I don't think an IETF mailing list is the right place to pursue 3GPP2 debates. One of the factors in the success of the IETF/3GPP collaboration described in Minneapolis was that 3GPP came to IETF with a list of working group drafts which they needed and dates when they needed them by. I would suggest that TSG-P should come to an agreement about which working group drafts they need from the MIP group and let the WG chairs and responsible ADs know. Similarly for other IETF WGs where drafts are needed. Furthermore, if there is technical work on MIP or any other IETF protocol that TSG-P thinks needs doing and there currently isn't a WG draft, then members of TSG-P who are acctive in the working group can submit drafts and request that they be given working group status, as usual. jak ----- Original Message ----- From: "Parviz Yegani" To: ; Sent: Wednesday, March 27, 2002 6:58 PM Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 > At 05:02 PM 3/27/2002 -0600, Tom Hiller wrote: > >To all - > > > >This is a contribution from Lucent and Tahoe in 3GPP2, and does not represent > >consensus in 3GPP2. There may be a need in cdma2000 carriers to integrate > >MIPv6 > >with network access control mechanisms. In the contribution we are analyzing > >different solutions to meet these requirements. 3GPP2 has not yet come to any > >conclusions about which particular set of IETF drafts are needed, or which > >solutions 3GPP2 will pursue. > > Tom, I can not agree with your following statement: > > "3GPP2 has not yet come to any conclusions about which particular > set of IETF > drafts are needed, or which solutions 3GPP2 will pursue. " > > As a principle 3GPP2 has agreed to use IETF-based protocols (to the extent > possible) > for developing wireless IP network standards. Support for IPv6 mobility is > no exception! > Of course, we can always propose 3GPP2 specific extensions to any existing > protocols > if necessary. Currently, I am unaware of any such extensions/enhancements > needed to > support IPv6 mobility in 3GPP2 carriers networks. > > -Parviz > > > >Thanks, > >Tom > > > > > > > Below is a pointer to a 3GPP2/TSG-P document > > > recording the IPv6 Mobility Discussion at the > > > recent TSG-P meeting in Kobe, Japan on March 11. > > > > > > Pete McCann, Tom Hillar and Paul Francis put > > > together this 3GPP2 TSGP document. > > > > > > > > > Pointer is: > > > > > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > > > The file name is: > > > P00-20020311-006 luc IPv6 mobility.doc > > > > > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > > > and other topics (PANA working group, EAP, etc) were > > > discussed at the meeting. > > > > > > I am sending the pointer to the doc as a fyi.... > > > > > > Carl > > > > > > > > _________________ > Parviz Yegani, Ph.D. > Mobile Wireless Group > Cisco Systems > 3625 Cisco Way > San Jose, CA 95134 > (408) 853-9018 (voice) > (408) 832-5729 (mobile) > (408) 853-3543 (fax) > Email: pyegani@cisco.com > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 12:11: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 MAA06386 for ; Thu, 28 Mar 2002 12:11: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 KAA11962; Thu, 28 Mar 2002 10:10: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 JAA10468; Thu, 28 Mar 2002 09:10: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 g2SH9HKL019730 for ; Thu, 28 Mar 2002 09:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SH9HFN019729 for mobile-ip-dist; Thu, 28 Mar 2002 09:09: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 g2SH9EKL019722 for ; Thu, 28 Mar 2002 09:09:14 -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 JAA06654 for ; Thu, 28 Mar 2002 09:09:02 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10956 for ; Thu, 28 Mar 2002 10:09:01 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SH90I15944 for ; Thu, 28 Mar 2002 09:09:00 -0800 (PST) Message-ID: <014601c1d67b$07edc8f0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC1@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 09:07: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 Hesham, The problem is more complex than just using IAPP as a trigger for fast handover. The current working assumption of 802.11f is that fast handovers for voice can be supported using reactive handover. That is, the new access point does the IAPP transaction with the old after the MN has moved rather than the other way around. We've measured L2 handover times at from 90-200 ms with existing products, the IAPP transaction + reactive MIP handover would need to be added to that, and they are additionally proposing adding security to IAPP. Since total (L2 + L3) handover time must be under 40 ms for voice (if you want to support it), their current model of reactive handover is probably not going to get anywhere near supporting voice. In fact, I think it unlikely that 802.11 could really benefit in any significant way from the fast handover work in the MIP group, given the L2 performance of existing products and the current 802.11f efforts to have the APs use IAPP posthandover, regardless of whether it is possible to implement a nonstandard mobile-based trigger. So, we are trying to convince the 802.11f WG to change from a reactive to a proactive model. This would defined a standardized way for the AP to issue a prehandover trigger to the router or MN to get a prehandover trigger based on power levels, and for the AP to initiate the IAPP transaction with the new AP prior to the MN moving. There is some work going on at U. Maryland to measure 802.11 L2 handover times and hopefully this will give the 802.11 group some data to base modifying the basic L2 handover protocol if needed, and for vendors to get some baseline to improve their products. As to how likely they are to accept this model, I think it is probably no more difficult than trying to persuade an IETF WG to accept something, and they are certainly motivated since they want to support voice. At the worst, we will be able to convince them they either need to provide some standardized support for fast handover or give up the goal of supporting voice. jak From: "Hesham Soliman (ERA)" To: Sent: Thursday, March 28, 2002 4:26 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Just a question, are you guys aware that > this trigger happens _after_ the handover? > > I can't see how this helps fast handoffs. > > Hesham > > > -----Original Message----- > > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > > Sent: Wednesday, March 27, 2002 9:20 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > James, > > I like the idea of extending IAPP to provide > > L2 trigger to oAR and nAR. > > regards, > > ajoy > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, March 27, 2002 2:12 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > Ajoy, > > > > You are right, it doesn't > > > > What we would like to do is modify the 802.11 standard, perhaps via > > IAPP, so that this information is made available to the AR. > > > > jak > > > > ----- Original Message ----- > > From: "Singh Ajoy-ASINGH1" > > To: > > Sent: Wednesday, March 27, 2002 10:33 AM > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > But I didn't think 802.11 allowed the AP to > > > know whether a MN has 'left' its coverage area. > > > So I always assume that link up or down > > > is only relevant to the MN itself. > > > I see no reason to send this info to the AR. > > > I get the feeling we're talking about different > > > things :) are we? > > > > > > -> If I remember correctly, new AP does send IAPP(?) message > > > to old AP after MN is re-associated with new AP. Can't > > > we extend IAPP to inform AR about the Mobile node's > > > re-association with new AP ? Can some one comment > > > about this ? > > > > > > regards, > > > ajoy > > > > > > > > > -----Original Message----- > > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > > Sent: Wednesday, March 27, 2002 12:17 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > I think even in case of Mobile initiated trigger, > > > > providing L2 trigger information (Link UP and Link Down) > > > > at AR will definitely make the handover better. Probably > > > > this is what Alper is referring to. I think this should > > > > be doable by extending the existing IAPP protocol or defining > > > > a new protocol. Am I missing anything ? > > > > > > => But I didn't think 802.11 allowed the AP to > > > know whether a MN has 'left' its coverage area. > > > So I always assume that link up or down > > > is only relevant to the MN itself. > > > I see no reason to send this info to the AR. > > > I get the feeling we're talking about different > > > things :) are we? > > > > > > Hesham > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 12:26: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 MAA06974 for ; Thu, 28 Mar 2002 12:26: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 KAA28142; Thu, 28 Mar 2002 10:25: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 JAA14425; Thu, 28 Mar 2002 09:25: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 g2SHObKL019823 for ; Thu, 28 Mar 2002 09:24:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SHObHK019822 for mobile-ip-dist; Thu, 28 Mar 2002 09:24: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 g2SHOWKL019815 for ; Thu, 28 Mar 2002 09:24:34 -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 JAA18571 for ; Thu, 28 Mar 2002 09:24:35 -0800 (PST) Received: from penguin.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 KAA20113 for ; Thu, 28 Mar 2002 10:24:34 -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.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SHOXs7009932 for ; Thu, 28 Mar 2002 18:24:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 28 18:24:26 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 18:24:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABD3@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 18:24:22 +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, > The problem is more complex than just using IAPP as a > trigger for fast > handover. The current working assumption of 802.11f is that fast > handovers for voice can be supported using reactive > handover. That is, > the new access point does the IAPP transaction with the old > after the MN > has moved rather than the other way around. We've measured > L2 handover > times at from 90-200 ms with existing products, the IAPP > transaction + > reactive MIP handover would need to be added to that, and they are > additionally proposing adding security to IAPP. Since total > (L2 + L3) > handover time must be under 40 ms for voice (if you want to > support it), > their current model of reactive handover is probably not > going to get > anywhere near supporting voice. => Which is exactly my point. IAPP is not relevant here. The only way to do it in WLAN (at least so far) is to make sure that the MN initiates the handover based on internal triggers. > > In fact, I think it unlikely that 802.11 could really benefit in any > significant way from the fast handover work in the MIP > group, given the > L2 performance of existing products and the current 802.11f > efforts to > have the APs use IAPP posthandover, regardless of whether > it is possible > to implement a nonstandard mobile-based trigger. => I don't understand why PREREG is not considered a solution here? We always assumed that IAPP is not relevant. > > So, we are trying to convince the 802.11f WG to change from > a reactive > to a proactive model. This would defined a standardized way > for the AP > to issue a prehandover trigger to the router or MN to get a > prehandover > trigger based on power levels, and for the AP to initiate the IAPP > transaction with the new AP prior to the MN moving. There > is some work > going on at U. Maryland to measure 802.11 L2 handover times and > hopefully this will give the 802.11 group some data to base > modifying > the basic L2 handover protocol if needed, and for vendors > to get some > baseline to improve their products. => James I don't understand why or how you can do that. Unless you have connection oriented l2s with the MN reporting measurements to the APs, you can't do it. Is IEEE going to design a cellular network now? Even if this happens, are we going to run IAPP between subnets?? Even if we do that, wouldn't there still be some interruption from the time IAPP does its thing, till the MN actually moves? The level of complication is astounding and frankly I don't understand why you would want to do that. If people within the WG keep ignoring the work that this WG is doing, then I agree, nothing produced by the WG will ever be used! > > As to how likely they are to accept this model, I think it > is probably > no more difficult than trying to persuade an IETF WG to accept > something, and they are certainly motivated since they want > to support > voice. => Well, I suppose the concept of designing a new cellualr system will be exciting for them :) :) Good luck! At the worst, we will be able to convince them they > either need > to provide some standardized support for fast handover or > give up the > goal of supporting voice. => There is another alternative, tell them that there is a draft here that they can at least read first. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 12:37: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 MAA07434 for ; Thu, 28 Mar 2002 12:37: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 KAA05319; Thu, 28 Mar 2002 10:37: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 JAA17695; Thu, 28 Mar 2002 09:37: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 g2SHabKL019964 for ; Thu, 28 Mar 2002 09:36:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SHabWj019963 for mobile-ip-dist; Thu, 28 Mar 2002 09:36: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 g2SHaYKL019956 for ; Thu, 28 Mar 2002 09:36:34 -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 JAA16444 for ; Thu, 28 Mar 2002 09:36:36 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22085 for ; Thu, 28 Mar 2002 10:36:34 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SHaXI16846; Thu, 28 Mar 2002 09:36:33 -0800 (PST) Message-ID: <017101c1d67e$e0c00af0$7e6015ac@T23KEMPF> From: "James Kempf" To: Cc: , References: <8C92E23A3E87FB479988285F9E22BE465ABC72@ftmail> Subject: Re: [mobile-ip] Reverse tunneling issues Date: Thu, 28 Mar 2002 09:34:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" 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 George, > > GT> Inbound traffic is ok because of PFANE in MIPv4 and BU to oldAR in MIPv6 > so, yes this is only when you do reverse tunneling. Actually the packet loss > is mostly at the HA side. For example if the HA has a reverse tunnel entry > from CoAx it can accept packets coming from that CoA. If now the MN moves, > it will send a new reverse registration for CoAy. If this reaches the HA > while packets from the oldCoAx are still on their way to the HA, these > packets will thrown on the floor (because the HA replaces old binding with > new one). I think with FMIPv6 you can defer the BU to the HA until the traffic slows down. Also, what about registering CoAy as an alt-CoA initially? > And there is a bit more loss if the CoAy registration is > immediately followed by data packets because of difference between fast and > slow paths in the HA... > I'm not sure I understand this, maybe I need to read Alan's draft. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 12:39: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 MAA07514 for ; Thu, 28 Mar 2002 12:39: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 KAA06683; Thu, 28 Mar 2002 10:39: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 JAA18269; Thu, 28 Mar 2002 09:39: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 g2SHcjKL019999 for ; Thu, 28 Mar 2002 09:38:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SHciq4019998 for mobile-ip-dist; Thu, 28 Mar 2002 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SHcfKL019991 for ; Thu, 28 Mar 2002 09:38: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 JAA17994 for ; Thu, 28 Mar 2002 09:38:43 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17890 for ; Thu, 28 Mar 2002 10:38:43 -0700 (MST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2SHcfF29278 for ; Thu, 28 Mar 2002 12:38:41 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA04602; Thu, 28 Mar 2002 11:38:39 -0600 (CST) Message-ID: <3CA354D8.E9ED215E@lucent.com> Date: Thu, 28 Mar 2002 11:37:28 -0600 From: Tom Hiller Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 References: <001701c1d534$ae22b390$686015ac@docomocarl> <4.3.2.7.2.20020327183553.01db0600@franklin.cisco.com> <002e01c1d673$d7e90400$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 Jim, We agree that 3GPP2 debates are not a topic for the MIP mailing list. At the same time I'd like to state that 3GPP2 members have partcipated in IETF working groups for four years now as individuals. An ftp pointer to a 3GPP2 contribution was posted without our being consulted. The purpose of the contribution is for internal discussion within 3GPP2. I responded to the MIP mailing list to put it in context, so it would not be misinterpreted. When we come to some conclusions in 3GPP2, we'll be sure to bring input to the working group. Thanks, Tom James Kempf wrote: > > Tom/Parviz/Ernie, > > I don't think an IETF mailing list is the right place to pursue 3GPP2 > debates. > > One of the factors in the success of the IETF/3GPP collaboration > described in Minneapolis was that 3GPP came to IETF with a list of > working group drafts which they needed and dates when they needed them > by. I would suggest that TSG-P should come to an agreement about which > working group drafts they need from the MIP group and let the WG chairs > and responsible ADs know. Similarly for other IETF WGs where drafts are > needed. Furthermore, if there is technical work on MIP or any other IETF > protocol that TSG-P thinks needs doing and there currently isn't a WG > draft, then members of TSG-P who are acctive in the working group can > submit drafts and request that they be given working group status, as > usual. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 12:42:52 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 MAA07640 for ; Thu, 28 Mar 2002 12:42: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 KAA20447; Thu, 28 Mar 2002 10:42: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 JAA18692; Thu, 28 Mar 2002 09: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 g2SHfpKL020091 for ; Thu, 28 Mar 2002 09:41:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SHfoOP020090 for mobile-ip-dist; Thu, 28 Mar 2002 09:41: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 g2SHflKL020078 for ; Thu, 28 Mar 2002 09:41:47 -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 JAA24785 for ; Thu, 28 Mar 2002 09:41:50 -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 KAA19973 for ; Thu, 28 Mar 2002 10:41:49 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 28 Mar 2002 09:41:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D67F.D54C1C4A" Subject: RE: [mobile-ip] Comments on Draft 16 Date: Thu, 28 Mar 2002 09:41:47 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF198@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Comments on Draft 16 Thread-Index: AcHWRqT9dfLkf0xdQcOlN4SzgeBuUgAN+jhQ From: "Mohan Parthasarathy" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 28 Mar 2002 17:41:47.0572 (UTC) FILETIME=[D5970740:01C1D67F] Sender: owner-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_01C1D67F.D54C1C4A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 >=20 > > Or if the binding cache entry is removed/expired, a=20 > replayed binding=20 > > update will be accepted (assuming nonces are still valid). I am not=20 > > sure how bad is this. But requiring the implementors to=20 > store it in NV=20 > > might be a overkill because you have to store one per MN=20 > plus the home > > address and how do you know when to ever remove them from NV ? >=20 > Mohan, >=20 > The issue with non-volatile memory for the sequence number is=20 > just an issue for the HA. BUs sent to CNs rely on fresh=20 > cookies to prevent replays combined with using the sequence=20 > number when the CN already has a BCE. This requires some case=20 > (not well-specified in -16) on how to deleted BCEs at a CN -=20 > essentially it needs to keep a tombstone BCE around=20 > until the cookies used to create it are so old they would be rejected. >=20 Ok. I see that BU3WAY draft seems to explain this in a bit more detail. > Since we're not using RR cookies for the home registration (for better > performance) and allow IPsec with static keys (which can't=20 > provide IPsec replay protection) it seems like we need the=20 > sequence numbers to provide strong replay protection for home=20 > registrations. >=20 I don't think I have spent enough time reading the latest (146 pages ?) MIPv6 draft I guess :-) So, for the HA case, as there are no cookies we need to store it in NV for preventing replay attacks. I am not able to see how you can ever remove this entry from NV. As soon as you remove it, a old binding update can be replayed and will be accepted I guess. -mohan > Erik >=20 >=20 >=20 ------_=_NextPart_001_01C1D67F.D54C1C4A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Comments on Draft 16

 
>
>
> > Or if the binding cache entry is = removed/expired, a
> replayed binding
> > update will be accepted (assuming nonces = are still valid). I am not
> > sure how bad is this. But requiring the = implementors to
> store it in NV
> > might be a overkill because you have to = store one per MN
> plus the home
> > address and how do you know when to ever = remove them from NV ?
>
> Mohan,
>
> The issue with non-volatile memory for the = sequence number is
> just an issue for the HA. BUs sent to CNs rely = on fresh
> cookies to prevent replays combined with using = the sequence
> number when the CN already has a BCE. This = requires some case
> (not well-specified in -16) on how to deleted = BCEs at a CN -
> essentially it needs to keep a tombstone BCE = around
> until the cookies used to create it are so old = they would be rejected.
>
Ok. I see that BU3WAY draft seems to explain this in = a bit more detail.

> Since we're not using RR cookies for the home = registration (for better
> performance) and allow IPsec with static keys = (which can't
> provide IPsec replay protection) it seems like = we need the
> sequence numbers to provide strong replay = protection for home
> registrations.
>
I don't think I have spent enough time reading the = latest (146 pages ?)
MIPv6 draft I guess :-) So, for the HA case, as there = are no cookies
we need to store it in NV for preventing replay = attacks. I am not able
to see how you can ever remove this entry from NV. As = soon as you remove it,
a old binding update can be replayed and will be = accepted I guess.


-mohan

>   Erik
>
>
>

------_=_NextPart_001_01C1D67F.D54C1C4A-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 13:02: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 NAA08417 for ; Thu, 28 Mar 2002 13:02: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 LAA19098; Thu, 28 Mar 2002 11:02: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 KAA25223; Thu, 28 Mar 2002 10:01: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 g2SI11KL020393 for ; Thu, 28 Mar 2002 10:01:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SI11LH020392 for mobile-ip-dist; Thu, 28 Mar 2002 10:01: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 g2SI0wKL020385 for ; Thu, 28 Mar 2002 10:00:58 -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 KAA01219 for ; Thu, 28 Mar 2002 10:01:00 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29649 for ; Thu, 28 Mar 2002 11:01:00 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 13:00:56 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC81@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Reverse tunneling issues Date: Thu, 28 Mar 2002 13:00:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-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: inline -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, March 28, 2002 5:35 PM To: mobile-ip@sunroof.eng.sun.com Cc: PRoberts@MEGISTO.com; Basavaraj.Patil@nokia.com Subject: Re: [mobile-ip] Reverse tunneling issues George, > > GT> Inbound traffic is ok because of PFANE in MIPv4 and BU to oldAR in MIPv6 > so, yes this is only when you do reverse tunneling. Actually the packet loss > is mostly at the HA side. For example if the HA has a reverse tunnel entry > from CoAx it can accept packets coming from that CoA. If now the MN moves, > it will send a new reverse registration for CoAy. If this reaches the HA > while packets from the oldCoAx are still on their way to the HA, these > packets will thrown on the floor (because the HA replaces old binding with > new one). I think with FMIPv6 you can defer the BU to the HA until the traffic slows down. GT> And what will that do? and when will the traffic slow down? I guess I do not understand what you are saying. Also, what about registering CoAy as an alt-CoA initially? GT> From what I understand about alt-COAs they do replace your bindings, don't they? so you still have the problem. > And there is a bit more loss if the CoAy registration is > immediately followed by data packets because of difference between fast and > slow paths in the HA... > I'm not sure I understand this, maybe I need to read Alan's draft. GT> It may be a good idea... George From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 13:11: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 NAA08857 for ; Thu, 28 Mar 2002 13:11:42 -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 LAA15576; Thu, 28 Mar 2002 11:11: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 KAA28847; Thu, 28 Mar 2002 10: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 g2SIATKL020559 for ; Thu, 28 Mar 2002 10:10:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SIAToh020558 for mobile-ip-dist; Thu, 28 Mar 2002 10:10: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 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 g2SIAOKL020551 for ; Thu, 28 Mar 2002 10:10:25 -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 g2SIANx09360; Thu, 28 Mar 2002 19:10:24 +0100 (MET) Date: Thu, 28 Mar 2002 19:10:09 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Comments on Draft 16 To: Mohan Parthasarathy Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <416B5AF360DED54088DAD3CA8BFBEA6E1DF198@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: > I don't think I have spent enough time reading the latest (146 pages ?) > MIPv6 draft I guess :-) So, for the HA case, as there are no cookies > we need to store it in NV for preventing replay attacks. I am not able > to see how you can ever remove this entry from NV. As soon as you remove > it, > a old binding update can be replayed and will be accepted I guess. Yes, but a home agent also need to permanently retain information about the MNs it is serving such as home address manual IPsec key # if manual keys home address certficate # if IKE is used [IKE could presumably use pre-shared keys etc. as well.] The only additional requirement due to the sequence number is that it will change as bindings are processed. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 13:16: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 NAA08979 for ; Thu, 28 Mar 2002 13:16: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 LAA08653; Thu, 28 Mar 2002 11:16: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 KAA01133; Thu, 28 Mar 2002 10:16: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 g2SIFVKL020645 for ; Thu, 28 Mar 2002 10:15:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SIFVNd020644 for mobile-ip-dist; Thu, 28 Mar 2002 10:15: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 g2SIFPKL020637 for ; Thu, 28 Mar 2002 10:15:26 -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 KAA05081 for ; Thu, 28 Mar 2002 10:15:28 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12221 for ; Thu, 28 Mar 2002 11:15:26 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 28 Mar 2002 10:15:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D684.889334CA" Subject: RE: [mobile-ip] Comments on Draft 16 Date: Thu, 28 Mar 2002 10:15:25 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E634A0F@TNEXVS02.tahoenetworks.com> Thread-Topic: [mobile-ip] Comments on Draft 16 Thread-Index: AcHWg9cmH4jw1j6STJGU6S/GLuMRdQAAD1Cg From: "Mohan Parthasarathy" To: "Erik Nordmark" Cc: "Erik Nordmark" , X-OriginalArrivalTime: 28 Mar 2002 18:15:26.0290 (UTC) FILETIME=[88D6F320:01C1D684] Sender: owner-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_01C1D684.889334CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]=20 > Sent: Thursday, March 28, 2002 10:10 AM > To: Mohan Parthasarathy > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Comments on Draft 16 >=20 >=20 > > I don't think I have spent enough time reading the latest=20 > (146 pages=20 > > ?) MIPv6 draft I guess :-) So, for the HA case, as there are no=20 > > cookies we need to store it in NV for preventing replay=20 > attacks. I am=20 > > not able to see how you can ever remove this entry from NV.=20 > As soon as=20 > > you remove it, a old binding update can be replayed and will be=20 > > accepted I guess. >=20 > Yes, but a home agent also need to permanently retain=20 > information about the MNs it is serving such as > home address manual IPsec key # if manual keys > home address certficate # if IKE is used > [IKE could presumably use pre-shared keys etc. as well.] >=20 > The only additional requirement due to the sequence number is=20 > that it will change as bindings are processed. >=20 Ok, that puts things in perspective :-) But may be I am reading into what NV memory is i.e the above are generally not stored in NV memory. That sort of strikes as a new and different requirement which in practice is not. So, perhaps it can be reworded or just state what you have said above which makes it very clear. -mohan > Erik >=20 >=20 ------_=_NextPart_001_01C1D684.889334CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Comments on Draft 16

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.co= m]
> Sent: Thursday, March 28, 2002 10:10 AM
> To: Mohan Parthasarathy
> Cc: Erik Nordmark; = mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Comments on Draft = 16
>
>
> > I don't think I have spent enough time = reading the latest
> (146 pages
> > ?) MIPv6 draft I guess :-) So, for the HA = case, as there are no
> > cookies we need to store it in NV for = preventing replay
> attacks. I am
> > not able to see how you can ever remove = this entry from NV.
> As soon as
> > you remove it, a old binding update can be = replayed and will be
> > accepted I guess.
>
> Yes, but a home agent also need to permanently = retain
> information about the MNs it is serving such = as
>       home = address            = manual IPsec key        # if manual = keys
>       home = address            = certficate      =         # if IKE is used
> [IKE could presumably use pre-shared keys etc. = as well.]
>
> The only additional requirement due to the = sequence number is
> that it will change as bindings are = processed.
>
Ok, that puts things in perspective :-) But may be I = am reading into
what NV memory is i.e the above are generally not = stored in NV memory.
That sort of strikes as a new and different = requirement which in practice
is not. So, perhaps it can be reworded or just state = what you have said
above which makes it very clear.

-mohan

>   Erik
>
>

------_=_NextPart_001_01C1D684.889334CA-- From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 13:37: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 NAA09847 for ; Thu, 28 Mar 2002 13:37: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 LAA18656; Thu, 28 Mar 2002 11:37: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 KAA09333; Thu, 28 Mar 2002 10:37: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 g2SIaSKL020809 for ; Thu, 28 Mar 2002 10:36:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SIaS3g020808 for mobile-ip-dist; Thu, 28 Mar 2002 10:36: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 g2SIaPKL020801 for ; Thu, 28 Mar 2002 10:36:25 -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 KAA10999 for ; Thu, 28 Mar 2002 10:36:26 -0800 (PST) From: Ernie.Tacsik@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 LAA28704 for ; Thu, 28 Mar 2002 11:36:26 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2SIcpc27125 for ; Thu, 28 Mar 2002 12:38:51 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 28 Mar 2002 12:36:24 -0600 Received: from daebe001.NOE.Nokia.com ([172.18.242.222]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Mar 2002 12:35:52 -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] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Date: Thu, 28 Mar 2002 12:35:52 -0600 Message-ID: <8F698F0DD0B49A48BDA9F451A7A68CAE09C4AA@daebe001.NOE.Nokia.com> Thread-Topic: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Thread-Index: AcHWdETB1grcv88NQfOwiDTVeklzMQAEJbQg To: X-OriginalArrivalTime: 28 Mar 2002 18:35:52.0737 (UTC) FILETIME=[63DBE910:01C1D687] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2SIaQKL020802 Sender: owner-mobile-ip@sunroof.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 couldn't agree more. 3GPP2/TSG-P is making an effort to improve communications with the IETF. Specifically an IETF draft dependency list is being generated to convey specific 3GPP2 needs/requirements. My point is that this list needs to be an approved 3GPP2-wide list communicated under the liaison agreement in RFC3131, NOT a forwarded, unapproved, "spun" corporate contribution to a specific 3GPP2 TSG. I might doubt that the general IETF audience is aware of the protocols and procedures used to make corporate member contributions into SDOs like 3GPP2. I would hate to see a precedence of "unapproved" contributions made into another forum forwarded to specific IETF WG lists and misrepresented as fact. thanx -----Original Message----- From: ext James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, 28 March, 2002 10:16 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Tom/Parviz/Ernie, I don't think an IETF mailing list is the right place to pursue 3GPP2 debates. One of the factors in the success of the IETF/3GPP collaboration described in Minneapolis was that 3GPP came to IETF with a list of working group drafts which they needed and dates when they needed them by. I would suggest that TSG-P should come to an agreement about which working group drafts they need from the MIP group and let the WG chairs and responsible ADs know. Similarly for other IETF WGs where drafts are needed. Furthermore, if there is technical work on MIP or any other IETF protocol that TSG-P thinks needs doing and there currently isn't a WG draft, then members of TSG-P who are acctive in the working group can submit drafts and request that they be given working group status, as usual. jak ----- Original Message ----- From: "Parviz Yegani" To: ; Sent: Wednesday, March 27, 2002 6:58 PM Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 > At 05:02 PM 3/27/2002 -0600, Tom Hiller wrote: > >To all - > > > >This is a contribution from Lucent and Tahoe in 3GPP2, and does not represent > >consensus in 3GPP2. There may be a need in cdma2000 carriers to integrate > >MIPv6 > >with network access control mechanisms. In the contribution we are analyzing > >different solutions to meet these requirements. 3GPP2 has not yet come to any > >conclusions about which particular set of IETF drafts are needed, or which > >solutions 3GPP2 will pursue. > > Tom, I can not agree with your following statement: > > "3GPP2 has not yet come to any conclusions about which particular > set of IETF > drafts are needed, or which solutions 3GPP2 will pursue. " > > As a principle 3GPP2 has agreed to use IETF-based protocols (to the extent > possible) > for developing wireless IP network standards. Support for IPv6 mobility is > no exception! > Of course, we can always propose 3GPP2 specific extensions to any existing > protocols > if necessary. Currently, I am unaware of any such extensions/enhancements > needed to > support IPv6 mobility in 3GPP2 carriers networks. > > -Parviz > > > >Thanks, > >Tom > > > > > > > Below is a pointer to a 3GPP2/TSG-P document > > > recording the IPv6 Mobility Discussion at the > > > recent TSG-P meeting in Kobe, Japan on March 11. > > > > > > Pete McCann, Tom Hillar and Paul Francis put > > > together this 3GPP2 TSGP document. > > > > > > > > > Pointer is: > > > > > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > > > The file name is: > > > P00-20020311-006 luc IPv6 mobility.doc > > > > > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > > > and other topics (PANA working group, EAP, etc) were > > > discussed at the meeting. > > > > > > I am sending the pointer to the doc as a fyi.... > > > > > > Carl > > > > > > > > _________________ > Parviz Yegani, Ph.D. > Mobile Wireless Group > Cisco Systems > 3625 Cisco Way > San Jose, CA 95134 > (408) 853-9018 (voice) > (408) 832-5729 (mobile) > (408) 853-3543 (fax) > Email: pyegani@cisco.com > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 13:48: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 NAA10246 for ; Thu, 28 Mar 2002 13:48:41 -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 LAA05414; Thu, 28 Mar 2002 11:48: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 KAA14522; Thu, 28 Mar 2002 10:48: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 g2SIlVKL021036 for ; Thu, 28 Mar 2002 10:47:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SIlVNE021035 for mobile-ip-dist; Thu, 28 Mar 2002 10:47: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 g2SIlSKL021028 for ; Thu, 28 Mar 2002 10:47:28 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19860 for ; Thu, 28 Mar 2002 10:47:30 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21477 for ; Thu, 28 Mar 2002 10:47:15 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SIlTI19298 for ; Thu, 28 Mar 2002 10:47:29 -0800 (PST) Message-ID: <01f801c1d688$c9e1cf80$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABD3@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 10:45:53 -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, > => Which is exactly my point. IAPP is not relevant here. > The only way to do it in WLAN (at least so far) is to > make sure that the MN initiates the handover > based on internal triggers. > If the vendors build IAPP into their APs and 802.11 handover is designed to require a secure IAPP transaction to complete before the new AP lets the MN send packets onto the new link, then this will lengthen 802.11 handover out considerably beyond the rather poor performance of the current round of AP products. Regardless of what the MN does prior to handover. So I think it is very relevent indeed. > => I don't understand why PREREG is not considered > a solution here? We always assumed that IAPP is > not relevant. > It doesn't matter which fast handover algorithm is used, if the IAPP transaction takes, say, 200 ms to complete and the L2 handover takes 200 ms to complete before the MN is allowed to get new packets through the new AP, then any optimization at Layer 3 will be in the noise. I wasn't making a point about PREREG v.s. POSTREG, I was making a point about how the assumptions being made by the 802.11 committee are causing both algorithms to be not useful. > => James I don't understand why or how you can do that. > Unless you have connection oriented l2s with the MN > reporting measurements to the APs, you can't > do it. Is IEEE going to design a cellular network > now? > Even if this happens, are we going to run IAPP > between subnets?? Even if we do that, wouldn't > there still be some interruption from the time > IAPP does its thing, till the MN actually moves? > > The level of complication is astounding and frankly > I don't understand why you would want to do that. > > If people within the WG keep ignoring the work that this > WG is doing, then I agree, nothing produced > by the WG will ever be used! > Please stay calm, Hesham. "We" are not going to run IAPP, that is what the 802.11 committee wants to do. The problem IAPP is supposed to solve is to tell the old access point to unallocate buffers and clean up other data structures associated with providing the MN with IP connectivity. Onto that, there has been additional stuff loaded, like context transfer. Also, I believe they are thinking of using it for flushing the ARP cache. I'd suggest that if you have some interest in seeing the right thing done, you contact Bernard Abboba who has been monitoring them closely, and have him brief you on the details. Also, take a look at the 802.11f IAPP spec, http://grouper.ieee.org/groups/802/11/ and browse from there. If you see something that he and I have missed, then please let us know. We are just trying to convince them that their protocol needs some work if it will properly support fast IP handover. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:10: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 OAA11147 for ; Thu, 28 Mar 2002 14:10:27 -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 MAA18637; Thu, 28 Mar 2002 12:10: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 LAA25097; Thu, 28 Mar 2002 11:10: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 g2SJ9HKL021385 for ; Thu, 28 Mar 2002 11:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJ9HJg021384 for mobile-ip-dist; Thu, 28 Mar 2002 11:09: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 g2SJ96KL021368 for ; Thu, 28 Mar 2002 11:09:06 -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 LAA20247 for ; Thu, 28 Mar 2002 11:09:07 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26952 for ; Thu, 28 Mar 2002 12:09:06 -0700 (MST) Received: from AlperVAIO (dhcp115.docomolabs-usa.com [172.21.96.115]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SJ96I20105 for ; Thu, 28 Mar 2002 11:09:06 -0800 (PST) Message-ID: <000301c1d68b$11b000f0$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABB8@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 10:30:49 -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.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 > > Even when this is a mobile-initiated/controlled > > handover, the access point might know the > > mobile is gone (through disassociation, etc.). > > => I don't think this can be done in a > real-time-like manner. Well, we have to look at numbers... (and definition of "real-time" :) > > > > > Passing this piece of information to the access > > router is useful in many aspects. One is, as > > mentioned in the FMIPv6 draft, this can be used > > as a signal to oldAR to start forwarding traffic > > through tunnel to newCoA. We can think > > of this as "delayed binding update". F-BU > > doesn't change the forwarding immediately. > > => Here we go again :). So do we need to go around > fixing every link layer to get FMIPv6 to work > over all L2s? No.. Whereever this is available, it shall be used. If the network can detect disassociation (a L2 feature) and can pass this information to AR (sometimes implementation, sometimes a new protocol issue depending on whether L2 and L3 are co-located or not), this can be used. > I think it is much cleaner to have a generic L3 > solution that works. Depends on the "L3 solution". > > > oldAR waits until it receives a positive confirmation > > that MN is gone (when this feature is available). > > (and so that you don't need to bi-cast ;) > > => Yeah, at what cost! I mean you want to > change IEEE 802.11, or alternatively design > a new protocol to transfer non-existent L2 > information between the AP and the AR, why? > to avoid bicasting! > What can I say, if you succeed in doing all > this then you've earnt it :) Bi-casting is used to compensate for uncertainity on the network as to when the mobile leaves. If we can solve the root of the problem, we don't need bi-casting. So, this is worth looking at. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:10: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 OAA11175 for ; Thu, 28 Mar 2002 14:10: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 MAA18887; Thu, 28 Mar 2002 12:10: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 LAA25322; Thu, 28 Mar 2002 11:10: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 g2SJ99KL021382 for ; Thu, 28 Mar 2002 11:09:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJ99DE021381 for mobile-ip-dist; Thu, 28 Mar 2002 11:09: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 g2SJ95KL021367 for ; Thu, 28 Mar 2002 11:09: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 LAA20246 for ; Thu, 28 Mar 2002 11:09:07 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26948 for ; Thu, 28 Mar 2002 12:09:06 -0700 (MST) Received: from AlperVAIO (dhcp115.docomolabs-usa.com [172.21.96.115]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SJ96I20102 for ; Thu, 28 Mar 2002 11:09:06 -0800 (PST) Message-ID: <000201c1d68b$11ab6d10$736015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6ABC1@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 10:23: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.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 The trigger (at least I am talking about) is LINK DOWN. So it's OK if it happens after the handover. As long as it happens shortly (how short?) after the handover, it's fine. This is not pre-trigger. alper ----- Original Message ----- From: "Hesham Soliman (ERA)" To: Sent: Thursday, March 28, 2002 4:26 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Just a question, are you guys aware that > this trigger happens _after_ the handover? > > I can't see how this helps fast handoffs. > > Hesham > > > -----Original Message----- > > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > > Sent: Wednesday, March 27, 2002 9:20 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > James, > > I like the idea of extending IAPP to provide > > L2 trigger to oAR and nAR. > > regards, > > ajoy > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Wednesday, March 27, 2002 2:12 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > Ajoy, > > > > You are right, it doesn't > > > > What we would like to do is modify the 802.11 standard, perhaps via > > IAPP, so that this information is made available to the AR. > > > > jak > > > > ----- Original Message ----- > > From: "Singh Ajoy-ASINGH1" > > To: > > Sent: Wednesday, March 27, 2002 10:33 AM > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > But I didn't think 802.11 allowed the AP to > > > know whether a MN has 'left' its coverage area. > > > So I always assume that link up or down > > > is only relevant to the MN itself. > > > I see no reason to send this info to the AR. > > > I get the feeling we're talking about different > > > things :) are we? > > > > > > -> If I remember correctly, new AP does send IAPP(?) message > > > to old AP after MN is re-associated with new AP. Can't > > > we extend IAPP to inform AR about the Mobile node's > > > re-association with new AP ? Can some one comment > > > about this ? > > > > > > regards, > > > ajoy > > > > > > > > > -----Original Message----- > > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > > Sent: Wednesday, March 27, 2002 12:17 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > I think even in case of Mobile initiated trigger, > > > > providing L2 trigger information (Link UP and Link Down) > > > > at AR will definitely make the handover better. Probably > > > > this is what Alper is referring to. I think this should > > > > be doable by extending the existing IAPP protocol or defining > > > > a new protocol. Am I missing anything ? > > > > > > => But I didn't think 802.11 allowed the AP to > > > know whether a MN has 'left' its coverage area. > > > So I always assume that link up or down > > > is only relevant to the MN itself. > > > I see no reason to send this info to the AR. > > > I get the feeling we're talking about different > > > things :) are we? > > > > > > Hesham > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:13: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 OAA11293 for ; Thu, 28 Mar 2002 14:12: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 LAA01415; Thu, 28 Mar 2002 11:12: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 LAA26419; Thu, 28 Mar 2002 11:12: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 g2SJBsKL021469 for ; Thu, 28 Mar 2002 11:11:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJBsnJ021468 for mobile-ip-dist; Thu, 28 Mar 2002 11:11: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 g2SJBoKL021461 for ; Thu, 28 Mar 2002 11:11: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 LAA21145 for ; Thu, 28 Mar 2002 11:11:52 -0800 (PST) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19764 for ; Thu, 28 Mar 2002 12:11:52 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 14:11:51 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465ABC82@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 14:11:49 -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: James, Maybe the larger question is why WE (the IETF) is concerned with how a link layer mobility management protocol works and indeed why are we discussing how it should be changed to become better or worst. Otherwise we should also get the specs from GSMA, 3GPP, 3GPP2, and a hundred other organizations and start analyzing them and trying to make them do this and that. I think this does not make any sense at all...and I wonder...is it only me? George -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, March 28, 2002 6:46 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Hesham, > => Which is exactly my point. IAPP is not relevant here. > The only way to do it in WLAN (at least so far) is to > make sure that the MN initiates the handover > based on internal triggers. > If the vendors build IAPP into their APs and 802.11 handover is designed to require a secure IAPP transaction to complete before the new AP lets the MN send packets onto the new link, then this will lengthen 802.11 handover out considerably beyond the rather poor performance of the current round of AP products. Regardless of what the MN does prior to handover. So I think it is very relevent indeed. > => I don't understand why PREREG is not considered > a solution here? We always assumed that IAPP is > not relevant. > It doesn't matter which fast handover algorithm is used, if the IAPP transaction takes, say, 200 ms to complete and the L2 handover takes 200 ms to complete before the MN is allowed to get new packets through the new AP, then any optimization at Layer 3 will be in the noise. I wasn't making a point about PREREG v.s. POSTREG, I was making a point about how the assumptions being made by the 802.11 committee are causing both algorithms to be not useful. > => James I don't understand why or how you can do that. > Unless you have connection oriented l2s with the MN > reporting measurements to the APs, you can't > do it. Is IEEE going to design a cellular network > now? > Even if this happens, are we going to run IAPP > between subnets?? Even if we do that, wouldn't > there still be some interruption from the time > IAPP does its thing, till the MN actually moves? > > The level of complication is astounding and frankly > I don't understand why you would want to do that. > > If people within the WG keep ignoring the work that this > WG is doing, then I agree, nothing produced > by the WG will ever be used! > Please stay calm, Hesham. "We" are not going to run IAPP, that is what the 802.11 committee wants to do. The problem IAPP is supposed to solve is to tell the old access point to unallocate buffers and clean up other data structures associated with providing the MN with IP connectivity. Onto that, there has been additional stuff loaded, like context transfer. Also, I believe they are thinking of using it for flushing the ARP cache. I'd suggest that if you have some interest in seeing the right thing done, you contact Bernard Abboba who has been monitoring them closely, and have him brief you on the details. Also, take a look at the 802.11f IAPP spec, http://grouper.ieee.org/groups/802/11/ and browse from there. If you see something that he and I have missed, then please let us know. We are just trying to convince them that their protocol needs some work if it will properly support fast IP handover. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:36: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 OAA12290 for ; Thu, 28 Mar 2002 14:36:22 -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 LAA06366; Thu, 28 Mar 2002 11:36:07 -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 LAA27832; Thu, 28 Mar 2002 11:35: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 g2SJZ1KL021713 for ; Thu, 28 Mar 2002 11:35:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJZ1TU021712 for mobile-ip-dist; Thu, 28 Mar 2002 11:35: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 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 g2SJYxKL021705 for ; Thu, 28 Mar 2002 11:34:59 -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 OAA08481 for ; Thu, 28 Mar 2002 14:35:01 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id OAA21544 for mobile-ip@sunroof.eng.sun.com; Thu, 28 Mar 2002 14:35:55 -0500 (EST) Received: from odin.France.Sun.COM (odin.France.Sun.COM [129.157.174.8]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAkYKL018095 for ; Thu, 28 Mar 2002 02:46:35 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by odin.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2SAkZF15221; Thu, 28 Mar 2002 11:46:35 +0100 (MET) Date: Thu, 28 Mar 2002 11:46:21 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] alt-coa - Comments on Draft 16 To: hesham.soliman@era.ericsson.se Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053802C6ABA6@Esealnt861.al.sw.ericsson.se> 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: > => Does it matter? I mean if the COTI is always > done on the intended CoA then wouldn't it always > work? So if a BU is sent with an Alt-CoA then > the COTI is done on the Alt-CoA. The question is really if alt-coa is still useful for its intended purpose, which is something that the design team doesn't understand. So let me spell things out in detail to see if something jumps out. Assume a MN has two CoAs: C1 and C2. It wants to create the binding to C2 but (for whatever reason) it wants to send the actual BU packet with C1 as a source. It would then do HoTI/HoT as normal. Send a CoTI with C2 as the source, and receive the CoT with C2 as the destination. Then it has the cookies necessary to send a BU for CoA=C2 and it can use any source address for that BU by including the alt-coa option. Thus the MN needs to be able to both send and receive packets on the alt-coa address in order to get the right Care-of cookie. As long as this is still useful things are fine. But if folks where intending to use alt-coa for cases when the MN can't (yet) send and/or receive on that address there is a problem to combine this with RR. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:53: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 OAA12732 for ; Thu, 28 Mar 2002 14:53: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 MAA26856; Thu, 28 Mar 2002 12:52: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 LAA02431; Thu, 28 Mar 2002 11:52: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 g2SJpdKL021849 for ; Thu, 28 Mar 2002 11:51:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJpdoq021848 for mobile-ip-dist; Thu, 28 Mar 2002 11:51: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 g2SJpaKL021841 for ; Thu, 28 Mar 2002 11:51:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12513 for ; Thu, 28 Mar 2002 11:51:38 -0800 (PST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12230 for ; Thu, 28 Mar 2002 11:51:23 -0800 (PST) Received: from pyegani-w2k2.cisco.com (sjc-vpn1-1009.cisco.com [10.21.99.241]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id LAA14259; Thu, 28 Mar 2002 11:51:37 -0800 (PST) Message-Id: <4.3.2.7.2.20020328112440.0371a5e0@franklin.cisco.com> X-Sender: pyegani@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Mar 2002 11:51:35 -0800 To: mobile-ip@sunroof.eng.sun.com, From: Parviz Yegani Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 In-Reply-To: <002e01c1d673$d7e90400$7e6015ac@T23KEMPF> References: <001701c1d534$ae22b390$686015ac@docomocarl> <4.3.2.7.2.20020327183553.01db0600@franklin.cisco.com> 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: At 08:15 AM 3/28/2002 -0800, James Kempf wrote: >Tom/Parviz/Ernie, > >I don't think an IETF mailing list is the right place to pursue 3GPP2 >debates. Agree 100%. This is exactly the point I was trying to make. >One of the factors in the success of the IETF/3GPP collaboration >described in Minneapolis was that 3GPP came to IETF with a list of >working group drafts which they needed and dates when they needed them >by. I would suggest that TSG-P should come to an agreement about which >working group drafts they need from the MIP group and let the WG chairs >and responsible ADs know. Similarly for other IETF WGs where drafts are >needed. Furthermore, if there is technical work on MIP or any other IETF >protocol that TSG-P thinks needs doing and there currently isn't a WG >draft, then members of TSG-P who are acctive in the working group can >submit drafts and request that they be given working group status, as >usual. Good suggestion. We are in the process of establishing a formal liaison between TSG-P and IETF WGs (MIP, AAA, etc). Thanks, Parviz > jak > >----- Original Message ----- >From: "Parviz Yegani" >To: ; >Sent: Wednesday, March 27, 2002 6:58 PM >Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting >March 11-15, 2002 > > > > At 05:02 PM 3/27/2002 -0600, Tom Hiller wrote: > > >To all - > > > > > >This is a contribution from Lucent and Tahoe in 3GPP2, and does not >represent > > >consensus in 3GPP2. There may be a need in cdma2000 carriers to >integrate > > >MIPv6 > > >with network access control mechanisms. In the contribution we are >analyzing > > >different solutions to meet these requirements. 3GPP2 has not yet >come to any > > >conclusions about which particular set of IETF drafts are needed, or >which > > >solutions 3GPP2 will pursue. > > > > Tom, I can not agree with your following statement: > > > > "3GPP2 has not yet come to any conclusions about which >particular > > set of IETF > > drafts are needed, or which solutions 3GPP2 will pursue. " > > > > As a principle 3GPP2 has agreed to use IETF-based protocols (to the >extent > > possible) > > for developing wireless IP network standards. Support for IPv6 >mobility is > > no exception! > > Of course, we can always propose 3GPP2 specific extensions to any >existing > > protocols > > if necessary. Currently, I am unaware of any such >extensions/enhancements > > needed to > > support IPv6 mobility in 3GPP2 carriers networks. > > > > -Parviz > > > > > > >Thanks, > > >Tom > > > > > > > > > > Below is a pointer to a 3GPP2/TSG-P document > > > > recording the IPv6 Mobility Discussion at the > > > > recent TSG-P meeting in Kobe, Japan on March 11. > > > > > > > > Pete McCann, Tom Hillar and Paul Francis put > > > > together this 3GPP2 TSGP document. > > > > > > > > > > > > Pointer is: > > > > > > > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > > > > The file name is: > > > > P00-20020311-006 luc IPv6 mobility.doc > > > > > > > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > > > > and other topics (PANA working group, EAP, etc) were > > > > discussed at the meeting. > > > > > > > > I am sending the pointer to the doc as a fyi.... > > > > > > > > Carl > > > > > > > > > > > > _________________ > > Parviz Yegani, Ph.D. > > Mobile Wireless Group > > Cisco Systems > > 3625 Cisco Way > > San Jose, CA 95134 > > (408) 853-9018 (voice) > > (408) 832-5729 (mobile) > > (408) 853-3543 (fax) > > Email: pyegani@cisco.com > > > > _________________ Parviz Yegani, Ph.D. Mobile Wireless Group Cisco Systems 3625 Cisco Way San Jose, CA 95134 (408) 853-9018 (voice) (408) 832-5729 (mobile) (408) 853-3543 (fax) Email: pyegani@cisco.com From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:56: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 OAA12857 for ; Thu, 28 Mar 2002 14:56:47 -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 MAA13683; Thu, 28 Mar 2002 12:56:29 -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 LAA03506; Thu, 28 Mar 2002 11:56: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 g2SJtiKL021934 for ; Thu, 28 Mar 2002 11:55:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJth0N021933 for mobile-ip-dist; Thu, 28 Mar 2002 11:55: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 g2SJteKL021926 for ; Thu, 28 Mar 2002 11:55:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13631 for ; Thu, 28 Mar 2002 11:55:42 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13420 for ; Thu, 28 Mar 2002 11:55:27 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SJtgI21798 for ; Thu, 28 Mar 2002 11:55:42 -0800 (PST) Message-ID: <029301c1d692$511d79a0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <8C92E23A3E87FB479988285F9E22BE465ABC82@ftmail> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 11:54:05 -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 George, Good point. The 802.11 committee drafted a liason letter which is on the IETF liason page regarding EAP after a period of informal contacts between the committee and an IETF member, namely Bernard. The letter requested some joint action regarding EAP, the BOF held in Minneapolis is a result, and if the IESG approves, a WG will form. The work I've been discussing is currently in the current informal stage, which Bernard and I are pursuing because we'd like to see 802.11 do the right thing for supporting IP handover. At some point, it may become desirable to formalize the association through a liason letter similar to what was drafted for EAP. So, IETF is doing nothing formally with respect to 802.11f right now, Bernard and I are. IETF is doing something formally with 802.11i regarding EAP, and that is described in the aformentioned liason letter. jak ----- Original Message ----- From: "George Tsirtsis" To: Sent: Thursday, March 28, 2002 11:11 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > James, > > Maybe the larger question is why WE (the IETF) is concerned with how a link > layer mobility management protocol works and indeed why are we discussing > how it should be changed to become better or worst. Otherwise we should also > get the specs from GSMA, 3GPP, 3GPP2, and a hundred other organizations and > start analyzing them and trying to make them do this and that. > > I think this does not make any sense at all...and I wonder...is it only me? > > George > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 28, 2002 6:46 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Hesham, > > > => Which is exactly my point. IAPP is not relevant here. > > The only way to do it in WLAN (at least so far) is to > > make sure that the MN initiates the handover > > based on internal triggers. > > > > If the vendors build IAPP into their APs and 802.11 handover is designed > to require a secure IAPP transaction to complete before the new AP lets > the MN send packets onto the new link, then this will lengthen 802.11 > handover out considerably beyond the rather poor performance of the > current round of AP products. Regardless of what the MN does prior to > handover. So I think it is very relevent indeed. > > > => I don't understand why PREREG is not considered > > a solution here? We always assumed that IAPP is > > not relevant. > > > > It doesn't matter which fast handover algorithm is used, if the IAPP > transaction takes, say, 200 ms to complete and the L2 handover takes 200 > ms to complete before the MN is allowed to get new packets through the > new AP, then any optimization at Layer 3 will be in the noise. I wasn't > making a point about PREREG v.s. POSTREG, I was making a point about how > the assumptions being made by the 802.11 committee are causing both > algorithms to be not useful. > > > => James I don't understand why or how you can do that. > > Unless you have connection oriented l2s with the MN > > reporting measurements to the APs, you can't > > do it. Is IEEE going to design a cellular network > > now? > > Even if this happens, are we going to run IAPP > > between subnets?? Even if we do that, wouldn't > > there still be some interruption from the time > > IAPP does its thing, till the MN actually moves? > > > > The level of complication is astounding and frankly > > I don't understand why you would want to do that. > > > > If people within the WG keep ignoring the work that this > > WG is doing, then I agree, nothing produced > > by the WG will ever be used! > > > > Please stay calm, Hesham. > > "We" are not going to run IAPP, that is what the 802.11 committee wants > to do. The problem IAPP is supposed to solve is to tell the old access > point to unallocate buffers and clean up other data structures > associated with providing the MN with IP connectivity. Onto that, there > has been additional stuff loaded, like context transfer. Also, I believe > they are thinking of using it for flushing the ARP cache. > > I'd suggest that if you have some interest in seeing the right thing > done, you contact Bernard Abboba who has been monitoring them closely, > and have him brief you on the details. Also, take a look at the 802.11f > IAPP spec, http://grouper.ieee.org/groups/802/11/ and browse from there. > If you see something that he and I have missed, then please let us > know. We are just trying to convince them that their protocol needs some > work if it will properly support fast IP handover. > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 14:59: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 OAA12936 for ; Thu, 28 Mar 2002 14:59: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 MAA15371; Thu, 28 Mar 2002 12:59: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 LAA04428; Thu, 28 Mar 2002 11:59: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 g2SJx3KL022022 for ; Thu, 28 Mar 2002 11:59:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJx3AF022021 for mobile-ip-dist; Thu, 28 Mar 2002 11: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SJx0KL022014 for ; Thu, 28 Mar 2002 11:59: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 LAA15534 for ; Thu, 28 Mar 2002 11:59:02 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07445 for ; Thu, 28 Mar 2002 12:59:01 -0700 (MST) Received: from docomocarl (dhcp104.docomolabs-usa.com [172.21.96.104]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2SJx0I21978 for ; Thu, 28 Mar 2002 11:59:00 -0800 (PST) Message-ID: <08e201c1d693$84992490$686015ac@docomocarl> From: "Carl Williams" To: References: <001701c1d534$ae22b390$686015ac@docomocarl><4.3.2.7.2.20020327183553.01db0600@franklin.cisco.com> <4.3.2.7.2.20020328112440.0371a5e0@franklin.cisco.com> Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Date: Thu, 28 Mar 2002 12:02: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.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: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Parviz Yegani" To: ; Sent: Thursday, March 28, 2002 11:51 AM Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 > At 08:15 AM 3/28/2002 -0800, James Kempf wrote: > >Tom/Parviz/Ernie, > > > >I don't think an IETF mailing list is the right place to pursue 3GPP2 > >debates. > > Agree 100%. This is exactly the point I was trying to make. > > > >One of the factors in the success of the IETF/3GPP collaboration > >described in Minneapolis was that 3GPP came to IETF with a list of > >working group drafts which they needed and dates when they needed them > >by. I would suggest that TSG-P should come to an agreement about which > >working group drafts they need from the MIP group and let the WG chairs > >and responsible ADs know. Similarly for other IETF WGs where drafts are > >needed. Furthermore, if there is technical work on MIP or any other IETF > >protocol that TSG-P thinks needs doing and there currently isn't a WG > >draft, then members of TSG-P who are acctive in the working group can > >submit drafts and request that they be given working group status, as > >usual. > > Good suggestion. We are in the process of establishing a formal liaison between > TSG-P and IETF WGs (MIP, AAA, etc). > Parviz, I am glad my fyi posting is creating some action :-).... Carl > Thanks, > Parviz > > > > jak > > > >----- Original Message ----- > >From: "Parviz Yegani" > >To: ; > >Sent: Wednesday, March 27, 2002 6:58 PM > >Subject: Re: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting > >March 11-15, 2002 > > > > > > > At 05:02 PM 3/27/2002 -0600, Tom Hiller wrote: > > > >To all - > > > > > > > >This is a contribution from Lucent and Tahoe in 3GPP2, and does not > >represent > > > >consensus in 3GPP2. There may be a need in cdma2000 carriers to > >integrate > > > >MIPv6 > > > >with network access control mechanisms. In the contribution we are > >analyzing > > > >different solutions to meet these requirements. 3GPP2 has not yet > >come to any > > > >conclusions about which particular set of IETF drafts are needed, or > >which > > > >solutions 3GPP2 will pursue. > > > > > > Tom, I can not agree with your following statement: > > > > > > "3GPP2 has not yet come to any conclusions about which > >particular > > > set of IETF > > > drafts are needed, or which solutions 3GPP2 will pursue. " > > > > > > As a principle 3GPP2 has agreed to use IETF-based protocols (to the > >extent > > > possible) > > > for developing wireless IP network standards. Support for IPv6 > >mobility is > > > no exception! > > > Of course, we can always propose 3GPP2 specific extensions to any > >existing > > > protocols > > > if necessary. Currently, I am unaware of any such > >extensions/enhancements > > > needed to > > > support IPv6 mobility in 3GPP2 carriers networks. > > > > > > -Parviz > > > > > > > > > >Thanks, > > > >Tom > > > > > > > > > > > > > Below is a pointer to a 3GPP2/TSG-P document > > > > > recording the IPv6 Mobility Discussion at the > > > > > recent TSG-P meeting in Kobe, Japan on March 11. > > > > > > > > > > Pete McCann, Tom Hillar and Paul Francis put > > > > > together this 3GPP2 TSGP document. > > > > > > > > > > > > > > > Pointer is: > > > > > > > > > > ftp://ftp.3gpp2.org/TSGP/Working/2002/20020311-Kobe/ > > > > > The file name is: > > > > > P00-20020311-006 luc IPv6 mobility.doc > > > > > > > > > > Discussion regarding MIPv6, requirements, WLAN, DIAMETER, > > > > > and other topics (PANA working group, EAP, etc) were > > > > > discussed at the meeting. > > > > > > > > > > I am sending the pointer to the doc as a fyi.... > > > > > > > > > > Carl > > > > > > > > > > > > > > > > _________________ > > > Parviz Yegani, Ph.D. > > > Mobile Wireless Group > > > Cisco Systems > > > 3625 Cisco Way > > > San Jose, CA 95134 > > > (408) 853-9018 (voice) > > > (408) 832-5729 (mobile) > > > (408) 853-3543 (fax) > > > Email: pyegani@cisco.com > > > > > > > > _________________ > Parviz Yegani, Ph.D. > Mobile Wireless Group > Cisco Systems > 3625 Cisco Way > San Jose, CA 95134 > (408) 853-9018 (voice) > (408) 832-5729 (mobile) > (408) 853-3543 (fax) > Email: pyegani@cisco.com > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 15:00: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 PAA13009 for ; Thu, 28 Mar 2002 15:00: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 NAA15898; Thu, 28 Mar 2002 13:00: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 MAA04865; Thu, 28 Mar 2002 12:00: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 g2SJxsKL022042 for ; Thu, 28 Mar 2002 11:59:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJxsTO022041 for mobile-ip-dist; Thu, 28 Mar 2002 11:59: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 g2SJxpKL022034 for ; Thu, 28 Mar 2002 11:59:51 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15150 for ; Thu, 28 Mar 2002 11:59:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09464 for ; Thu, 28 Mar 2002 11:59:49 -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 LAA23081 for ; Thu, 28 Mar 2002 11:59:48 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2SJxl526913 for ; Thu, 28 Mar 2002 11:59:47 -0800 X-mProtect:  Thu, 28 Mar 2002 11:59:47 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpditWlyN; Thu, 28 Mar 2002 11:59:45 PST Message-ID: <3CA37632.F1BE23A@iprg.nokia.com> Date: Thu, 28 Mar 2002 11:59:46 -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] IPv4 Fast Handover Support for 802.11 References: <8C92E23A3E87FB479988285F9E22BE465ABC82@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 Sorry to interrupt.. I think if IAPP is improved in IEEE, that's good; another crucial step towards supporting real-time applications during WLAN mobility.. For us, we should constrain ourselves with IP mobility aspects. If it turns out that certain link-specific issues are of interest, they should be handled separately in an appropriate "link-specific extensions" document. In general, I have reservations to including L2-specific optimizations in the base specification. My 2 cents.. -Rajeev George Tsirtsis wrote: > James, > > Maybe the larger question is why WE (the IETF) is concerned with how a link > layer mobility management protocol works and indeed why are we discussing > how it should be changed to become better or worst. Otherwise we should also > get the specs from GSMA, 3GPP, 3GPP2, and a hundred other organizations and > start analyzing them and trying to make them do this and that. > > I think this does not make any sense at all...and I wonder...is it only me? > > George > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, March 28, 2002 6:46 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > Hesham, > > > => Which is exactly my point. IAPP is not relevant here. > > The only way to do it in WLAN (at least so far) is to > > make sure that the MN initiates the handover > > based on internal triggers. > > > > If the vendors build IAPP into their APs and 802.11 handover is designed > to require a secure IAPP transaction to complete before the new AP lets > the MN send packets onto the new link, then this will lengthen 802.11 > handover out considerably beyond the rather poor performance of the > current round of AP products. Regardless of what the MN does prior to > handover. So I think it is very relevent indeed. > > > => I don't understand why PREREG is not considered > > a solution here? We always assumed that IAPP is > > not relevant. > > > > It doesn't matter which fast handover algorithm is used, if the IAPP > transaction takes, say, 200 ms to complete and the L2 handover takes 200 > ms to complete before the MN is allowed to get new packets through the > new AP, then any optimization at Layer 3 will be in the noise. I wasn't > making a point about PREREG v.s. POSTREG, I was making a point about how > the assumptions being made by the 802.11 committee are causing both > algorithms to be not useful. > > > => James I don't understand why or how you can do that. > > Unless you have connection oriented l2s with the MN > > reporting measurements to the APs, you can't > > do it. Is IEEE going to design a cellular network > > now? > > Even if this happens, are we going to run IAPP > > between subnets?? Even if we do that, wouldn't > > there still be some interruption from the time > > IAPP does its thing, till the MN actually moves? > > > > The level of complication is astounding and frankly > > I don't understand why you would want to do that. > > > > If people within the WG keep ignoring the work that this > > WG is doing, then I agree, nothing produced > > by the WG will ever be used! > > > > Please stay calm, Hesham. > > "We" are not going to run IAPP, that is what the 802.11 committee wants > to do. The problem IAPP is supposed to solve is to tell the old access > point to unallocate buffers and clean up other data structures > associated with providing the MN with IP connectivity. Onto that, there > has been additional stuff loaded, like context transfer. Also, I believe > they are thinking of using it for flushing the ARP cache. > > I'd suggest that if you have some interest in seeing the right thing > done, you contact Bernard Abboba who has been monitoring them closely, > and have him brief you on the details. Also, take a look at the 802.11f > IAPP spec, http://grouper.ieee.org/groups/802/11/ and browse from there. > If you see something that he and I have missed, then please let us > know. We are just trying to convince them that their protocol needs some > work if it will properly support fast IP handover. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 15:58: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 PAA14773 for ; Thu, 28 Mar 2002 15:58: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 MAA21386; Thu, 28 Mar 2002 12:57:29 -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 MAA09616; Thu, 28 Mar 2002 12:57: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 g2SKujKL022473 for ; Thu, 28 Mar 2002 12:56:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SKuj6E022472 for mobile-ip-dist; Thu, 28 Mar 2002 12:56: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 jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SKugKL022465 for ; Thu, 28 Mar 2002 12:56:42 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g2SKui7p178328; Thu, 28 Mar 2002 12:56:45 -0800 (PST) Message-Id: <200203282056.g2SKui7p178328@jurassic.eng.sun.com> Date: Thu, 28 Mar 2002 12:58:58 -0800 (PST) From: Samita Chakrabarti Subject: Re: [mobile-ip] Comments on Draft 16 To: mobile-ip@sunroof.eng.sun.com, jari.arkko@piuha.net Cc: erik.nordmark@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: UHCI8ZJV+BlyEMiy01m5OA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-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, As being discussed, section 4.5.4 "Securing Binding Updates to Hame Agents" needs some clarification on sequence number usage for HA and MN. Vijay's description below clears concept for MN behavior in case it reboots. As per Vijay's description on draft15, HA can accept BUs with any seq# after HA reboots as it does not keep the state upon reboot. I am trying to understand how useful would it be to keep the seqno/MN information in HA's NV memory. If the HA reboots it looses all other information including binding etc. But when the MN re-registers with HA it'll use a seq# higher than what's in the HA's NV ram. Although, it adds extra replay protection at HA, I'd think, the home-agent usage of NV memory could be optional. I'd like to know how big is the threat in this particular case (i,e if HA reboots). If we somehow decide that HA should preserve the bindings accross reboot, then obviously, it makes sense to have all the information intact. Also this section mentions "The mobile node and homeagent MAY on a new key for the security association before this many (2**31) BU have been sent if this is an issue". I wonder if we leave it as MAY, then there might be some interoperability issues as MN and HA may have different expectations. Please see my additional comments on draft 16 changes below. ============================================== > Jari Arkko wrote: > > > > Thanks Brian for your comments! Some answer below: > > > > >>Both the mobile node and the home agent MUST use non-volatile memory > > >>to store the sequence number so that a reboot does not prevent the > > >>acceptance of new Binding Updates. > > > > > > Why is this a MUST and not a SHOULD (or MAY) > > > > The nv memory allows for protection against replays. If there's > > no nv memory, we'll have to provide a resynch procedure, which could > > be used by attackers in a replay too. > > > > But I'm not sure either whether this should be a MUST. Perhaps a SHOULD > > would be sufficient? > > wrote: > There was something in draft 15 to handle the case when the > MN reboots. If the MN sends a BU with a sequence number smaller > than the one it had sent before the reboot, the HA rejects the > BU and sends a BAck with error status 141 (sequence number too > small). In addition to this, the HA includes the sequence number > from its binding cache in the BAck. For the next BU, the MN > chooses a sequence number greater than the sequence number in > the returned BAck. > > When the HA reboots and comes up, it accepts whatever sequence > number the MN sends. More comments/questions on the new changes for draft16: 1. section 4.5.5, please clarify in words how the Correspondent node secret key Kcn would be used. There is an example of MAC_Kcn in COT message processing, but that is not very clear. 2. In HOTI and COTI messages we use "nonce" index. What is "nonce" index? Is it a random number ? IBM has IPR on nonces, how different or same is this nonce index from IBM's nonces ? 3. section 5.1.8 refers to "refresh" field. After last Connectathon and the followup discussion at IETF, I think we have decided to remove the "refresh" field as default and make it optional --correct ? More later. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 16:43: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 PAA14772 for ; Thu, 28 Mar 2002 15:58: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 MAA20982; Thu, 28 Mar 2002 12:55:25 -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 MAA08882; Thu, 28 Mar 2002 12: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 g2SKsDKL022411 for ; Thu, 28 Mar 2002 12:54:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SKsDHZ022410 for mobile-ip-dist; Thu, 28 Mar 2002 12:54: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 g2SKsAKL022403 for ; Thu, 28 Mar 2002 12:54:10 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08550 for ; Thu, 28 Mar 2002 12:54:13 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24560 for ; Thu, 28 Mar 2002 12:54:14 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA09853 for ; Thu, 28 Mar 2002 13:54:12 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA10920 for ; Thu, 28 Mar 2002 13:54:12 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Thu, 28 Mar 2002 14:54:11 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Thu, 28 Mar 2002 14:54:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) 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: Hesham, I am not talking about pre-trigger here. But I do not see any thing wrong in providing link up and link down trigger at AR after L2 handover. regards, ajoy -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Thursday, March 28, 2002 6:27 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Just a question, are you guys aware that this trigger happens _after_ the handover? I can't see how this helps fast handoffs. Hesham > -----Original Message----- > From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] > Sent: Wednesday, March 27, 2002 9:20 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > James, > I like the idea of extending IAPP to provide > L2 trigger to oAR and nAR. > regards, > ajoy > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Wednesday, March 27, 2002 2:12 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Ajoy, > > You are right, it doesn't > > What we would like to do is modify the 802.11 standard, perhaps via > IAPP, so that this information is made available to the AR. > > jak > > ----- Original Message ----- > From: "Singh Ajoy-ASINGH1" > To: > Sent: Wednesday, March 27, 2002 10:33 AM > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > But I didn't think 802.11 allowed the AP to > > know whether a MN has 'left' its coverage area. > > So I always assume that link up or down > > is only relevant to the MN itself. > > I see no reason to send this info to the AR. > > I get the feeling we're talking about different > > things :) are we? > > > > -> If I remember correctly, new AP does send IAPP(?) message > > to old AP after MN is re-associated with new AP. Can't > > we extend IAPP to inform AR about the Mobile node's > > re-association with new AP ? Can some one comment > > about this ? > > > > regards, > > ajoy > > > > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, March 27, 2002 12:17 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > I think even in case of Mobile initiated trigger, > > > providing L2 trigger information (Link UP and Link Down) > > > at AR will definitely make the handover better. Probably > > > this is what Alper is referring to. I think this should > > > be doable by extending the existing IAPP protocol or defining > > > a new protocol. Am I missing anything ? > > > > => But I didn't think 802.11 allowed the AP to > > know whether a MN has 'left' its coverage area. > > So I always assume that link up or down > > is only relevant to the MN itself. > > I see no reason to send this info to the AR. > > I get the feeling we're talking about different > > things :) are we? > > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Mar 28 17:13: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 RAA17762 for ; Thu, 28 Mar 2002 17:13:11 -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 PAA29605; Thu, 28 Mar 2002 15:12: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 OAA29248; Thu, 28 Mar 2002 14:12: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 g2SMBtKL022700 for ; Thu, 28 Mar 2002 14:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SMBsHf022699 for mobile-ip-dist; Thu, 28 Mar 2002 14:11: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 g2SMBpKL022692 for ; Thu, 28 Mar 2002 14:11:51 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28913 for ; Thu, 28 Mar 2002 14:11:53 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23969 for ; Thu, 28 Mar 2002 14:11:37 -0800 (PST) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6F4892CE4 for ; Thu, 28 Mar 2002 17:11:52 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 29B0C7DF for ; Thu, 28 Mar 2002 17:11:52 -0500 (EST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2SMBoR00390; Thu, 28 Mar 2002 17:11:50 -0500 (EST) Received: from compaq.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id RAA0000177118; Thu, 28 Mar 2002 17:11:49 -0500 (EST) Message-ID: <3CA39525.1F045379@compaq.com> Date: Thu, 28 Mar 2002 17:11:49 -0500 From: Vladislav Yasevich Organization: Compaq 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] Comments on Draft 16 References: <200203282056.g2SKui7p178328@jurassic.eng.sun.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 I don't think it makes much sense storing the BU sequence number in NV memory. Since all BUs to the home agent (home registrations) should be protected by some kind of security (the latest specs mandates ESP), then replay protection would be provided by ESP itself. The home agent MAY store the key/cert in NV ram as Eric suggested, but that completely depends on the configuration. Just my thoughts. -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 Mar 28 22:25: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 WAA23675 for ; Thu, 28 Mar 2002 22:25:27 -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 UAA20995; Thu, 28 Mar 2002 20:24: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 TAA05910; Thu, 28 Mar 2002 19: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 g2T3NbKL023331 for ; Thu, 28 Mar 2002 19:23:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2T3Nb22023330 for mobile-ip-dist; Thu, 28 Mar 2002 19:23: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 g2T3NYKL023323 for ; Thu, 28 Mar 2002 19:23: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 TAA15473 for ; Thu, 28 Mar 2002 19:23:36 -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 UAA14186 for ; Thu, 28 Mar 2002 20:23:36 -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 TAA17926; Thu, 28 Mar 2002 19:23:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2T3NRC17035; Thu, 28 Mar 2002 19:23:27 -0800 X-mProtect:  Thu, 28 Mar 2002 19:23:27 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdacdyK3; Thu, 28 Mar 2002 19:23:25 PST Message-ID: <3CA3DE2E.66A9D202@iprg.nokia.com> Date: Thu, 28 Mar 2002 19:23:26 -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: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6ABBD@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 long as this is still useful things are fine. > > But if folks where intending to use alt-coa for cases when > > the MN can't > > (yet) send and/or receive on that address there is a > > problem to combine > > this with RR. > > => Agreed. The screnario that you mention where > there could be problems (forwarding to an address > that the MN is not in yet) is more relevant > to the Fast Handoffs draft, which is why I think > there needs to be some serious security work > for that draft. > [Rajeev:] If I may add to this.. In the current version of FMIPv6, a MN binds (or attempts to bind) its current CoA-1 with a prospective CoA-2 valid on the new access router. In other words, CoA-1 is the temporary HoA. So, the addresses in Fast BU look as follows: Src-IP = CoA-1, Dst-IP = AR-1, HAO = CoA-1, alt-coa = CoA-2. For HoTI/HoT test: since the AR-1 is the AR forwarding packets to CoA-1, this is somewhat simplified. In fact, ProxyRtSol can be HoTI and ProxyRtAdv can be HoT. For CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using Handover Initiate/ Ack sequence. Only when AR-1 receives such a confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN arrives, you cannot flood any arbitrary node but AR-2 itself. But, AR-2 only maintains a very small buffer corresponding to proxy ND cache for packets destined for CoA-2. Assuming that AR-1 and AR-2 have security association, could this vouching by AR-2 be considered sufficient ? Regards, -Rajeev > > Hesham > > > > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 10:12: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 KAA17705 for ; Fri, 29 Mar 2002 10:12:28 -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 IAA00939; Fri, 29 Mar 2002 08:12: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 HAA00692; Fri, 29 Mar 2002 07:11: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 g2TFB4KL024103 for ; Fri, 29 Mar 2002 07:11:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TFB3BR024102 for mobile-ip-dist; Fri, 29 Mar 2002 07:11: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 g2TFAxKL024095 for ; Fri, 29 Mar 2002 07:11:00 -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 g2TFAxx18877; Fri, 29 Mar 2002 16:10:59 +0100 (MET) Date: Fri, 29 Mar 2002 16:10:44 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 To: Rajeev Koodli Cc: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "Hesham Soliman (ERA)" In-Reply-To: "Your message with ID" <3CA3DE2E.66A9D202@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 CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using > Handover Initiate/ Ack sequence. Only when AR-1 receives such a > confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to > CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN arrives, > you cannot flood any arbitrary node but AR-2 itself. But, AR-2 > only maintains a very small buffer corresponding to proxy ND cache for > packets destined for CoA-2. > > Assuming that AR-1 and AR-2 have security association, could this > vouching by AR-2 be considered sufficient ? Rajeev, Since I don't know much about FMIPv6 let me try to restate an approximation which should't add any significant new residual threats. Assume AR-1 and AR-2 have a security association used for these messages. AR-1 sends something to AR-2 saying "MN coming your way - will have CoA-2 when it arrives". AR-2 responds with "ok, I will forward the CoT when I get it". Then AR-2 then forwards the CoT to either AR-2 (which in turn sends it to CoA-1) or directly to CoA-1 at which point the MN can send the BU. Basically AR-2 trusts AR-1, under the security association, so that random nodes can't get it to forward CoT for bogus CoAs. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 11:26: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 LAA21077 for ; Fri, 29 Mar 2002 11:26: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 JAA08922; Fri, 29 Mar 2002 09:25: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 IAA27564; Fri, 29 Mar 2002 08:25: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 g2TGOQKL024316 for ; Fri, 29 Mar 2002 08:24:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TGOQDJ024315 for mobile-ip-dist; Fri, 29 Mar 2002 08:24: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 g2TGONKL024308 for ; Fri, 29 Mar 2002 08:24:23 -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 IAA09129 for ; Fri, 29 Mar 2002 08:24:26 -0800 (PST) From: Basavaraj.Patil@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 JAA03924 for ; Fri, 29 Mar 2002 09:24:24 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2TGOcv05011 for ; Fri, 29 Mar 2002 18:24:38 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 29 Mar 2002 18:24:23 +0200 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 29 Mar 2002 18:24:22 +0200 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 29 Mar 2002 10:24:20 -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] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Date: Fri, 29 Mar 2002 10:24:20 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12AE1@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] IPv6 Mobility Discussion at 3GPP2 TSG-P meeting March 11-15, 2002 Thread-Index: AcHWdEhfv0BQOWyeSLSmZpLczf8pZQAydD6A To: X-OriginalArrivalTime: 29 Mar 2002 16:24:20.0832 (UTC) FILETIME=[2E548600:01C1D73E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2TGONKL024309 Sender: owner-mobile-ip@sunroof.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 > > Tom/Parviz/Ernie, > > I don't think an IETF mailing list is the right place to pursue 3GPP2 > debates. > Could'nt agree more. Thanks for your message to the list James. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 11:46: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 LAA22077 for ; Fri, 29 Mar 2002 11:46:13 -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 JAA08638; Fri, 29 Mar 2002 09:45: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 IAA02145; Fri, 29 Mar 2002 08:45: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 g2TGiqKL024445 for ; Fri, 29 Mar 2002 08:44:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TGiqhQ024444 for mobile-ip-dist; Fri, 29 Mar 2002 08:44: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 g2TGinKL024437 for ; Fri, 29 Mar 2002 08:44:49 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25848 for ; Fri, 29 Mar 2002 08:44:52 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01912 for ; Fri, 29 Mar 2002 08:44:53 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2TGimI18774; Fri, 29 Mar 2002 08:44:48 -0800 (PST) Message-ID: <006001c1d740$d2954040$7e6015ac@T23KEMPF> From: "James Kempf" To: Cc: "'Erik Nordmark'" , "Hesham Soliman \(ERA\)" References: <4DA6EA82906FD511BE2F00508BCF053802C6ABBD@Esealnt861.al.sw.ericsson.se> <3CA3DE2E.66A9D202@iprg.nokia.com> Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 Date: Fri, 29 Mar 2002 08:43: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 Rajeev, I think security on the HI/HAck should remove the need for the CoAT. Currently, I don't think the FMIPv6 draft says anything explicit about security on HI/HAck, however. It should be made explicit. jak ----- Original Message ----- From: "Rajeev Koodli" To: Cc: "'Erik Nordmark'" ; "Hesham Soliman (ERA)" Sent: Thursday, March 28, 2002 7:23 PM Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 > > > > > > As long as this is still useful things are fine. > > > But if folks where intending to use alt-coa for cases when > > > the MN can't > > > (yet) send and/or receive on that address there is a > > > problem to combine > > > this with RR. > > > > => Agreed. The screnario that you mention where > > there could be problems (forwarding to an address > > that the MN is not in yet) is more relevant > > to the Fast Handoffs draft, which is why I think > > there needs to be some serious security work > > for that draft. > > > > [Rajeev:] If I may add to this.. In the current version of FMIPv6, > a MN binds (or attempts to bind) its current CoA-1 with a prospective > CoA-2 valid on the new access router. In other words, CoA-1 is the > temporary HoA. So, the addresses in Fast BU look as follows: > > Src-IP = CoA-1, Dst-IP = AR-1, HAO = CoA-1, alt-coa = CoA-2. > > For HoTI/HoT test: since the AR-1 is the AR forwarding packets to > CoA-1, this is somewhat simplified. In fact, ProxyRtSol can be HoTI > and ProxyRtAdv can be HoT. > > For CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using > Handover Initiate/ Ack sequence. Only when AR-1 receives such a > confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to > CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN arrives, > you cannot flood any arbitrary node but AR-2 itself. But, AR-2 > only maintains a very small buffer corresponding to proxy ND cache for > packets destined for CoA-2. > > Assuming that AR-1 and AR-2 have security association, could this > vouching by AR-2 be considered sufficient ? > > Regards, > > -Rajeev > > > > > > Hesham > > > > > > > > Erik > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 12:05: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 MAA23390 for ; Fri, 29 Mar 2002 12:05: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 KAA09638; Fri, 29 Mar 2002 10: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 JAA02719; Fri, 29 Mar 2002 09:04: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 g2TH3wKL024525 for ; Fri, 29 Mar 2002 09:03:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TH3vBX024524 for mobile-ip-dist; Fri, 29 Mar 2002 09: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TH3sKL024517 for ; Fri, 29 Mar 2002 09:03: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 JAA25658 for ; Fri, 29 Mar 2002 09:03:58 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21068 for ; Fri, 29 Mar 2002 10:03:56 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2TH3tI19323; Fri, 29 Mar 2002 09:03:55 -0800 (PST) Message-ID: <00c201c1d743$7c2896a0$7e6015ac@T23KEMPF> From: "James Kempf" To: , "Rajeev Koodli" Cc: , "'Erik Nordmark'" , "Hesham Soliman \(ERA\)" References: Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 Date: Fri, 29 Mar 2002 09:02:18 -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, I don't think there even needs to be a CoT message. The HI includes the proposed new CoA-2 within it for stateless, and the HAck includes it for stateful. If there is a signature on HI, AR-2 will know it came from a legitimate source. For stateful, AR-2 is providing the address, and a signature will allow AR-1 to know that it came from a legitmate source. One of the benefits of having real routers involved is that we can leverage off the routing security infrastructure. jak ----- Original Message ----- From: "Erik Nordmark" To: "Rajeev Koodli" Cc: ; "'Erik Nordmark'" ; "Hesham Soliman (ERA)" Sent: Friday, March 29, 2002 7:10 AM Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 > > For CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using > > Handover Initiate/ Ack sequence. Only when AR-1 receives such a > > confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to > > CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN arrives, > > you cannot flood any arbitrary node but AR-2 itself. But, AR-2 > > only maintains a very small buffer corresponding to proxy ND cache for > > packets destined for CoA-2. > > > > Assuming that AR-1 and AR-2 have security association, could this > > vouching by AR-2 be considered sufficient ? > > Rajeev, > > Since I don't know much about FMIPv6 let me try to restate an > approximation which should't add any significant new residual threats. > Assume AR-1 and AR-2 have a security association used for these messages. > > AR-1 sends something to AR-2 saying "MN coming your way - will have CoA-2 > when it arrives". > AR-2 responds with "ok, I will forward the CoT when I get it". > Then AR-2 then forwards the CoT to either AR-2 (which in turn sends > it to CoA-1) or directly to CoA-1 at which point the MN can send the BU. > > Basically AR-2 trusts AR-1, under the security association, so that > random nodes can't get it to forward CoT for bogus CoAs. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 13:10:57 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 NAA26021 for ; Fri, 29 Mar 2002 13:10:56 -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 LAA15725; Fri, 29 Mar 2002 11:10: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 KAA17871; Fri, 29 Mar 2002 10:10: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 g2TI9TKL024749 for ; Fri, 29 Mar 2002 10:09:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TI9S0P024748 for mobile-ip-dist; Fri, 29 Mar 2002 10: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 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 g2TI9OKL024741 for ; Fri, 29 Mar 2002 10:09:25 -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 g2TI9Px08522; Fri, 29 Mar 2002 19:09:26 +0100 (MET) Date: Fri, 29 Mar 2002 19:09:11 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Rajeev Koodli , "'Erik Nordmark'" , "Hesham Soliman (ERA)" In-Reply-To: "Your message with ID" <00c201c1d743$7c2896a0$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: > Erik, > > I don't think there even needs to be a CoT message. The HI includes the > proposed new CoA-2 within it for stateless, and the HAck includes it for > stateful. If there is a signature on HI, AR-2 will know it came from a > legitimate source. For stateful, AR-2 is providing the address, and a > signature will allow AR-1 to know that it came from a legitmate source. So the BU isn't going to be sent to a CN? I was assuming it would be in which case the MN would need to correct Home cookie and Care-of cookie. Erik > One of the benefits of having real routers involved is that we can > leverage off the routing security infrastructure. > > jak > > ----- Original Message ----- > From: "Erik Nordmark" > To: "Rajeev Koodli" > Cc: ; "'Erik Nordmark'" > ; "Hesham Soliman (ERA)" > > Sent: Friday, March 29, 2002 7:10 AM > Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 > > > > > For CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using > > > Handover Initiate/ Ack sequence. Only when AR-1 receives such a > > > confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to > > > CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN > arrives, > > > you cannot flood any arbitrary node but AR-2 itself. But, AR-2 > > > only maintains a very small buffer corresponding to proxy ND cache > for > > > packets destined for CoA-2. > > > > > > Assuming that AR-1 and AR-2 have security association, could this > > > vouching by AR-2 be considered sufficient ? > > > > Rajeev, > > > > Since I don't know much about FMIPv6 let me try to restate an > > approximation which should't add any significant new residual threats. > > Assume AR-1 and AR-2 have a security association used for these > messages. > > > > AR-1 sends something to AR-2 saying "MN coming your way - will have > CoA-2 > > when it arrives". > > AR-2 responds with "ok, I will forward the CoT when I get it". > > Then AR-2 then forwards the CoT to either AR-2 (which in turn sends > > it to CoA-1) or directly to CoA-1 at which point the MN can send the > BU. > > > > Basically AR-2 trusts AR-1, under the security association, so that > > random nodes can't get it to forward CoT for bogus CoAs. > > > > Erik > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 13:12: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 NAA26086 for ; Fri, 29 Mar 2002 13:12:37 -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 KAA09880; Fri, 29 Mar 2002 10:12:14 -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 KAA18428; Fri, 29 Mar 2002 10: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 g2TIBLKL024781 for ; Fri, 29 Mar 2002 10:11:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TIBLbG024780 for mobile-ip-dist; Fri, 29 Mar 2002 10:11: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 g2TIBGKL024773 for ; Fri, 29 Mar 2002 10:11:17 -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 g2TIBHx08601; Fri, 29 Mar 2002 19:11:17 +0100 (MET) Date: Fri, 29 Mar 2002 19:11:03 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Comments on Draft 16 To: Vladislav.Yasevich@compaq.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3CA39525.1F045379@compaq.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 don't think it makes much sense storing the > BU sequence number in NV memory. Since all BUs to > the home agent (home registrations) should be protected > by some kind of security (the latest specs mandates ESP), > then replay protection would be provided by ESP itself. My understanding is that ESP with manual keying can't provide replay protection. Assuming we need this replay protection I think the choices are - sequence numbers in nvram' - no manual keying - implement IKE (with at least pre-shared secrets) in all MNs and HAs But I might be missing something. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 13:36: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 NAA27293 for ; Fri, 29 Mar 2002 13:36: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 LAA26329; Fri, 29 Mar 2002 11:35:55 -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 KAA27131; Fri, 29 Mar 2002 10:35: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 g2TIZ1KL024974 for ; Fri, 29 Mar 2002 10:35:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TIZ15D024973 for mobile-ip-dist; Fri, 29 Mar 2002 10:35: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 g2TIYvKL024966 for ; Fri, 29 Mar 2002 10:34:57 -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 KAA08581 for ; Fri, 29 Mar 2002 10:34:59 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25917; Fri, 29 Mar 2002 11:34:59 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2TIYwI22342; Fri, 29 Mar 2002 10:34:58 -0800 (PST) Message-ID: <019201c1d750$342f38b0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: , "Rajeev Koodli" , "'Erik Nordmark'" , "Hesham Soliman \(ERA\)" References: Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 Date: Fri, 29 Mar 2002 10:33:21 -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 don't think there even needs to be a CoT message. The HI includes the > > proposed new CoA-2 within it for stateless, and the HAck includes it for > > stateful. If there is a signature on HI, AR-2 will know it came from a > > legitimate source. For stateful, AR-2 is providing the address, and a > > signature will allow AR-1 to know that it came from a legitmate source. > > So the BU isn't going to be sent to a CN? > I was assuming it would be in which case the MN would need to correct > Home cookie and Care-of cookie. I'm not sure I understand. The MN does need to send an F-BU to the old AR. That either happens when the MN is on the old link or on the new. What I'm saying is that I don't believe there needs to be an RR test on the new CoA because the HI/HAck exchange allows the old AR, which is serving as the on link home agent, can be strongly authenticated. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Mar 29 19:54: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 TAA08701 for ; Fri, 29 Mar 2002 19:54: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 RAA06332; Fri, 29 Mar 2002 17:53: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 QAA10703; Fri, 29 Mar 2002 16:53: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 g2U0qpKL025378 for ; Fri, 29 Mar 2002 16:52:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2U0qpXC025377 for mobile-ip-dist; Fri, 29 Mar 2002 16:52: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2U0qmKL025370 for ; Fri, 29 Mar 2002 16:52:48 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27395 for ; Fri, 29 Mar 2002 16:52:52 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27343 for ; Fri, 29 Mar 2002 16:52: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 QAA10046; Fri, 29 Mar 2002 16:52:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2U0qmn28972; Fri, 29 Mar 2002 16:52:48 -0800 X-mProtect: <200203300052> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAr8YG1; Fri, 29 Mar 2002 16:52:46 PST Message-ID: <3CA50C5F.766DC047@iprg.nokia.com> Date: Fri, 29 Mar 2002 16:52:47 -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: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6ABBD@Esealnt861.al.sw.ericsson.se> <3CA3DE2E.66A9D202@iprg.nokia.com> <006001c1d740$d2954040$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 James Kempf wrote: > Rajeev, > > I think security on the HI/HAck should remove the need for the CoAT. > I agree with you. I was trying to draw out parallels using the RR jargon (hangover:-). In short, AR-1 trusts CoA-1. AR-1 trusts CoA-2 transitively through AR-2, what I called vouching. Hence, AR-1 can bind CoA-1 to CoA-2. Perhaps Erik was thinking that MN may wish to send a BU to CN from AR-1 itself. Is that right ? This is not needed for FMIPv6, since BU transmission epoch is not time-critical. > > Currently, I don't think the FMIPv6 draft says anything explicit about > security on HI/HAck, however. It should be made explicit. Yes. Regards, -Rajeev > > > jak > > ----- Original Message ----- > From: "Rajeev Koodli" > To: > Cc: "'Erik Nordmark'" ; "Hesham Soliman > (ERA)" > Sent: Thursday, March 28, 2002 7:23 PM > Subject: Re: [mobile-ip] alt-coa - Comments on Draft 16 > > > > > > > > > As long as this is still useful things are fine. > > > > But if folks where intending to use alt-coa for cases when > > > > the MN can't > > > > (yet) send and/or receive on that address there is a > > > > problem to combine > > > > this with RR. > > > > > > => Agreed. The screnario that you mention where > > > there could be problems (forwarding to an address > > > that the MN is not in yet) is more relevant > > > to the Fast Handoffs draft, which is why I think > > > there needs to be some serious security work > > > for that draft. > > > > > > > [Rajeev:] If I may add to this.. In the current version of FMIPv6, > > a MN binds (or attempts to bind) its current CoA-1 with a prospective > > CoA-2 valid on the new access router. In other words, CoA-1 is the > > temporary HoA. So, the addresses in Fast BU look as follows: > > > > Src-IP = CoA-1, Dst-IP = AR-1, HAO = CoA-1, alt-coa = CoA-2. > > > > For HoTI/HoT test: since the AR-1 is the AR forwarding packets to > > CoA-1, this is somewhat simplified. In fact, ProxyRtSol can be HoTI > > and ProxyRtAdv can be HoT. > > > > For CoTI/CoT test: here, AR-2 may "vouch" that CoA-2 is valid using > > Handover Initiate/ Ack sequence. Only when AR-1 receives such a > > confirmation from AR-2 which it trusts, AR-1 will bind CoA-1 to > > CoA-2. Note that if AR-2 agrees to "host" CoA-2 until the MN arrives, > > you cannot flood any arbitrary node but AR-2 itself. But, AR-2 > > only maintains a very small buffer corresponding to proxy ND cache for > > packets destined for CoA-2. > > > > Assuming that AR-1 and AR-2 have security association, could this > > vouching by AR-2 be considered sufficient ? > > > > Regards, > > > > -Rajeev > > > > > > > > > > Hesham > > > > > > > > > > > Erik > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 30 12: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 MAA02234 for ; Sat, 30 Mar 2002 12:31: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 JAA11069; Sat, 30 Mar 2002 09:31:18 -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 JAA16410; Sat, 30 Mar 2002 09: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 g2UHTPKL026215 for ; Sat, 30 Mar 2002 09:29:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2UHTPCA026214 for mobile-ip-dist; Sat, 30 Mar 2002 09: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2UHTMKL026207 for ; Sat, 30 Mar 2002 09:29:22 -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 JAA05128 for ; Sat, 30 Mar 2002 09:29:26 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14015 for ; Sat, 30 Mar 2002 10:29:25 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DC83E6A909; Sat, 30 Mar 2002 19:29:23 +0200 (EET) Message-ID: <3CA5F407.7030409@piuha.net> Date: Sat, 30 Mar 2002 19:21:11 +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: "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" , Glenn Morrow Subject: Re: [mobile-ip] Comments on Draft 16 References: <4DA6EA82906FD511BE2F00508BCF053802C6ABA7@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: > Glenn Morrow brought up the issue (ipv6 list) of reverse > tunnelling to the HA when the HoA is a Site-local > address. He suggested that tunnel must be authenticated. > I don't remember if this was in the draft already, but > I think it has to be added. The draft (15) said that > the HA SHOULD tunnel Site-local (unicast and mcast) > packets to the CoA, so we can expect reverse tunnelling > to take place if the MN was communicating to another > node within the home site. I must have missed that e-mail, can someone send a copy to me? Anyway, there seems to be a few different issues: 1. Now that reverse tunneling is mandatory if there's no RO, part of the problem goes away. 2. When RO is used, a CoA is not site-local, so this isn't a problem either. 3. Authentication of the tunnel. Is there some difference in the security impacts whether or note link/site-local addresses or global addresses are used? If not, would the current text on MAY use authenticated tunnels be sufficient? Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 30 12:31: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 MAA02235 for ; Sat, 30 Mar 2002 12:31: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 KAA07005; Sat, 30 Mar 2002 10:31: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 JAA16247; Sat, 30 Mar 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 g2UHTlKL026255 for ; Sat, 30 Mar 2002 09:29:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2UHTl5N026254 for mobile-ip-dist; Sat, 30 Mar 2002 09:29: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 g2UHTaKL026239 for ; Sat, 30 Mar 2002 09:29:36 -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 JAA05157 for ; Sat, 30 Mar 2002 09:29:40 -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 KAA19220 for ; Sat, 30 Mar 2002 10:29:39 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7FDFF6A908; Sat, 30 Mar 2002 19:29:23 +0200 (EET) Message-ID: <3CA5F261.7030301@piuha.net> Date: Sat, 30 Mar 2002 19:14:09 +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: Brian Haley Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Comments on Draft 16 References: <3C9FADAA.5DDFD408@compaq.com> <3CA0DF53.10309@piuha.net> <3CA0E9C1.1D45178@compaq.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 wrote: > Ok, I understand the reason now, it's because we could be using > manually-configured > IPsec keys. But later on in that section it says you don't have to update the > nv > memory every time you get a BU, which itself could lead to a replay attack if > the HA crashes. I'm fine with a SHOULD. There are ways to update the NVM in a manner that this isn't a problem. But I'm fine with a SHOULD too. > Using multiple HAOs without an intervening tunnel is the problem, i.e. both > in the same Destination Option. How about this: The Home Address Option MUST not appear more than once in any given packet, except inside the payload part of the packet if tunneling is involved. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 30 12:31: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 MAA02259 for ; Sat, 30 Mar 2002 12:31:34 -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 KAA14473; Sat, 30 Mar 2002 10:31:16 -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 JAA16418; Sat, 30 Mar 2002 09:31: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 g2UHTjKL026252 for ; Sat, 30 Mar 2002 09:29:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2UHTjHE026251 for mobile-ip-dist; Sat, 30 Mar 2002 09:29: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 g2UHTaKL026237 for ; Sat, 30 Mar 2002 09:29:36 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15924 for ; Sat, 30 Mar 2002 09:29:40 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24038 for ; Sat, 30 Mar 2002 09:29:22 -0800 (PST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 702626A904; Sat, 30 Mar 2002 19:29:21 +0200 (EET) Message-ID: <3CA5C6F0.4010901@piuha.net> Date: Sat, 30 Mar 2002 16:08:48 +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 Cc: "'PRoberts@MEGISTO.com'" , "'Basavaraj.Patil@nokia.com'" Subject: Re: [mobile-ip] Reverse tunneling issues References: <8C92E23A3E87FB479988285F9E22BE465ABC72@ftmail> Content-Type: text/plain; charset=ISO-8859-7; 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 George Tsirtsis wrote: > GT> No problem...have a look at the draft and do not let the too many > options of how to solve the problem confuse you ...this is not complex...it > is just that it has to be dealt with. Assuming something has to be done, is this something that has to go to the base RFC, or something that can be done in an extension separately? Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 30 12:31: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 MAA02284 for ; Sat, 30 Mar 2002 12:31: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 KAA14488; Sat, 30 Mar 2002 10:31: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 JAA16348; Sat, 30 Mar 2002 09: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 g2UHTWKL026232 for ; Sat, 30 Mar 2002 09:29:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2UHTVaP026231 for mobile-ip-dist; Sat, 30 Mar 2002 09:29: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 g2UHTPKL026216 for ; Sat, 30 Mar 2002 09:29: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 JAA15896 for ; Sat, 30 Mar 2002 09:29:29 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14030 for ; Sat, 30 Mar 2002 10:29:28 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 829B86A906; Sat, 30 Mar 2002 19:29:22 +0200 (EET) Message-ID: <3CA5D5E9.1070804@piuha.net> Date: Sat, 30 Mar 2002 17:12:41 +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: George Tsirtsis Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] non-security comments to Draft-16 References: <8C92E23A3E87FB479988285F9E22BE465ABC70@ftmail> Content-Type: text/plain; charset=ISO-8859-7; 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 George Tsirtsis wrote: > 1. Reverse Tunneling > In section 9.5. "Handling Reverse Tunneled Packets from a Mobile Node" > There is a statement: > > " A home agent MUST support decapsulating reverse tunneled packets > sent to it from a mobile node's home address. " > > ...which I think it is absolutely correct although the justification that > follows is not as strong as I think the requirement is...but anyway, this is > not important. The text seems a bit outdated. How about this: 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, depending on the security policies used by the home agent. In any case, the home agent MUST check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node, as otherwise any node in the Internet could send traffic through the home agent and escape ingress filtering limitations. The support for authenticated reverse tunneling allows the home agent to protect the home network and correspondent nodes from malicious nodes masquerading as a mobile node, even if they know the current location of the real mobile node. The support for encrypted reverse tunneling allows mobile nodes to defeat certain kinds of traffic analysis. > What is important is that section 7.2. "Requirements for IPv6 > Home Agents" does not include the above....I think that if this is a MUST > then it should be listed in 7.2. How about this: Every home agent MUST support decapsulating reverse tunneled packets sent to it from a mobile node's home address. Every home agent MUST also check that the source address in the tunneled packets corresponds to the currently registered location of the mobile node. Question: is there something else missing from the list? Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Mar 30 12:31: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 MAA02296 for ; Sat, 30 Mar 2002 12:31:39 -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 JAA11055; Sat, 30 Mar 2002 09:31: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 JAA16370; Sat, 30 Mar 2002 09: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 g2UHTWKL026235 for ; Sat, 30 Mar 2002 09:29:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2UHTWUq026233 for mobile-ip-dist; Sat, 30 Mar 2002 09:29: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 g2UHTPKL026217 for ; Sat, 30 Mar 2002 09:29: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 JAA15898 for ; Sat, 30 Mar 2002 09:29:29 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14031 for ; Sat, 30 Mar 2002 10:29:29 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 059D16A907; Sat, 30 Mar 2002 19:29:23 +0200 (EET) Message-ID: <3CA5DEF9.1070100@piuha.net> Date: Sat, 30 Mar 2002 17:51:21 +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: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com, erik.nordmark@sun.com Subject: Re: [mobile-ip] Comments on Draft 16 References: <200203282056.g2SKui7p178328@jurassic.eng.sun.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 Samita Chakrabarti wrote: > Vijay's description below clears concept for MN behavior in case it reboots. > As per Vijay's description on draft15, HA can accept BUs with any seq# after HA > reboots as it does not keep the state upon reboot. Right, I believe what Vijay described does have a small vulnerability in that after a reboot replays are possible. > Although, it adds extra replay protection at HA, I'd think, the > home-agent usage of NV memory could be optional. I'd like to know > how big is the threat in this particular case (i,e if HA reboots). > If we somehow decide that HA should preserve the bindings accross reboot, > then obviously, it makes sense to have all the information intact. Yes. Why don't we use the -15 scheme, describe the remaining threat and make the seqno-preservation through reboots a SHOULD (or a MAY). > Also this section mentions "The mobile node and homeagent MAY on a new key > for the security association before this many (2**31) BU have been sent if > this is an issue". > I wonder if we leave it as MAY, then there might be some interoperability issues > as MN and HA may have different expectations. I don't think so. There has to be a key management scheme to change the key, and I can only think of two: IKE and a manual change. In either case it will be apparent if the other side does not support this activity. For instance, if manual keying is used then the administrator either gets hold of the mobile node's owner and asks him to change the key, or he doesn't ;-) But perhaps we should clarify in the draft that the mobile IP protocol as such will not start complaining about too old keys. So, as far as mobile IP concerned this wrapping over is ok, and does not result in any error codes. > 1. section 4.5.5, please clarify in words how the Correspondent node > secret key Kcn would be used. There is an example of MAC_Kcn in COT > message processing, but that is not very clear. This key is used by the correspondent node to accept only the use of cookies which it has created itself. Adding some text... > 2. In HOTI and COTI messages we use "nonce" index. What is "nonce" index? > Is it a random number ? IBM has IPR on nonces, how different or same > is this nonce index from IBM's nonces ? It is just an efficient way to find the right nonce. Adding some text.. As for the IPRs, please tell me more! Do you have a pointer to IBM's claim? > 3. section 5.1.8 refers to "refresh" field. After last Connectathon and > the followup discussion at IETF, I think we have decided to remove > the "refresh" field as default and make it optional --correct ? Jari