From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 2 06:04: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 GAA02274 for ; Wed, 2 Jan 2002 06:04: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 DAA12816; Wed, 2 Jan 2002 03:03: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 DAA12940; Wed, 2 Jan 2002 03:03:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02B2qZR027182 for ; Wed, 2 Jan 2002 03:02:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02B2qkd027181 for mobile-ip-dist; Wed, 2 Jan 2002 03:02: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.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02B2nZR027174 for ; Wed, 2 Jan 2002 03:02:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09804 for ; Wed, 2 Jan 2002 03:02:51 -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 DAA01701 for ; Wed, 2 Jan 2002 03:02:46 -0800 (PST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 49DFDA; Wed, 2 Jan 2002 13:03:12 +0200 (EET) Message-ID: <3C32E8C8.5000208@nomadiclab.com> Date: Wed, 02 Jan 2002 13:02:32 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko , Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] list of things for MIPv6 References: <200112241438.fBOEcWD04946@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, [I am catching old e-mail; the to/cc didn't include me so I didn't notice this before now.] Francis Dupont wrote: > Well, to me this seems to depend on how the CoAs are > assigned. If the MN is allowed to use stateless autoconfiguration, > it can generate a few thousand different CoAs for itself, > and use each CoA separately to send different home addresses > in the Home Address Option. > > => this behavior is so different than standard MN's one that > the ingress filtering should block it. How can ingress filtering notice that so that it could block it? That is, how can it differentiate between one host generating 200 different CoAs and using them and having 200 different hosts in the network? Of course this depends on the link layer, but given a suitable link layer (e.g. Ethernet), you cannot make the difference. (For Ethernet you need MAC spoofing, but that is easy.) --Pekka From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 2 12:36:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07648 for ; Wed, 2 Jan 2002 12:36:00 -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 KAA01592; Wed, 2 Jan 2002 10:34: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 JAA15951; Wed, 2 Jan 2002 09:35:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02HYLZR027872 for ; Wed, 2 Jan 2002 09:34:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02HYLPe027871 for mobile-ip-dist; Wed, 2 Jan 2002 09:34:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02HYIZR027864 for ; Wed, 2 Jan 2002 09:34:18 -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 JAA15651 for ; Wed, 2 Jan 2002 09:34:21 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25545 for ; Wed, 2 Jan 2002 09:34:20 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA14157 for ; Wed, 2 Jan 2002 10:34:20 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA27925 for ; Wed, 2 Jan 2002 10:34:19 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 2 Jan 2002 11:34:19 -0600 Message-ID: <215C954ACE13D4119B9400D0B73E9AB9047106D2@il02exm22.comm.mot.com> From: Bekiares Tyrone-CTB041 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIPv4: can a foreign agent broadcast an ARP request for the home address of a mobile node? Date: Wed, 2 Jan 2002 11:34:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I've been reading over the MIPv4 RFC-2002 and the updated Internet Draft in greater detail, and it appears to be somewhat ambigious as to whether or not a foreign agent can broadcast an ARP request for the home address of a mobile node. Page 59 of the updated Internet Draft "IP Mobility Support for IPv4, revised" states that "A Foreign agent MUST NOT use broadcast ARP for a mobile node's MAC address on a foreign network." Yet on page 66 of the same draft, it reads "Finally, while the mobile node is away from home, it MUST NOT reply to ARP Requests in which the target IP address is its own home address, **** unless the ARP Request is unicast by a foreign agent with which the mobile node is attempting to register or a foreign agent with which the mobile node has an unexpired registration ****" That last bit seems to imply the use of a unicast ARP request mechanism, which dosen't make any sense to me (anyone?). The original RFC basically has the same verbiage, but leaves out the word "unicast"... Why would the FA ever need to do an ARP request for the the mobile node's home address? Shouldn't it update its ARP cache based on the MIPv4 Registration Request (discussed on page 59 of the Internet Draft)? Thanks! + Tyrone Bekiares - Advanced Technology, Motorola From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 2 17:31:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12251 for ; Wed, 2 Jan 2002 17:31: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 PAA28367; Wed, 2 Jan 2002 15:30:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15567; Wed, 2 Jan 2002 14:30:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02MTUZR028763 for ; Wed, 2 Jan 2002 14:29:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g02MTUYQ028762 for mobile-ip-dist; Wed, 2 Jan 2002 14:29:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g02MTRZR028755 for ; Wed, 2 Jan 2002 14:29:27 -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 OAA15217 for ; Wed, 2 Jan 2002 14:29:27 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00849 for ; Wed, 2 Jan 2002 14:29:22 -0800 (PST) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KCMOE25FT28WXQW2@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Thu, 3 Jan 2002 09:29:19 +1100 Received: from localhost (localhost [127.0.0.1]) by thwack.its.monash.edu.au (Postfix) with ESMTP id D54FD12C009; Thu, 03 Jan 2002 09:29:18 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189]) by thwack.its.monash.edu.au (Postfix) with ESMTP id E1E1012C008; Thu, 03 Jan 2002 09:29:17 +1100 (EST) Date: Thu, 03 Jan 2002 09:32:27 +1100 From: Greg Daley Subject: Re: [mobile-ip] HMIPv6 test To: mobile-ip@sunroof.eng.sun.com Cc: Lajos.Zaccomer@eth.ericsson.se, akos.cserveni@eth.ericsson.se Message-id: <3C338A7B.3DE9647F@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en References: <4DA6EA82906FD511BE2F00508BCF053801C4C17B@Esealnt861.al.sw.ericsson.se> <003b01c18a79$cf157390$df0589c1@loliveira> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8BIT Luís Miguel Oliveira wrote: > > Hi, > > Anyone have some details about this tests? Hi Luis, I've just returned from christmas/summer break so I do not have any breakdowns of the testing. I'll try to define the areas, and maybe Lajos or Akos can flesh out details. the testing was divided into Interop and Conformance testing. Conformance testing was performed with the Ericsson Hungary testing suite, which has a lot of control over test cases. Primarily the testing was aimed at HMIPv6-draft4, but some reliances on the underlying MIPV6 stack were tested. Mobile node and MAP roles were tested for conformance to the basic mode of operation. As far as I know, neither implementation has Extended Mode to a testable state. As far as I can tell, tests for all the MUSTs in the draft (which apply to basic mode) have been provided as well as some common sense cases (which were not all passed... :) Interop testing was conducted between the Ericsson and the AT-CRC implementations, and work focussed on working the Ericsson MAP implementation with the Mobile node from AT-CRC. Some initial assumptions on the AT-CRC implementation had been revealed by the conformance testing, which previously had been confusing in the first attempt of interop testing. After correcting these, mobile node registrations were performed with map and a MIPv6-14 ha, and data was received from a MIPv6-14 correspondent node. Intra mobility domain movement was performed, and instrumented. Some of the test results are still to be analysed by our team because of the christmas holiday interruption. Greg From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 04:34: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 EAA28243 for ; Thu, 3 Jan 2002 04:34:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26033; Thu, 3 Jan 2002 02:33:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11224; Thu, 3 Jan 2002 01:33:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g039WFZR029388 for ; Thu, 3 Jan 2002 01:32:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g039WFc9029387 for mobile-ip-dist; Thu, 3 Jan 2002 01: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g039W8ZR029372; Thu, 3 Jan 2002 01:32:09 -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 BAA10921; Thu, 3 Jan 2002 01:32:13 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19505; Thu, 3 Jan 2002 02:32:12 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 5B459A; Thu, 3 Jan 2002 11:32:41 +0200 (EET) Message-ID: <3C342515.10904@nomadiclab.com> Date: Thu, 03 Jan 2002 11:32:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, or AAA at all. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 05:57: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 FAA28895 for ; Thu, 3 Jan 2002 05:57:50 -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 DAA01311; Thu, 3 Jan 2002 03:56: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 CAA29515; Thu, 3 Jan 2002 02:57:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03AuLZR029580 for ; Thu, 3 Jan 2002 02:56:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03AuLtX029579 for mobile-ip-dist; Thu, 3 Jan 2002 02:56:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03AuIZR029572 for ; Thu, 3 Jan 2002 02:56:18 -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 CAA17620 for ; Thu, 3 Jan 2002 02:56:18 -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 DAA21442 for ; Thu, 3 Jan 2002 03:57:12 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 33DAEA; Thu, 3 Jan 2002 12:56:43 +0200 (EET) Message-ID: <3C3438BF.5010304@nomadiclab.com> Date: Thu, 03 Jan 2002 12:55:59 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: msa@burp.tkv.asdf.org Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200112271252.OAA20990@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Markku Savela wrote: > I may have missed some discussion due to high volume on this topic, > but I like to inject one scenario of Home Address option use... > > If MN and CN have IPSEC session between them, then I > suppose HAO within such session is safe. (I leave it open for now, > whether the session should be between care of addresses or home > addresses of MN and CN, but either should work?). Well, that depends on _how_ exactly you have created the IPSEC session, and, as a consequence, how much you trust the MN. If you use something like opportunistic IPSEC (see http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/draft-richardson-ipsec-opportunistic-04-change.txt) you certainly CANNOT trust the HAO any more than without IPSEC. On the other hand, if you have a closed user group with strong internal trust relationships, you may decide to trust the HAO without any explicit authorization. However, in the general case, when you create the IPSEC SA, you have to check that the MN is _authorized_ to use the Home Address. Only that makes it secure to trust on the HAO. As a side note, the CGA and RR methods are means to check an MN's authority to use a Home Address. Basically, RR relies on the assumption that if a host can answer to messages sent to an address, it is authorized to use that address. CGA, on the other hand, relies on that if a host possesses a private key that corresponds to the host ID part of an IPv6 address, it is assumed to be authorized to use that address. Neither is perfectly secure, but both are much better than nothing. (Well, what do I mean with "much better". In the RR case, much better means that the number of hosts able to foil the RR check is much smaller than the number of hosts in the Internet. In the CGA case, creating a private key that corresponds to a given IPv6 interface ID requires so large amounts of computational capasity that few attackers are likely willing to spend that much of resources.) --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 09:19: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 JAA01810 for ; Thu, 3 Jan 2002 09:19: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 HAA21697; Thu, 3 Jan 2002 07:18: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 GAA22897; Thu, 3 Jan 2002 06:19:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03EIKZR029842 for ; Thu, 3 Jan 2002 06:18:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03EIKUG029841 for mobile-ip-dist; Thu, 3 Jan 2002 06:18: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03EIHZR029834 for ; Thu, 3 Jan 2002 06:18:17 -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 GAA22778 for ; Thu, 3 Jan 2002 06:18:22 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17922 for ; Thu, 3 Jan 2002 06:18:21 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g03EIKJ06828 for ; Thu, 3 Jan 2002 15:18:20 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jan 03 15:18:14 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 15:09:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C18D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Charlie Perkins Subject: RE: [mobile-ip] list of things for MIPv6 Date: Thu, 3 Jan 2002 15:17: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: Francis, > Furthermore, I will claim that I am usually pretty aware of the > distinction between mobility and wireless, but hey > nobody's perfect. > > => you should recognize piggy-backing is less useful on an Ethernet > or a 802.11b/802.11a. I consider piggy-backing as an > over-optimization > (as RSVP in fact) in most cases, i.e. this really makes sense with > some link-layers which are very hard (i.e. too expensive) to improve > (this is the case of mobile phone in Europe, nobody wants to buy > a second license in some countries just to get more bandwidth :-). > => It actually does NOT make any sense for the expensive, hard ..etc link layers. I've already explained why before and expressed it again when discussing this with Cedric. I'm assuming of course that you're referring to cellular links. So the question is, where does this optimisation make sense ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 09:34: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 JAA02119 for ; Thu, 3 Jan 2002 09:34: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 GAA19856; Thu, 3 Jan 2002 06:33: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 GAA24884; Thu, 3 Jan 2002 06:33:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03EUEZR029977 for ; Thu, 3 Jan 2002 06:30:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03EUE1E029976 for mobile-ip-dist; Thu, 3 Jan 2002 06:30:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03EUAZR029969 for ; Thu, 3 Jan 2002 06:30:11 -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 GAA07089 for ; Thu, 3 Jan 2002 06:30:16 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27166 for ; Thu, 3 Jan 2002 07:31:17 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g03EUDJ18589 for ; Thu, 3 Jan 2002 15:30:13 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jan 03 15:30:13 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 15:30:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C18E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Is RR only enough ? Date: Thu, 3 Jan 2002 15:29:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-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 can't see how we can do RR only and still maintain > > that our requirement is "Add no harm". Connection > > hijacking can be considered "new harm" and RR will > > not stop it. IMHO (and I'm not a security expert) > > the combination of CGAs and RR is an excellent idea > > and will give quite a strong security. > > Any node on the path between two communicating entities today can be > MiTM for TCP connections and UDP "flows". If IPsec/TLS/etc > is not used those > MiTM can modify the content of the communication; otherwise they can > just cause a DoS by dropping packets (or modifying them and > having the > receipient drop then due to authentication failure). > > Adding MIPv6 a BU protected by RR doesn't seem to make this > any worse. > What am I missing? > => Probably nothing, but consider this scenario and see if it is possible: A MiTM is performing an active attack by sending a BU to the CN to direct the MN's traffic to itself. Now this Bad Guy happens to be on the path between the CN and the HA. In this case, if RR (only) is used, Bad Guy will be able to steal all the MN connections with the CN, and her can keep refreshing the BU to disallow future communication with that particular Home address. However, if RR, combined with CGAs is used, this can not happen (well, or it becomes as hard as it is to generate a duplicate CGA). As far as I can see this situation is an 'addition of harm' compared to today's Internet, and is due to the BU. That's why I think RR and CGA are a good combination. Have I missed something ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 10:16: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 KAA03630 for ; Thu, 3 Jan 2002 10:16: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 IAA23805; Thu, 3 Jan 2002 08:15: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 HAA17182; Thu, 3 Jan 2002 07:16:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03FFGZR000208 for ; Thu, 3 Jan 2002 07:15:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03FFGJv000206 for mobile-ip-dist; Thu, 3 Jan 2002 07:15: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.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03FFDZR000199 for ; Thu, 3 Jan 2002 07:15:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17062 for ; Thu, 3 Jan 2002 07:15:17 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23311 for ; Thu, 3 Jan 2002 08:15:16 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g03FFFJ25800 for ; Thu, 3 Jan 2002 16:15:15 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jan 03 16:14:59 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 16:06:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C192@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] list of things for MIPv6 Date: Thu, 3 Jan 2002 16:14:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, December 21, 2001 10:12 PM > To: Jari Arkko > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] list of things for MIPv6 > > > Jari Arkko wrote: > > > I believe there is a real difference in current spoofing > > attacks compared to the ones enabled by the home > > address option. Namely, ingress filtering or other techniques > > can prevent source address spoofing but I can't see how > > they could prevent HAO spoofing. > > Ingress filtering could put some restriction on this. > For instance, it could be enforced that only one home > address could be associated to a particular care-of address. > This would eliminate most of the "fun" that would be > associated with such spoofing. We could also say that > a correspondent node has to do such filtering. After > these two measures are taken, I think that no self-respecting > bad guy would waste time on such a low-payoff exploit. > Hello Charlie, > Supposing we had a new header type. Wouldn't it be > appropriate to make the necessary signaling for protecting > Binding Updates to also fit in the same container? => Absolutely. In fact it is as simple as taking the exact same ext header and giving it a new name/Header Type. I think the biggest amount of work will be done by IANA :) But I think Francis already said that. Regarding your response on RR and CGAs please see the separate thread containing my response to Erik and respond to that if you like. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 12:27: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 MAA06465 for ; Thu, 3 Jan 2002 12:27:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02667; Thu, 3 Jan 2002 09:26:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22239; Thu, 3 Jan 2002 09:26:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HPqZR000712 for ; Thu, 3 Jan 2002 09:25:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id g03HPqlT000711 for mobile-ip-dist; Thu, 3 Jan 2002 09:25: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.Beta3+Sun/8.12.2.Beta3) with ESMTP id g03HPnZR000704 for ; Thu, 3 Jan 2002 09:25:49 -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 JAA22944 for ; Thu, 3 Jan 2002 09:25:54 -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 KAA28285 for ; Thu, 3 Jan 2002 10:25:53 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03HPpv01531 for ; Thu, 3 Jan 2002 11:25:52 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 11:24:20 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E014CC504@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Thu, 3 Jan 2002 11:24:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1947B.8B9DAFE0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1947B.8B9DAFE0 Content-Type: text/plain; charset="iso-8859-1" Jari, There was a long offline argument about how a router would definitely know that it was the first hop router. I.e. how would it know to turn on the checks or not without configuration. The point was brought up about assymetric routing where outbound traffic goes through a set of egress routers and inbound comes in on ingress routers. The point was made that the outbound routers would likely not have a FIB flag set in cache indicating that node was a first hop. So it seems that in order to turn on some kind of check on the 1st hop automatically, we would need to find some other standardized means of turning the checks on. I think that if MAC anti-spoofing was mandated then the solution to mandate the filtering would be mute; however, the problem set is essentially the same in that you would still have to find a way to have the router detect automatigically that the anti-spoofing checks were needed - sort of a zeroconf solution. We could have the routers monitor the autoconfiguration messages and perhaps the DHCP messages or we could rely on an all routers multicast message to handle the situation with assymetric routes. This would be automagic yet I still suspect someone will complain about subnet bandwidth being used up with a new message, etc.. Even if such a thing were agreed we will get into the arguments about core routers also having hosts attached to them. Someone will likely take the stance that I don't want these core routers being bogged down; however, configuration via either subneting or simple configurable overrides would likely quell these arguments as well. This would certainly change the thinking from one of you have to configure the router to enable the filtering to that of you have to configure the router to disable the filtering. Anyway these were my thoughts about this. Thanks for bringing it up. I am hopeful that something could be done and agreed on this matter with IPv6 and perhaps even IPv4 for newer implementations or releases. Most of the core routers are configured in some fashion anyway. Thanks, Glenn > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, December 26, 2001 1:39 PM > To: Francis Dupont; ipng@sunroof.eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Re: IPv6 ingress filtering early access > > > > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-i > ngress-filtering-00.txt > > Nice draft, thanks for taking the time to write down the problems and > their alternative solutions. Hope you still had time for Christmas ;-) > > I have a few comments. > > First, it seems that the main alternatives we have is (a) > restrict MIPv6 > functionality by removing intermediate alternatives between > bidirectional > tunneling and route optimisation, or (b) deploy AAA to help > visited networks > figure out what are legal home addresses. > > It is interesting to note the different actors in these two > alternatives. In the > first alternative, it is the CN who is taking the > responsibility, and requiring > no help whatsoever from the firewalls in between. In the > second alternative, > we put all the trust on the firewalls/routers of sites, and > none of the CNs do > any worrying over this anymore. Both solutions work if > applied allover, and > the second solution allows the current MIPv6 flexibility, > being therefore the > preferred solution if seen feasible. > > However, I'm concerned about the "applied allover" part. > Specifically - while > I'm very much fond of the AAA solutions - I'm concerned > whether we can expect > all parts of the Internet to have an infrastructure that > really can figure out the > home addresses. What if there's a coin-operated (or Visa-) > airport WLAN? > With no connection to a global roaming association of who > owns what addresses. > What kind of filtering should that do? Prohibit everything > else expect bidirectional > tunneling, or allow home addresses to be used? If latter, > then the trusting > CNs don't have a clue that they could be used as reflectors... > > Finally, I seem to remember there was a discussion a long > time ago whether > we could somehow provide automatic, mandatory, ingress > filtering in IPv6. > If such a feature were possible, it would really make setting > up networks easier > and denial of service attacks easier to trace. Do you think > this would be > feasible? If yes, perhaps it should also be discussed in the > draft. Currently, > we are headed towards the same situation as in IPv4 where > ingress filtering > is only partially applied, and we keep coming up with "patch" > solutions such > as I-trace to help the situation. Interestingly, these > solutions typically need > changes to a large fraction of the routers in the Internet > which we already are > doing anyway to move to IPv6... > > Jari > > > > ------_=_NextPart_001_01C1947B.8B9DAFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: IPv6 ingress filtering early access

Jari,

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

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

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

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

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

Thanks,

Glenn

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

------_=_NextPart_001_01C1947B.8B9DAFE0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 16:10:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11352 for ; Thu, 3 Jan 2002 16:10:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19450; Thu, 3 Jan 2002 14:08:58 -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 NAA23109; Thu, 3 Jan 2002 13:09:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03L8ClJ001622 for ; Thu, 3 Jan 2002 13:08:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g03L8C0K001621 for mobile-ip-dist; Thu, 3 Jan 2002 13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g03L89lJ001614 for ; Thu, 3 Jan 2002 13:08:09 -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 NAA28107 for ; Thu, 3 Jan 2002 13:08:14 -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 OAA00467 for ; Thu, 3 Jan 2002 14:08:14 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g03L8Dq10315; Thu, 3 Jan 2002 13:08:14 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP47258; Thu, 3 Jan 2002 13:07:40 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA11334; Thu, 3 Jan 2002 13:08:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.51261.418122.958215@thomasm-u1.cisco.com> Date: Thu, 3 Jan 2002 13:08:13 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: "'Erik Nordmark'" , "Hesham Soliman (ERA)" Subject: [mobile-ip] Is RR only enough ? In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C18E@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053801C4C18E@Esealnt861.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, I thought we agreed that an man in the middle which would need to be part of the network (switch/router) was something we could ignore. As in, if that happens, BU hijacking is just one of a nearly infinite number of attacks you could mount -- most of which have nothing to do with MIP. Now, if you can show an attack by an end host in the CN's, MN's or anybody else's network which can be mounted without requiring a compromised router/switch I'll be the first one to change my mind on this. One condition here though: if the access router/switch can defeat the attack, and it's localized to an attack on its networks (eg another CN on the same network segment), it's not unreasonable to expect that that be part of the entire RR solution, IMO. Mike Hesham Soliman (ERA) writes: > => Probably nothing, but consider this scenario and see > if it is possible: > A MiTM is performing an active attack by sending a BU to > the CN to direct the MN's traffic to itself. > Now this Bad Guy happens to be on the path between the > CN and the HA. In this case, if RR (only) is used, > Bad Guy will be able to steal all the MN connections > with the CN, and her can keep refreshing the BU to disallow > future communication with that particular Home address. > However, if RR, combined with CGAs is used, this can not > happen (well, or it becomes as hard as it is to generate > a duplicate CGA). > As far as I can see this situation is an 'addition of harm' > compared to today's Internet, and is due to the BU. > That's why I think RR and CGA are a good combination. > > Have I missed something ? > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 21:56:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16540 for ; Thu, 3 Jan 2002 21:56:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11725; Thu, 3 Jan 2002 19:55: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 SAA13086; Thu, 3 Jan 2002 18:55:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g042sJNg002138 for ; Thu, 3 Jan 2002 18:54:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g042sJRu002137 for mobile-ip-dist; Thu, 3 Jan 2002 18:54:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g042sFNg002130 for ; Thu, 3 Jan 2002 18:54:16 -0800 (PST) Received: from lillen (hobo174.EBay.Sun.COM [129.150.99.71]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g042s8306216; Fri, 4 Jan 2002 03:54:09 +0100 (MET) Date: Fri, 4 Jan 2002 03:51:34 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Re: Is RR only enough ? To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C18E@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => Probably nothing, but consider this scenario and see > if it is possible: > A MiTM is performing an active attack by sending a BU to > the CN to direct the MN's traffic to itself. > Now this Bad Guy happens to be on the path between the > CN and the HA. In this case, if RR (only) is used, > Bad Guy will be able to steal all the MN connections > with the CN, and her can keep refreshing the BU to disallow > future communication with that particular Home address. Yes this is a possible attack. But you seem to be implicitly claiming that this is worse than today's IPv4 network with an attacker on the path between the communicating nodes. That is the argument I don't understand i.e. why is this any more harmful than the MiTM attacking every TCP connection and UDP "session"? The MiTM is on the path between the communicating nodes. > However, if RR, combined with CGAs is used, this can not > happen (well, or it becomes as hard as it is to generate > a duplicate CGA). I fully agree that RR+CGA doesn't have this problem thus it is more secure. > As far as I can see this situation is an 'addition of harm' > compared to today's Internet, and is due to the BU. So why is it worse? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 3 22:08: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 WAA16817 for ; Thu, 3 Jan 2002 22:08:41 -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 TAA16712; Thu, 3 Jan 2002 19:07:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14503; Thu, 3 Jan 2002 19:07:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0436tNg002264 for ; Thu, 3 Jan 2002 19:06:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0436sNd002263 for mobile-ip-dist; Thu, 3 Jan 2002 19:06:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0436oNg002256 for ; Thu, 3 Jan 2002 19:06:51 -0800 (PST) Received: from lillen (hobo174.EBay.Sun.COM [129.150.99.71]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0436m307059; Fri, 4 Jan 2002 04:06:49 +0100 (MET) Date: Fri, 4 Jan 2002 04:04:14 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Is RR only enough ? To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, "'Erik Nordmark'" , "Hesham Soliman (ERA)" In-Reply-To: "Your message with ID" <15412.51261.418122.958215@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I thought we agreed that an man in the middle > which would need to be part of the network > (switch/router) was something we could ignore. As > in, if that happens, BU hijacking is just one of a > nearly infinite number of attacks you could mount > -- most of which have nothing to do with MIP. > > Now, if you can show an attack by an end host in > the CN's, MN's or anybody else's network which can > be mounted without requiring a compromised > router/switch I'll be the first one to change my > mind on this. One condition here though: if the > access router/switch can defeat the attack, and > it's localized to an attack on its networks (eg > another CN on the same network segment), it's not > unreasonable to expect that that be part of the > entire RR solution, IMO. Mike, An attacker (e.g. a host) on a multi-access link next to the CN, HA, or MN can lauch successful attacks against RR in general. (BU3WAY shows a scheme for preventing attacks on the link attached to the MN and the rest of the path between the MN and HA.) This does require that the multi-access link allows anybody to receive packets (e.g. non-switched Ethernets or 802.11) or using ND/ARP spoofing to become a MiTM on those links. But this isn't any worse than IPv4 today either - any host attached e.g. to a non-switched Ethernet next either of two communicating nodes can use ARP spoofing and/or snooping packets to become a MiTM for TCP connections and UDP "sessions". Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 10:39:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05886 for ; Fri, 4 Jan 2002 10:39:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20772; Fri, 4 Jan 2002 08:38: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 HAA08812; Fri, 4 Jan 2002 07:38:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FbiNg002965 for ; Fri, 4 Jan 2002 07:37:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04FbimH002964 for mobile-ip-dist; Fri, 4 Jan 2002 07:37: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FbfNg002957; Fri, 4 Jan 2002 07:37:41 -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 HAA29503; Fri, 4 Jan 2002 07:37:44 -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 IAA25751; Fri, 4 Jan 2002 08:38:47 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04Fbdb12345; Fri, 4 Jan 2002 16:37:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA03449; Fri, 4 Jan 2002 16:37:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g04FbdQ03170; Fri, 4 Jan 2002 16:37:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Wed, 26 Dec 2001 21:38:53 +0200. <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> Date: Fri, 04 Jan 2002 16:37:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: However, I'm concerned about the "applied allover" part. Specifically - while I'm very much fond of the AAA solutions - I'm concerned whether we can expect all parts of the Internet to have an infrastructure that really can figure out the home addresses. What if there's a coin-operated (or Visa-) airport WLAN? => this is a problem of trust in the local/visited domain *and* in the remote/home domain. In your example if I understand the issue is the lack of trust in the local/visited domain, so one may reject traffic with home address options from it. Finally, I seem to remember there was a discussion a long time ago whether we could somehow provide automatic, mandatory, ingress filtering in IPv6. => my concern is that the "mandatory" term in a RFC is not enough to enforce it in the real world. Currently, we are headed towards the same situation as in IPv4 where ingress filtering is only partially applied, and we keep coming up with "patch" solutions such as I-trace to help the situation. => ingress filtering has more problems with IPv4, mainly because it was not considered from the beginning. But it is already a BCP and it seems that most ISPs use it (feedback from ISPs please). Interestingly, these solutions typically need changes to a large fraction of the routers in the Internet which we already are doing anyway to move to IPv6... => we can expect to avoid the same errors with IPv6. Unfortunately ingress filtering (like network management) is something where IPv6 is not yet at the same level than for IPv4 today. We hope this situation will be improved very fast. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 10:59: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 KAA06779 for ; Fri, 4 Jan 2002 10:58:57 -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 IAA01936; Fri, 4 Jan 2002 08: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 HAA11274; Fri, 4 Jan 2002 07:58:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FvJNg003144 for ; Fri, 4 Jan 2002 07:57:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04FvJ7I003143 for mobile-ip-dist; Fri, 4 Jan 2002 07:57:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04FvCNg003128; Fri, 4 Jan 2002 07:57:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11153; Fri, 4 Jan 2002 07:57:17 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01410; Fri, 4 Jan 2002 08:56:57 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g04FvEU25373; Fri, 4 Jan 2002 17:57:14 +0200 Date: Fri, 4 Jan 2002 17:57:13 +0200 (EET) From: Pekka Savola To: cc: Jari Arkko , Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, 4 Jan 2002, Francis Dupont wrote: > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). Feedback you get here does *not* reflect to the real world -- those who work around here, are usually even a little conscientious. The problem is the ignorant and the uncaring. FWIW, we provide connectivity for every university and the like in Finland, and they're all ingress-filtered at ISP-organization border. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 11:15: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 LAA07355 for ; Fri, 4 Jan 2002 11:15:01 -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 IAA21100; Fri, 4 Jan 2002 08:13:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13911; Fri, 4 Jan 2002 08:13:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GCiNg003308 for ; Fri, 4 Jan 2002 08:12:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04GCiJc003307 for mobile-ip-dist; Fri, 4 Jan 2002 08:12:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GCfNg003300; Fri, 4 Jan 2002 08:12:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27700; Fri, 4 Jan 2002 08:12:45 -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 JAA11029; Fri, 4 Jan 2002 09:12:26 -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 g04GCab14846; Fri, 4 Jan 2002 17:12: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 RAA04118; Fri, 4 Jan 2002 17:12: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 g04GCaQ03314; Fri, 4 Jan 2002 17:12:36 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041612.g04GCaQ03314@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 27 Dec 2001 14:38:10 +0200. Date: Fri, 04 Jan 2002 17:12:36 +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: About section 2 on Correspondent Nodes; could you elaborate in the document why exactly solution is too drastic? => because this gives no choice between bidirectional tunnel and route optimization, so in some cases mobile IPv6 becomes far less attractive. The real impact depends on how mobile IPv6 is used, in fact one can argue that bidirectional tunnels are enough, but I don't believe that mobile-ip list members will agree... Note that BCE check is not the only way to ensure legitimity of HAO: if it's secured by AH, it's ok; if some SUCV/.. weak authentication method is used, it's probably also ok; the same might even apply to return routability. It's too early to crush CN solutions. => these CN solutions have the same cost than full routing optimization, so I consider them as BCE check variants. (I think the solution for HAO should most likely consist of two separate, "strong-enough" layers, one mandated at CN, one possible at firewalls, but that's not the topic of this draft). => one mandated at CN == no third choice. Note: it seems every site, even if it had only a few MN's, will have to have AAA infrastructure, so that it could interact, certify etc. home address use for remote AAA systems when MN goes roaming and there's a need to punch a hole in ingress filtering of remote sites. => I don't know if the "remote sites" are home sites (sites with home agents) or correspondent sites (sites with correspondent nodes). In the last case the only issue is the iDDoS because both care-of and home addresses are external. In the first case one can rely on home registrations (which have to be strongly secured) in order to understand what happens (and what HAO are valid), in fact this is just remote network access control (in AAA terms this can be done directly (IKE with certificate for instance) or (better because simpler) using the local/visited AAA system as a mediator, note the issue is for first home registrations because they have to create security contexts). (If this is the approach for security, it should be required in the main MIPv6 draft). => I disagree, the iDDoS security threat is not a major one because ingress filtering is not really mandatory. The purpose of my draft is not to fill the hole, it is to get back the previous (i.e. before HAO) situation. Or have I missed something? This seems unnecessary in many environments, e.g. university campus area WLAN or company's internal network. => this depends on where are the visited, home and correspondent domains. For an university campus area WLAN home agents are in campus area too so a bidirectional tunnel with a good local security seems enough (i.e. visited domain = home domain with home agents in the path between MNs and CNs). In a company internal network all three domains are the same so there is no security problems as soon as basic security (i.e. no physical intruders) is enforced. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 11:40:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08002 for ; Fri, 4 Jan 2002 11:40:40 -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 JAA28840; Fri, 4 Jan 2002 09:38: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 IAA08816; Fri, 4 Jan 2002 08:23:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GMQNg003418 for ; Fri, 4 Jan 2002 08:22:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04GMQD1003417 for mobile-ip-dist; Fri, 4 Jan 2002 08:22:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GMMNg003410 for ; Fri, 4 Jan 2002 08:22:22 -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 IAA08748 for ; Fri, 4 Jan 2002 08:22:27 -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 JAA14718 for ; Fri, 4 Jan 2002 09:22:22 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04GMKb15737 for ; Fri, 4 Jan 2002 17:22:20 +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 RAA04297 for ; Fri, 4 Jan 2002 17:22:20 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g04GMKQ03361 for ; Fri, 4 Jan 2002 17:22:20 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041622.g04GMKQ03361@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 27 Dec 2001 14:52:32 +0200. <200112271252.OAA20990@burp.tkv.asdf.org> Date: Fri, 04 Jan 2002 17:22:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-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 may have missed some discussion due to high volume on this topic, but I like to inject one scenario of Home Address option use... If MN and CN have IPSEC session between them, then I suppose HAO within such session is safe. => this depends on what is an IPsec session (AH makes HAO safe, more details are needed for other cases). (I leave it open for now, whether the session should be between care of addresses or home addresses of MN and CN, but either should work?). => if the IPsec SA is with a care-of address it has to be rebuilt after each movement. But the ISAKMP SA can be with the care-of or the home address (i.e. IKE session can use the care-of or the home address) at the exception of the IKE session for a first home registration (i.e. before the home agent - mobile node tunnel is established, mobile IPv6 drafts have a MUST because of this case). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 11:55: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 LAA08474 for ; Fri, 4 Jan 2002 11:55:53 -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 IAA06530; Fri, 4 Jan 2002 08:54: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 IAA14632; Fri, 4 Jan 2002 08:54:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GrENg003656 for ; Fri, 4 Jan 2002 08:53:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04GrEqD003655 for mobile-ip-dist; Fri, 4 Jan 2002 08:53:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04GrBNg003648; Fri, 4 Jan 2002 08:53:11 -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 IAA12002; Fri, 4 Jan 2002 08:53:15 -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 JAA28064; Fri, 4 Jan 2002 09:54:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g04GrAb19477; Fri, 4 Jan 2002 17:53:10 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA04760; Fri, 4 Jan 2002 17:53: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 g04Gr9Q03466; Fri, 4 Jan 2002 17:53:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201041653.g04Gr9Q03466@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Thu, 03 Jan 2002 11:32:05 +0200. <3C342515.10904@nomadiclab.com> Date: Fri, 04 Jan 2002 17:53: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: The draft is quite nice, thanks for writing it. There are a few problems, though, that I see. Firstly, I really do find it unrealistic to assume that each and every site in the world would understand AAA, and change their ingress filtering rules based on AAA information. => this is not exactly I propose, my idea is: - to do better ingress filtering based on AAA for sites where there are some mobile nodes (aka visited sites). - to do better anti-spoofing filtering for sites from where some mobile nodes are (aka home sites). There is no constraint on sites where are the regular correspondent nodes (aka correspondent domains) which should be the vast majority of sites. I don't know how this is done everywhere but in many sites I can see a special network for nomadic nodes with special network access control and small priviledges just because by definition local network managers have not the control of them, so IMHO this is not unrealistic to ask to sites which welcome mobile nodes to have a responsible attitude towards security. Thus, that leaves changing the Binding Cache into hard state (instead of being cache) the only option, i.e. requiring that the CNs check the HAO against the Binding information. => this is exactly what we don't like... Secondly, such a the proposed practice would basically foil all of the designed zero-configuration nature of IPv6. That is, the reason for IPv6 stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 network without any prior configuration. IMHO, such a practice would be very good in many environments, even in public access WLANs. (I know that some people disagree with me.) => this is very unrealistic because this forgets the third letter of AAA. And of course this doesn't go well with the responsible use of the network principle. Thirdly, if we consider most current DDoS attacks, the majority of hosts used to launch those attacks seem to be badly administered PCs that belong to home users, careless university labs, etc. When we move to IPv6, there will continue to be organizations with little administrative knowledge (e.g. home users) or little money (e.g. some universities). It is exactly those kinds of organizations that are likely to continue having hosts that can be broken in and used in DDoS attacks. => note that the use of reflectors (i.e. iDDoS) makes the number of primary attackers less important. Now, the point is that those are also exactly the organizations that are most _unlikely_ to use advanced ingress filtering methods, => the solution in this case is just to filter out HAO, i.e. to refuse mobile nodes. or AAA at all. => in the case of home users AAA is used by ISPs. Thus, relying on AAA and advanced ingress filtering will most probably secure those parts of IPv6 internet that already have relatively secure hosts (e.g. mobile handsets or PDAs), and not those parts of the IPv6 internet that have insecure hosts. => this is more a DDoS vs ingress filtering topics... Don't forget that my idea is not to fill the hole but to get back the previous situation, i.e. to make ingress filtering a reply to the DDoS threat again. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 12:18: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 MAA08897 for ; Fri, 4 Jan 2002 12:18: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 KAA25189; Fri, 4 Jan 2002 10:17: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 JAA09426; Fri, 4 Jan 2002 09:17:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HGCNg003817 for ; Fri, 4 Jan 2002 09:16:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04HGCbx003816 for mobile-ip-dist; Fri, 4 Jan 2002 09:16: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04HG6Ng003801; Fri, 4 Jan 2002 09:16:06 -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 JAA19028; Fri, 4 Jan 2002 09:16:11 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24218; Fri, 4 Jan 2002 10:15:52 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g04HFZw22070; Fri, 4 Jan 2002 09:15:36 -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 AAP61420; Fri, 4 Jan 2002 09:15:23 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11717; Fri, 4 Jan 2002 09:15:56 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15413.58187.884431.562406@thomasm-u1.cisco.com> Date: Fri, 4 Jan 2002 09:15:55 -0800 (PST) To: Francis Dupont Cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> References: <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. RPF checks "work" mainly because they are so painless for ISP's to implement. Anything beyond that is likely to be a complete non-starter. Mike Francis Dupont writes: > In your previous mail you wrote: > > However, I'm concerned about the "applied allover" > part. Specifically - while I'm very much fond of the AAA solutions - > I'm concerned whether we can expect all parts of the Internet to have > an infrastructure that really can figure out the home addresses. What > if there's a coin-operated (or Visa-) airport WLAN? > > => this is a problem of trust in the local/visited domain *and* in the > remote/home domain. In your example if I understand the issue is the lack > of trust in the local/visited domain, so one may reject traffic with > home address options from it. > > Finally, I seem to remember there was a discussion a long time ago whether > we could somehow provide automatic, mandatory, ingress filtering in IPv6. > > => my concern is that the "mandatory" term in a RFC is not enough to > enforce it in the real world. > > Currently, we are headed towards the same situation as in IPv4 > where ingress filtering is only partially applied, and we keep coming > up with "patch" solutions such as I-trace to help the situation. > > => ingress filtering has more problems with IPv4, mainly because it was > not considered from the beginning. But it is already a BCP and it seems > that most ISPs use it (feedback from ISPs please). > > Interestingly, these solutions typically need changes to a large > fraction of the routers in the Internet which we already are doing > anyway to move to IPv6... > > => we can expect to avoid the same errors with IPv6. Unfortunately > ingress filtering (like network management) is something where IPv6 > is not yet at the same level than for IPv4 today. We hope this situation > will be improved very fast. > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 13:12: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 NAA09882 for ; Fri, 4 Jan 2002 13:12:26 -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 LAA00046; Fri, 4 Jan 2002 11:11: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 KAA21798; Fri, 4 Jan 2002 10:11:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IAONg004093 for ; Fri, 4 Jan 2002 10:10:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04IANkH004092 for mobile-ip-dist; Fri, 4 Jan 2002 10:10:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IAHNg004077; Fri, 4 Jan 2002 10:10:17 -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 KAA21587; Fri, 4 Jan 2002 10:10:22 -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 KAA28578; Fri, 4 Jan 2002 10:10:21 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id A9473A; Fri, 4 Jan 2002 20:10:53 +0200 (EET) Message-ID: <3C35F009.6020202@nomadiclab.com> Date: Fri, 04 Jan 2002 20:10:17 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201041653.g04Gr9Q03466@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I wrote: >> The draft is quite nice, thanks for writing it. There are a few problems, >> though, that I see. Firstly, I really do find it unrealistic to assume >> that each and every site in the world would understand AAA, and change their >> ingress filtering rules based on AAA information. Francis Dupont wrote: > => this is not exactly I propose, my idea is: > - to do better ingress filtering based on AAA for sites where there are > some mobile nodes (aka visited sites). Why do you assume that AAA would be used everywhere where there are mobile nodes? For example, if I am visiting with my friends at their place, why couldn't I just use their private WLAN to connect my wireless PDA to the Internet? If I could not use their private WLAN, I would consider that as a flaw in the design if the Internet. Similarily, our local university campus provides open WLAN for anyone, for anyone to connect to the Internet. It is so much simpler to run these kinds of networks without any kinds of authentication that they will continue to exist, even though many current open WLAN networks may turn into requiring some kind of authentication. But even when they start to require authentication and/or authorization, that authentication or authorization is more likely to be based on 802.1x or PANA than AAA, and even if RADIUS/DIAMETER is used, the non-ISP connectivity providers are unlikely to be part of the AAA infrastruture. For example, I run an open WLAN at my home, and even though I may require some kind of authentication in the future, it is very unlikely that I would run RADIUS or DIAMETER. Thus, making your system to help at all, it would require that EVERYBODY ELSE FORBIDS Home Address Option altogether. It is not only a mobile host that can send HAO, any host can send it. If an intruder can break into 10 million poorly protected home PCs, they can be converted into MN looking devices that send fake HAOs. Sure the ISP can drop all packets containing HAO sent from their home customer sites, but that would break the ability to use your PDA/other device through your friend's WLAN while visiting at their place. Do you see my point now? > - to do better anti-spoofing filtering for sites from where some mobile > nodes are (aka home sites). I do not argue with that part. You draft may well have some value protecting the home sites of MNs. > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. As I said above, either you must assume that any site can host MNs (in addition to CNs), ---or--- you must forbid sending HAO containing packets from those sites that are assumed not tho host MNs. My main point is that forbidding HAOs to be sent from the majority of the Internet would largely foil the purpose of Mobile IPv6. > I don't know how this is done everywhere but in many sites I can see > a special network for nomadic nodes with special network access control > and small priviledges just because by definition local network managers > have not the control of them, so IMHO this is not unrealistic to ask > to sites which welcome mobile nodes to have a responsible attitude towards > security. My point is that almost every home will, in the future, be a potential site hosting MNs. -------------------------------- > Secondly, such a the proposed practice would basically foil all of the > designed zero-configuration nature of IPv6. That is, the reason for IPv6 > stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 > network without any prior configuration. IMHO, such a practice would be > very good in many environments, even in public access WLANs. (I know that > some people disagree with me.) > > => this is very unrealistic because this forgets the third letter of AAA. > And of course this doesn't go well with the responsible use of the network > principle. Most homes do not even know about responsible use of network principle. It is just that since you can buy an Apple Airport (or whatever) from your local shop, and set it up within minutes, that will happen. Actually, it is already happening in many places in the US and scandinavia. Remember me setting up an WLAN access point at IPCN'2001 in Paris? --------------------------------- > Now, the point is that those are also exactly the organizations > that are most _unlikely_ to use advanced ingress filtering methods, > > => the solution in this case is just to filter out HAO, i.e. to refuse > mobile nodes. ... and what I am saying, such a practise is unreasonable and would severly restrict our possibility to use the future Internet. In other words, madating that ingress filtering MUST refuse HAO (unless special means is used to ensure that the Home Address is valid), besides being expensive and unrealistic, would result in MIPv6 being used only be the telecom vendors, not by the rest of us. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 13:58: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 NAA11146 for ; Fri, 4 Jan 2002 13:58:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24953; Fri, 4 Jan 2002 10:58:08 -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 KAA10704; Fri, 4 Jan 2002 10:58:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IulNg004257 for ; Fri, 4 Jan 2002 10:56:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04IulRi004256 for mobile-ip-dist; Fri, 4 Jan 2002 10:56:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04IudNg004241; Fri, 4 Jan 2002 10:56:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10315; Fri, 4 Jan 2002 10:56:43 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23488; Fri, 4 Jan 2002 10:56:41 -0800 (PST) Received: from jariws1 ([62.248.238.9]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020104185640.TKLJ11987.fep01-app.kolumbus.fi@jariws1>; Fri, 4 Jan 2002 20:56:40 +0200 Message-ID: <007101c19551$90358240$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" , "Pekka Nikander" Cc: , References: <200201041653.g04Gr9Q03466@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Fri, 4 Jan 2002 20:56:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. I am concerned that this would be an obstacle to deploying MIPv6: I couldn't put my node to network X because X will not get AAA within five years. > Secondly, such a the proposed practice would basically foil all of the > designed zero-configuration nature of IPv6. That is, the reason for IPv6 > stateless autoconfiguration is to allow hosts to be plugged in to a IPv6 > network without any prior configuration. IMHO, such a practice would be > very good in many environments, even in public access WLANs. (I know that > some people disagree with me.) > > => this is very unrealistic because this forgets the third letter of AAA. > And of course this doesn't go well with the responsible use of the network > principle. Uh... there are legitimate uses for accounting and AAA but I really don't think we should impose configuration and AAA in all situations. There's plenty of examples where there is no business or security need for complicated configuration or even accounting. Such as closed company or free university networks, or my access-paid-by-visa WLAN. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 14:11: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 OAA11551 for ; Fri, 4 Jan 2002 14:11: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 LAA00498; Fri, 4 Jan 2002 11:10:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14041; Fri, 4 Jan 2002 11:10:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04JA2Ng004408 for ; Fri, 4 Jan 2002 11:10:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04JA2Am004407 for mobile-ip-dist; Fri, 4 Jan 2002 11:10: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04J9xNg004400 for ; Fri, 4 Jan 2002 11:09:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13918 for ; Fri, 4 Jan 2002 11:10:03 -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 MAA27413 for ; Fri, 4 Jan 2002 12:11:04 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 Jan 2002 14:04:55 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] salt lake city draft meeting minutes Date: Fri, 4 Jan 2002 14:04:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, here are the draft meeting minutes from Salt Lake City. Thanks to George and Raziq for taking notes. Please let me know of mistakes that need to be corrected. Thanks, Phil --------------------- IP Routing for Wireless/Mobile Hosts WG (mobileip) Wednesday, December 12 at 0900-1130 ===================================== CHAIRS: Patil Basavaraj, Phil Roberts AGENDA: 1 Agenda Bashing, 10 Mins, WG Chairs, WG Doc Status update Document status - RFC2002bis Charlie P.: What to use on RegRep when MN has no HoA? 0.0.0.0 does not look good....maybe all 1s? it does not really matter - Aaa-key and gen-key docs to be merged - v4/v6 fast handoff drafts keep working on it. V6 doc is tied to MIPv6 security discussion - QoS and MIP interactions will be continued on NSIS WG - NAT/VPN traversal draft become WG items =>Announcement about Connectathon 2002 update MIPv4/v6 will be tested March 4-7 in San Jose Contact: email: cthon@sun.com 2 MIPv6 Security Discussion, 75 Mins Discussion lead by Gabriel Montenegro, Jari Arkko and Erik Nordmark Eric: Gabriel, Jari and Erik have looked at all the drafts and try to come up with the best solution. These presentations identify unresolved issues. - Jari talked about http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00.txt Decisions needed: + How strong should IFL be + Are Binding Security Associations (BSAs) needed? + How to implement BSAs + How to provide IFB auth? + Do we need to apply IFL if IFB is being applied? + How to provide protection between HA and MN? + How to carry Bus? + How to piggyback Bus? + Is the HoA a DoS problem? + What do about HoA + Is the Route Header a problem? + What to do about the Route Header + Is it worth doing DoS protection? - BU Security Proposals by Gabriel M. 2 main types of solutions Return Routability (RR) and Cryptographically Generated Addresses (GSAs) + RR RR without BSA RR with BSA RR with BSA #2 Double path variants possible Some vulnerabilities: RRnoBSA: Passive and active attackers RR_clearKey: Passive and active attackers RR_DH: active attackers only Minor differences with MIPv4 + CGAs No infrastructure required crypto relation between address and signature Very strong inherent authorization More cost: - Hashes are cheap but - Two heavy repeated operations couple of orders of magnitude more costly due to DH - One-Time done offine? More expensive than RR but is it an issue? Should not be a big problem for terminals Someone: There may also be some problem with scaling the Servers with the PK operations No hijacking or operations by non addr owner possible. Other possibilities are: - offload CGAs o use MN0HA trust o Potential additional round trips + previous ones on CGA - DH variants - CGA with RR o This could be good but need to be careful about reflection attacks using the protocol itself. -> Performance On 16MHz dragon (palm) SHA-1: 2.7msec per block 160 bit DH key agreement ~500ms -> IPR issues? - CGAs (Ericsson, Microsoft)? - Puzzle? - Other? -> Key Questions 1) Is to ok to be subject to passive attacks? o If not RR_noBSA and RrclearKey are not good enough Erik: This is about passive attacks between CN and MN 2) Is cost difference between RR_DH and CGA significant? 3) Is the stronger security property of CGA desired? 4) Offloading schemes worth the complexity? Michael T: Are we moving to something that requires Hard State? In CGA you can be stateless but you need state anyway because of Home Address Option so there is no benefit. Someone? What is the difference between passive and active attack? Gabriel: in active someone needs to be in the path...i.e.: it is harder Raj: Passive attacks may be done from anywhere Christian H: Microsoft send letter to IETF about potential IPR on CGA Someone: Even with BSA we have no hard state Erik: Do not think there is much difference between passive and active attack...attacks most probable close to the MN (e.g.: in wireless LAN) which is trivial to do either type of attack. More difficult to do active attacks in the core net. Someone: on q4. Servers that have many MNs on them will have hard time with offloading Gabriel: Offloading is in optimization so possibly useful but may difficult to do fast CharlyP. About Q4 should be double but should be invisible to CN Jari: If MN is Constrained in power then this may not be true...if both sides have a way to signal this then it will be better Charlie: we are asking for features that are beyond these offered by current Internet. We should think about what is it that we actually need further than what security we have today. There should also be some flexibility depending on applications so we need to think about what is the minimum needed. Gabriel: Level of protection in wireless and Mobile IP is much bigger because they security exposure is bigger. Thomas N: Q1 There are a lot of DoS attacks that are passive. The question is what are the new attack opportunities that Bus bring? And do we want to secure those. Also CGA may be more stateless but at some point one end needs to have the verify the Key in which case you will need some state anyway. Gabriel: But you can only included when you needed in which case it is stateless Hesham: Yes we do need more security than today because we do more things than before (i.e.: Bus) Christian H: We need strong security. Also RO is an optimization anyway so we should design it so that protection should be controlled by MN so we do not loose connectivity. This way we can fall back to triangular routing if MN-CN can not agree on protection required. Markus L: IF you consider on axis attacks then there is no difference between passive and active attacks Michael T: Fallback is a good thing but we still have a problem with the IPSEC tunnel black holes Erik: So we can not remove the RR_noBSA/Clear Key based on the passive/active attack arguments. Michael T: All of them are subject to Man in the middle attack. At least in DH you are only vulnerable at the start of the communication Erik: CGA is not vulnerable to Man in the middle Michael T: Actually you can Christian H: But in CGA you have to prepare the attack. If you cannot tie IP address to high level ID then you do not know how you are talking to. Erik: So in CGA you always know you talk to the right address so Man in the middle attacks are hard. But is this desirable? TCP is vulnerable to these attacks today...so maybe it is not needed. Hesham: some types of active attacks that we do not have today like hijacking connections. CGA does not allow that. Discussion about the vulnerability of CGA to man in the middle. Michael T argues that even CGA can be vulnerable in some case. Others say that it is much less vulnerable since it does no allow hijacking Raj: Based on "do not harm" how do we go forward? Steve D; Do we know intentions of IPR? Christian D: Microsoft is granting fair and reasonable non discriminatory rights. Ericsson seams to have similar policy Phil: Q4 is optimization so lets deal with this later. Michael T should document what the man in the middle vulnerability of CGA. No consensus yet more discussion on the list - Home Address Option and Routing Header security Reqs by Erik Trying to understand interactions between HoA option header and ingress filtering, ITRACE, IPPT etc. If non of these is used then source address spoofing could be used for reflection attacks. Discussion about ITRACE Discussion about IP in IP tunneling VS Home Address Option security issues. Discussion about HAOpt idea: CN drops packets with HAOpt unless there is a matching binding cache entry for sending Francis: We should instead improve ingress filtering...describes high level idea Erik: You should right this up because I do not think it is possible Phil: Please right up the proposal Michael T: Important thing is that if we want ingress filtering we can either put it in ARs or in CNs...more need work. But what brings better fate sharing? The AR will do better in this. Hesham: What happens with BNACKS on reboots? Erik: That is why we need ICMP error message Hesham: How do you rate limit? Erik: Basic ICMP rate limiting can be used Hesham: I think this is a good idea to go with. Routing Header Discussion This is about the MIPv6 use of the routing header Steve D: Source Routing is equivalent to encapsulation. RH leaves trace of the path which is better than the encapsulation and box that uses them should adhere to back trace requirements for general routers. In the special case of MIPv6 the packets is only forwarded in the box...so these could be excluded for the router rules Charlie: Home Address has to be after the CoA and that is the only thing needed for the MIPv6 application of RH...other apps may have more complex requirements 3 RFC3012bis: Issues identified and Changes made 10 Mins Charles http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-00.txt Need to specify which bytes to be included in the authentication data A number of issues fixed. This will come out soon and will go to last call. 4. Handoffs: Low Latency(v4) and Fast HO (v6) 30 Mins a. Discussion of issues based on implementation experience James Kempf http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs- v4-03.txt http://geocities.com/kempf42/llanalysis.pdf Asked who else implemented this...No hands were raised! Problems with Prereg method Proposed to move Prereg to separate draft keep postreg in standards track A couple of people actually about to do the implementations so comparisons are premature. Hesham challenged whether what was implemented was actually what is described in the draft. Karim pointed out that this analysis is based on a very particular network configuration and results may be different with other configurations. -------------WG run out of time----------- b. Fast handoff - Updates/Changes/Issues raised on list Gopal Dommety http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast-mipv 6-04.txt 5. Localized Mobility Management Requirements 10 Mins Carl Williams http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-00. txt 6. MIPv6 at ETSI Bakeoff Report 10 Mins Sebastien Barbin From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 15:30:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13162 for ; Fri, 4 Jan 2002 15:30:04 -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 NAA22430; Fri, 4 Jan 2002 13:28: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 MAA19133; Fri, 4 Jan 2002 12:29:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04KRwNg004589 for ; Fri, 4 Jan 2002 12:27:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04KRwvA004588 for mobile-ip-dist; Fri, 4 Jan 2002 12:27:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04KRtNg004581; Fri, 4 Jan 2002 12:27:55 -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 MAA07324; Fri, 4 Jan 2002 12:28:00 -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 NAA28036; Fri, 4 Jan 2002 13:29:00 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g04KRuQ27975; Fri, 4 Jan 2002 14:27:56 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 14:26:25 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0152FC17@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Was Node Mobility a Requirement for IPng? Date: Fri, 4 Jan 2002 14:26:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1955E.25F9D900" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/plain; charset="iso-8859-1" Hello, Does anyone know if node mobility was a requirement for IPng during the debates among the proposals? If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on. I'm just trying to understand the thinking of the past and how each might be reason to affect the other. Thanks, Glenn ------_=_NextPart_001_01C1955E.25F9D900 Content-Type: text/html; charset="iso-8859-1"
Hello,
 
Does anyone know if node mobility was a requirement for IPng during the debates among the proposals?
 
If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on.
 
I'm just trying to understand the thinking of the past and how each might be reason to affect the other.
 
Thanks,
 
Glenn
------_=_NextPart_001_01C1955E.25F9D900-- From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 16:05: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 QAA13780 for ; Fri, 4 Jan 2002 16:05:24 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12536; Fri, 4 Jan 2002 14:04:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04252; Fri, 4 Jan 2002 13:04:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04L2XNg004727 for ; Fri, 4 Jan 2002 13:02:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04L2Xbs004726 for mobile-ip-dist; Fri, 4 Jan 2002 13:02:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04L2TNg004719 for ; Fri, 4 Jan 2002 13:02:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13925 for ; Fri, 4 Jan 2002 13:02:24 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10959 for ; Fri, 4 Jan 2002 14:03:29 -0700 (MST) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 8A6165F2; Fri, 4 Jan 2002 13:02:07 -0800 (PST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 69007721 for ; Fri, 4 Jan 2002 13:02:07 -0800 (PST) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id B2FFB1ED5; Fri, 4 Jan 2002 15:02:22 -0600 (CST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 4A33B50B for ; Fri, 4 Jan 2002 15:02:22 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000008714; Fri, 4 Jan 2002 16:02:21 -0500 (EST) From: Brian Haley USG Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000027469; Fri, 4 Jan 2002 16:02:21 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA17211; Fri, 4 Jan 2002 16:02:20 -0500 Message-Id: <200201042102.AA17211@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] salt lake city draft meeting minutes Date: Fri, 04 Jan 2002 16:02:20 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -------------WG run out of time----------- > > 6. MIPv6 at ETSI Bakeoff Report 10 Mins Sebastien Barbin I was wondering if Sebastien could send this report to the mailing list. I know of a couple of issues that came up there, but maybe there were more? Thanks, -Brian P.S Why does this working group never get through it's agenda? I've attended the last 5 IETFs and don't think it's happened yet. From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 16:17: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 QAA14048 for ; Fri, 4 Jan 2002 16:17: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 NAA14594; Fri, 4 Jan 2002 13:16:22 -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 NAA27548; Fri, 4 Jan 2002 13:16:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04LExNg004976 for ; Fri, 4 Jan 2002 13:14:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04LExBP004975 for mobile-ip-dist; Fri, 4 Jan 2002 13:14: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04LEtNg004968 for ; Fri, 4 Jan 2002 13:14: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 NAA15943 for ; Fri, 4 Jan 2002 13:15:00 -0800 (PST) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12531 for ; Fri, 4 Jan 2002 13:15:00 -0800 (PST) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA04573 for ; Fri, 4 Jan 2002 15:14:59 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g04LExr15391 for ; Fri, 4 Jan 2002 15:14:59 -0600 (CST) Message-ID: <3C361B50.9010609@alcatel.com> Date: Fri, 04 Jan 2002 15:14:56 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] salt lake city draft meeting minutes References: <200201042102.AA17211@dogbert.zk3.dec.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Brian, Brian Haley USG wrote: >>-------------WG run out of time----------- >> > > > >P.S Why does this working group never get through it's agenda? I've > attended the last 5 IETFs and don't think it's happened yet. > If you attend WGs like Seamoby then you can see it to the end. They get through the agenda, and even they adjurn one hour or so earlier. The catch is that most of the technical presentations are avoided. Regards, -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 19:00: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 TAA16429 for ; Fri, 4 Jan 2002 19:00:52 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07210; Fri, 4 Jan 2002 16:59:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06808; Fri, 4 Jan 2002 15:59:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04NxBNg005420 for ; Fri, 4 Jan 2002 15:59:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g04NxAgK005419 for mobile-ip-dist; Fri, 4 Jan 2002 15:59: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04Nx7Ng005412 for ; Fri, 4 Jan 2002 15:59:07 -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 PAA05227 for ; Fri, 4 Jan 2002 15:59:12 -0800 (PST) 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 QAA06846 for ; Fri, 4 Jan 2002 16:58:53 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0500aQ15430 for ; Fri, 4 Jan 2002 18:00:36 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 4 Jan 2002 17:59:11 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 4 Jan 2002 17:59:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs Date: Fri, 4 Jan 2002 17:59:10 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD370@daebe007.NOE.Nokia.com> Thread-Topic: Consensus call - MIPv4 interopration with NATs/VPNs Thread-Index: AcGVe8zOJhsrxwFcEdaxfAAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 04 Jan 2002 23:59:11.0188 (UTC) FILETIME=[CDF36140:01C1957B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g04Nx7Ng005413 Sender: owner-mobile-ip@sunroof.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 In London a design team was formed to investigate the problem of Mobile IPv4 interoperation with NATs and VPNs. At the time there was a clear constituency in the working group that having a solution to NAT traversal was important. It was less clear to the chairs that there was a clear interest in the working group for a specification of the operation of Mobile IPv4 across VPN gateways. To that end we propose that the following draft: draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt (the output of the design team) be made into a working group item for progression on the Standards Track. Please let us know in the next few days if you object to this. We would also like to hear feedback from the working group on whether there is a perceived need for a solution to Mobile IPv4 interoperation with VPN gateways. WG Chairs From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 19:18: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 TAA16598 for ; Fri, 4 Jan 2002 19:18:26 -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 RAA14123; Fri, 4 Jan 2002 17:17: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 QAA10221; Fri, 4 Jan 2002 16:17:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g050GpNg005582 for ; Fri, 4 Jan 2002 16:16:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g050Gp6H005581 for mobile-ip-dist; Fri, 4 Jan 2002 16:16: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g050GmNg005574 for ; Fri, 4 Jan 2002 16:16: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 QAA08419 for ; Fri, 4 Jan 2002 16:16:33 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15905 for ; Fri, 4 Jan 2002 17:17:37 -0700 (MST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel12.hp.com (Postfix) with ESMTP id 47C5DE009C3 for ; Fri, 4 Jan 2002 16:16:32 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id QAA22017 for mobile-ip@sunroof.eng.sun.com; Fri, 4 Jan 2002 16:17:45 -0800 (PST) Date: Fri, 4 Jan 2002 16:17:45 -0800 (PST) From: Joe Lau Message-Id: <200201050017.QAA22017@strtio1.cup.hp.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD370@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. Yes. I should include Mobile IPv4 interoperation with VPN gateways as a WG item as well. Joe Lau From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 4 19:38: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 TAA16730 for ; Fri, 4 Jan 2002 19:38:02 -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 RAA20636; Fri, 4 Jan 2002 17:36: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 QAA01608; Fri, 4 Jan 2002 16:37:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g050aINg005715 for ; Fri, 4 Jan 2002 16:36:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g050aIvg005714 for mobile-ip-dist; Fri, 4 Jan 2002 16:36: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g050aFNg005707 for ; Fri, 4 Jan 2002 16:36:15 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23544 for ; Fri, 4 Jan 2002 16:36:20 -0800 (PST) Received: from hermes.fm.intel.com ([192.55.52.18]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15636 for ; Fri, 4 Jan 2002 16:36:19 -0800 (PST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.28 2002/01/02 21:40:45 root Exp $) with ESMTP id g050a4p07598 for ; Sat, 5 Jan 2002 00:36:04 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id g050a8t26774 for ; Sat, 5 Jan 2002 00:36:08 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002010416355017650 for ; Fri, 04 Jan 2002 16:35:50 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 16:36:18 -0800 Message-ID: <0DCC27458EB5D51181840002A507069EE30CC0@orsmsx117.jf.intel.com> From: "Iyer, Prakash" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Fri, 4 Jan 2002 16:36:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Raj, There were even folks (e.g. Alexis Olivereau from Motorola) on the IPSRA mailing list who were asking if a solution to combine mobile IP and VPNs was being worked on and I had responded with the link to the draft draft-adrangi-mobileip-natvpn-traversal-00.txt. Enterprise access with mobile IP is likely to be a driving scenario that clearly needs standardization of mobile IP with IPsec-based VPNs. And in fact the vendors who worked on the NAT draft has IPsec-based mobile IP solutions in their products. We have not seen any pushback on working on a solution to this problem and would in fact very much like to see this being taken up as a WG work item. Regards. -Prakash -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Friday, January 04, 2002 3:59 PM To: 'Mobile IP' Subject: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs In London a design team was formed to investigate the problem of Mobile IPv4 interoperation with NATs and VPNs. At the time there was a clear constituency in the working group that having a solution to NAT traversal was important. It was less clear to the chairs that there was a clear interest in the working group for a specification of the operation of Mobile IPv4 across VPN gateways. To that end we propose that the following draft: draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt (the output of the design team) be made into a working group item for progression on the Standards Track. Please let us know in the next few days if you object to this. We would also like to hear feedback from the working group on whether there is a perceived need for a solution to Mobile IPv4 interoperation with VPN gateways. WG Chairs From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 5 06:52: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 GAA03868 for ; Sat, 5 Jan 2002 06:52:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11743; Sat, 5 Jan 2002 03:51:24 -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 DAA19014; Sat, 5 Jan 2002 03:51:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05BoPNg006227 for ; Sat, 5 Jan 2002 03:50:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g05BoPjY006226 for mobile-ip-dist; Sat, 5 Jan 2002 03:50:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05BoLNg006219 for ; Sat, 5 Jan 2002 03:50: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 DAA18973 for ; Sat, 5 Jan 2002 03:50:25 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28686 for ; Sat, 5 Jan 2002 04:50:24 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g05BoOJ06849 for ; Sat, 5 Jan 2002 12:50:24 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Jan 05 12:50:07 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jan 2002 12:41:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C199@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: Is RR only enough ? Date: Sat, 5 Jan 2002 12:50:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik and Mike I'll try to save BW and answer you in one email. First to answer Mike, I'm not sure if we can say MITM is acceptable and put a blanket statement on that. I think it is more accurate to go with the context of adding no harm since I believe that the "MITM attacks are ok" statement was made in this context, but I might have misunderstood. So MITM attacks that can happen today are ok, but I would assume that new ones are not. I'll try to answer Erik's comments below. > Yes this is a possible attack. > > But you seem to be implicitly claiming that this is worse > than today's > IPv4 network with an attacker on the path between the > communicating nodes. => Yes that's correct. > That is the argument I don't understand i.e. why is this > any more harmful > than the MiTM attacking every TCP connection and UDP > "session"? The MiTM => Well, this is a much simpler attack. That is, assuming the MITM is in the right location, this attack is easily done by one BU and steals all connections. Furthermore, if the MITM happens to be close enough to the HA, he can do this attack for all MNs served by that HA (assuming that he is close enough so that most of the traffic addressed to the HA will be seen by him). I would assume that in the cases you mention, the MITM would have to do more work to be able to steal a TCP connection for example. Actually I don't know how the MITM can 'steal' the TCP connection in the scenario you mention. Please note that I'm talking about stealing the existing conneciton (receiving the information addressed to the MN), rather than modifying packets and causing the connection to be dropped. > > So why is it worse? > => So to summarise my points above, I think it's worse because: - From a single location the MITM can steal _all_ the MN connections with a CN (and possibly more than one CN). This is done without launching any DoS attacks on the MN which gives the MITM less work to do. - MITM can also steal most of the MN's connections to CNs he's aware of, provided he's close enough to the HA. - This attack is specific to MIPv6 and clearly due to the BU. The last point is probably not showing why it's worse but simply for clarification. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 5 08:52: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 IAA04447 for ; Sat, 5 Jan 2002 08:52:20 -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 FAA19694; Sat, 5 Jan 2002 05:51:33 -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 FAA13673; Sat, 5 Jan 2002 05:51:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05DolNg006407 for ; Sat, 5 Jan 2002 05:50:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g05Dok9o006406 for mobile-ip-dist; Sat, 5 Jan 2002 05:50: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05DohNg006399 for ; Sat, 5 Jan 2002 05:50:43 -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 FAA13640 for ; Sat, 5 Jan 2002 05:50:48 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01698 for ; Sat, 5 Jan 2002 06:50:29 -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.11.0/8.11.0/WIREfire-1.3) with SMTP id g05DolJ29005 for ; Sat, 5 Jan 2002 14:50:47 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Jan 05 14:50:30 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 5 Jan 2002 14:50:30 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1A0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Sat, 5 Jan 2002 14:50: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: Hi Francis, Thanks for the draft. Some comments: While I do believe that AAA will be available at some stage, in most networks, I still don't favour this solution because: - I firmly believe that an infrastructureless solution is the natural, scalable and more reliable way to go here. It is a natural continuation of the MIPv6 philosophy which is always e2e. This might sound wishy washy but I really think that relying on AAA for ingress filtering will just complicate things too much. - Relying on ingress filtering at all for the HAO is not a good idea. Relying on some intermediate node to do something, when no one will ever have a clue about whether this node has done it or not, seems like the wrong approach to me. Basically this is telling the CN to accept packets, because the MIPv6 spec says (potentially if this approach is adopted) that ingress filtering was done at the sender's default router. Doesn't seem right. - From a practical point of view, it will take a very long time before we can get the entire framework for AAAv6 finished. So if timing is a concern (I'm regularly reminded !) then it's probably a good idea not to delay the spec more than we have to. - Looking at this from a different angle, does it really matter if the MN reverse tunnels to the HA ? I mean, if the CN doesn't accept the BU, currently, there will be triangular routing. So, do we really know that reverse tunnelling will make the situation much worse ?? I don't know. That's all from me. Needless to say, that I did write a draft on using AAA for generating keys for BU authentication, but frankly, after investigating the CGA mechanisms, I won't pursue the AAA option anymore. Infrastructureless solutions are much more scalable and easier to deploy IMHO. Regards, Hesham > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Friday, January 04, 2002 5:22 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access > > > I may have missed some discussion due to high volume on > this topic, > but I like to inject one scenario of Home Address option use... > > If MN and CN have IPSEC session between them, then I > suppose HAO within such session is safe. > > => this depends on what is an IPsec session (AH makes HAO safe, > more details are needed for other cases). > > (I leave it open for now, > whether the session should be between care of addresses or home > addresses of MN and CN, but either should work?). > > => if the IPsec SA is with a care-of address it has to be rebuilt > after each movement. But the ISAKMP SA can be with the care-of > or the home address (i.e. IKE session can use the care-of or the > home address) at the exception of the IKE session for a first home > registration (i.e. before the home agent - mobile node tunnel is > established, mobile IPv6 drafts have a MUST because of this case). > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 5 13:23: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 NAA06294 for ; Sat, 5 Jan 2002 13:23: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 LAA10984; Sat, 5 Jan 2002 11:22:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20434; Sat, 5 Jan 2002 10:22:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05ILSNg006681 for ; Sat, 5 Jan 2002 10:21:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g05ILSq0006680 for mobile-ip-dist; Sat, 5 Jan 2002 10:21: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05ILONg006673 for ; Sat, 5 Jan 2002 10:21:25 -0800 (PST) Received: from lillen (hobo180.EBay.Sun.COM [129.150.99.77]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g05IJ9328436; Sat, 5 Jan 2002 19:19:17 +0100 (MET) Date: Sat, 5 Jan 2002 19:16:29 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RE: Is RR only enough ? To: hesham.soliman@era.ericsson.se Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C199@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: > => Well, this is a much simpler attack. That is, assuming > the MITM is in the right location, this attack > is easily done by one BU and steals all connections. So your point is that the attack program that a hacker needs to write would be significantly shorter and easier to develop? You're probably right, but I don't think that means there is more harm - once the attack software is written and distributed to the attackers out there they can cause the same amount of harm. > Furthermore, if the MITM happens to be close enough > to the HA, he can do this attack for all MNs served > by that HA (assuming that he is close enough so > that most of the traffic addressed to the HA will > be seen by him). Yes, but this doesn't seem any more different than an attacker close to the border router of e.g. sun.com being able to be a MiTM for most of the traffic to/from all of Sun. > I would assume that in the cases you mention, the > MITM would have to do more work to be able > to steal a TCP connection for example. Actually > I don't know how the MITM can 'steal' the TCP > connection in the scenario you mention. Please > note that I'm talking about stealing the existing > conneciton (receiving the information addressed > to the MN), rather than modifying packets and > causing the connection to be dropped. I depends what the attacker want to do. For instance with the TCP packet stream in both directions the attacker can easily respond to a HTTP get from the MN to the CN which completely different data, while consuming the actual HTTP response from the CN. Perhaps the set of attacks are more limited when the attacker is on path for only one direction due to assymetries in the routes. (I haven't thought this through in detail.) In the BU case for RR schemes we know I think it is sufficient for the attacker to see packets from the CN to the MN and then be able to respond to those packets with the MN's Home Address as the source i.e. the attacker doesn't need to be on the path for packets from the MN/HA to the CN. But this doesn't seem to be a significant different IMHO. > - From a single location the MITM can steal _all_ > the MN connections with a CN (and possibly more > than one CN). This is done without launching > any DoS attacks on the MN which gives the MITM > less work to do. In the TCP MiTM case I don't think a DoS attack is needed on the MN. The attacker on path is presumably capable of supressing packets from being delivered as was as injecting its own (spoofed) packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 5 13:27: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 NAA06348 for ; Sat, 5 Jan 2002 13:27: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 KAA10034; Sat, 5 Jan 2002 10:26: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 KAA21000; Sat, 5 Jan 2002 10:26:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05IPnNg006784 for ; Sat, 5 Jan 2002 10:25:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g05IPndt006783 for mobile-ip-dist; Sat, 5 Jan 2002 10:25:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05IPjNg006776 for ; Sat, 5 Jan 2002 10:25:45 -0800 (PST) Received: from lillen (hobo180.EBay.Sun.COM [129.150.99.77]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g05IPY328589; Sat, 5 Jan 2002 19:25:35 +0100 (MET) Date: Sat, 5 Jan 2002 19:22:54 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RE: Is RR only enough ? To: hesham.soliman@era.ericsson.se Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C199@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: > => Well, this is a much simpler attack. That is, assuming > the MITM is in the right location, this attack > is easily done by one BU and steals all connections. So your point is that the attack program that a hacker needs to write would be significantly shorter and easier to develop? You're probably right, but I don't think that means there is more harm - once the attack software is written and distributed to the attackers out there they can cause the same amount of harm. > Furthermore, if the MITM happens to be close enough > to the HA, he can do this attack for all MNs served > by that HA (assuming that he is close enough so > that most of the traffic addressed to the HA will > be seen by him). Yes, but this doesn't seem any more different than an attacker close to the border router of e.g. sun.com being able to be a MiTM for most of the traffic to/from all of Sun. > I would assume that in the cases you mention, the > MITM would have to do more work to be able > to steal a TCP connection for example. Actually > I don't know how the MITM can 'steal' the TCP > connection in the scenario you mention. Please > note that I'm talking about stealing the existing > conneciton (receiving the information addressed > to the MN), rather than modifying packets and > causing the connection to be dropped. I depends what the attacker want to do. For instance with the TCP packet stream in both directions the attacker can easily respond to a HTTP get from the MN to the CN which completely different data, while consuming the actual HTTP response from the CN. Perhaps the set of attacks are more limited when the attacker is on path for only one direction due to assymetries in the routes. (I haven't thought this through in detail.) In the BU case for RR schemes we know I think it is sufficient for the attacker to see packets from the CN to the MN and then be able to respond to those packets with the MN's Home Address as the source i.e. the attacker doesn't need to be on the path for packets from the MN/HA to the CN. But this doesn't seem to be a significant different IMHO. > - From a single location the MITM can steal _all_ > the MN connections with a CN (and possibly more > than one CN). This is done without launching > any DoS attacks on the MN which gives the MITM > less work to do. In the TCP MiTM case I don't think a DoS attack is needed on the MN. The attacker on path is presumably capable of supressing packets from being delivered as was as injecting its own (spoofed) packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 5 13:29: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 NAA06396 for ; Sat, 5 Jan 2002 13:29:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12090; Sat, 5 Jan 2002 11:28: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 KAA21218; Sat, 5 Jan 2002 10:28:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05IS6Ng006813 for ; Sat, 5 Jan 2002 10:28:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g05IS63p006812 for mobile-ip-dist; Sat, 5 Jan 2002 10:28:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g05IS2Ng006805 for ; Sat, 5 Jan 2002 10:28:03 -0800 (PST) Received: from lillen (hobo180.EBay.Sun.COM [129.150.99.77]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g05IMo328541; Sat, 5 Jan 2002 19:22:50 +0100 (MET) Date: Sat, 5 Jan 2002 19:18:33 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RE: Is RR only enough ? To: hesham.soliman@era.ericsson.se Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C199@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: > => Well, this is a much simpler attack. That is, assuming > the MITM is in the right location, this attack > is easily done by one BU and steals all connections. So your point is that the attack program that a hacker needs to write would be significantly shorter and easier to develop? You're probably right, but I don't think that means there is more harm - once the attack software is written and distributed to the attackers out there they can cause the same amount of harm. > Furthermore, if the MITM happens to be close enough > to the HA, he can do this attack for all MNs served > by that HA (assuming that he is close enough so > that most of the traffic addressed to the HA will > be seen by him). Yes, but this doesn't seem any more different than an attacker close to the border router of e.g. sun.com being able to be a MiTM for most of the traffic to/from all of Sun. > I would assume that in the cases you mention, the > MITM would have to do more work to be able > to steal a TCP connection for example. Actually > I don't know how the MITM can 'steal' the TCP > connection in the scenario you mention. Please > note that I'm talking about stealing the existing > conneciton (receiving the information addressed > to the MN), rather than modifying packets and > causing the connection to be dropped. I depends what the attacker want to do. For instance with the TCP packet stream in both directions the attacker can easily respond to a HTTP get from the MN to the CN which completely different data, while consuming the actual HTTP response from the CN. Perhaps the set of attacks are more limited when the attacker is on path for only one direction due to assymetries in the routes. (I haven't thought this through in detail.) In the BU case for RR schemes we know I think it is sufficient for the attacker to see packets from the CN to the MN and then be able to respond to those packets with the MN's Home Address as the source i.e. the attacker doesn't need to be on the path for packets from the MN/HA to the CN. But this doesn't seem to be a significant different IMHO. > - From a single location the MITM can steal _all_ > the MN connections with a CN (and possibly more > than one CN). This is done without launching > any DoS attacks on the MN which gives the MITM > less work to do. In the TCP MiTM case I don't think a DoS attack is needed on the MN. The attacker on path is presumably capable of supressing packets from being delivered as was as injecting its own (spoofed) packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 08:31: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 IAA23306 for ; Sun, 6 Jan 2002 08:31: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 GAA17253; Sun, 6 Jan 2002 06:30:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09786; Sun, 6 Jan 2002 05:30:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06DU8Ng007677 for ; Sun, 6 Jan 2002 05:30:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06DU7p2007676 for mobile-ip-dist; Sun, 6 Jan 2002 05:30: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06DU4Ng007669 for ; Sun, 6 Jan 2002 05:30: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 FAA11847 for ; Sun, 6 Jan 2002 05:30:09 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14837 for ; Sun, 6 Jan 2002 05:30:08 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 5B653A; Sun, 6 Jan 2002 15:30:36 +0200 (EET) Message-ID: <3C385158.8010201@nomadiclab.com> Date: Sun, 06 Jan 2002 15:30:00 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, Hesham and others, On the question of whether RR alone could provide security that is in par with IPv4 security, I think I have came up with an attack scenario that RR alone does not block (see below). However, this attack is certainly fairly far fetched, and I _personally_ could imagine that being vulnerable to this one _might_ be acceptable. The attack scenario: Let us consider an attacker A, a corrensponding node CN, and a pre-selected mobile node MN whose home address is HoA. Now, A has decided to steal all traffic that CN will initiate towards MN. To do so, it somehow arranges itself _once_ to the path between CN and MN's HA. It may do this, for example, by visiting the network where CN is located, where MN's HA is located, or any network in between. While being at the path between CN and MN's HA, the attacker creates a binding (and a corresponding BSA) at CN. This will succeed, since A knows MN's home address and it can foil the RR test. As a result, CN believes that MN is currently located at the adddress given by A, and therefor whenever it sends packets to MN, it will send them to the attacker. Thus, A is able to steal all connections initiated by CN towards MN. Furthermore, if CN does not check the return routability of the MN's home address if there is already an existing BSA, then the attacker can keep up the faulty binding as long as it wishes, simply by renewing the binding and BSA periodically. To renew, it no longer needs to be at the path between the CN and the MN's HA. Discussion: This attack is not present in IPv4 since in this scenario the attacker steals all traffic _beforehand_, and does not need to be on the vulnerable path later when the communication session is actually initiated. Thus, there is a potential class of attackers that may be able to launch this attack but that could not attack under the current IPv4 architecture. This attack is most effective if the discussed MN is not actually a mobile node but a stationary node. In that case the node will never send binding updates or home address options. As a result, the attacker may be able to renew the faulty binding and BSA for long times. Furthermore, even if the node initiates a connection, the CN will send replies to the attacker, allowing the attacker to spy or DoS this connection as well. Still further, if the attacker performs the same attack against both parties, it may establish itself as full MitM for all future communications between the parties. In a way, this is a variant of the "future attack" that I described at the 50th IETF SAAG meeting, see http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf If we consider stationary nodes communicating with CNs, i.e. about generic non-mobile-ipv6 traffic, this attack appears to be most devious. Since the nodes do not assume their peer to have a binding for them, they have hard time in determining that there actually is one. If the attacker is careful enough, it may get along for long times. Thus, the only protection here is that the attacker actually needs _once_ to get access to the vulnerable path between the CN and the HoA. Let us consider this "_once_ at the vulnerable path requirement." If all the links involved are physically protected, i.e. if the links do not accept unauthenticated nodes, the only realistic threat that I see is the attacker breaking in into _some_other_ computer at one of the links. For example, if the CN is a web server at a DMZ, and the DMZ also contains e.g. a poorly administered Linux-login box, just breaking in to that Linux box could make it possible to initiate the required faulty bindings at the CN. As a consequence, once it is found out that the Linux box has been compromised, the CN must be cleared of any bindings, just to be sure. Whether this risk is considered large enough to mandate using CGAs, i.e. potentially IPR protected technology, goes beyond my apprehension. But I certainly think there seems to be reason to make CGAs a preferred and recommended practise, and to be recommended that bindings that have not been protected with CGA should have relatively short lifetime, and not be renewable without full RR test upon renewal. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 08:48: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 IAA23448 for ; Sun, 6 Jan 2002 08:47:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19675; Sun, 6 Jan 2002 06:46:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10659; Sun, 6 Jan 2002 05:47:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06DkPNg007813 for ; Sun, 6 Jan 2002 05:46:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06DkPxq007812 for mobile-ip-dist; Sun, 6 Jan 2002 05:46:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06DkMNg007805 for ; Sun, 6 Jan 2002 05:46:22 -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 FAA28173 for ; Sun, 6 Jan 2002 05:46:27 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17011 for ; Sun, 6 Jan 2002 05:46:26 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 8212BA for ; Sun, 6 Jan 2002 15:47:00 +0200 (EET) Message-ID: <3C385531.8050606@nomadiclab.com> Date: Sun, 06 Jan 2002 15:46:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A proposed MIPv6 security policy statement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, Based on my observation about the "future attack" against RR (see my previous message), may I suggest that we establish a recommended security policy statement for all IPv6 nodes that implement MIPv6 CN functionality. I'd like the present the following statement as a seed for discussion: A node MUST NOT establish a binding unless the BU has been properly protected. If the BU is protected only with return reachability (RR), the maximun lifetime of the binding SHOULD NOT exceed MAX_RR_BU_LIFETIME minutes. If the BU is protected with cryptographically generated addresses (CGA) or by stronger local means, e.g. by employing AAA or a local PKI, the maximum lifetime of the binding is a matter of local policy. If a binding has been created in a result of a BU protected only with RR tests, and the MN wants to renew or change the binding, the CN MUST check the return reachability of both the care-of-address and the home address. If, on the other hand, the binding has been created in a result of a BU protected with CGA or stronger means, the test checking the return routability of the _home_address_ MAY be skipped. The return routablity of the care-of-address MUST be performed in any case. Rationale: RR is computationally much cheaper than CGA, but it leaves open some threats that are not present in IPv4. However, there seems to be environments where the protection provided by RR is enough. On the other hand, to provide reasonable protection against the aforementioned threats, RR of _both_ the home address and care-of-address MUST be checked every time an RR based binding is renewed or changed. CGA, combined with initial RR, on the other hand, provides reasonable grounds to believe that the CN really "owns" the home address. Consequently, if CGA is used, it seems to be sufficient to check the RR of the CoA whenever a binding is renewed or changed. Note that checking the RR of the CoA may be easily mixed with the regular packet stream (and therefore e.g. does not cause problems to packet header compression) while checking the RR of the Home Address requires an extra exchange that falls outside the normal packet flow. I think that statement might serve us in desiging the MIPv6 security solution in such a way that it allows flexibility of mechanisms without opening too many vulnerabilities. A reasonable value for MAX_RR_BU_LIFETIME might be e.g. a few minutes. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 09:30:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23698 for ; Sun, 6 Jan 2002 09:30:04 -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 HAA25050; Sun, 6 Jan 2002 07:29:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00698; Sun, 6 Jan 2002 06:29:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06ESMNg007956 for ; Sun, 6 Jan 2002 06:28:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06ESMMZ007955 for mobile-ip-dist; Sun, 6 Jan 2002 06:28:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06ESFNg007940; Sun, 6 Jan 2002 06:28:15 -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 GAA00673; Sun, 6 Jan 2002 06:28:20 -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 HAA02932; Sun, 6 Jan 2002 07:28:19 -0700 (MST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g06ESGb01069; Sun, 6 Jan 2002 15:28:16 +0100 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 g06ESGQ10317; Sun, 6 Jan 2002 15:28:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061428.g06ESGQ10317@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: "Jari Arkko" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Fri, 04 Jan 2002 09:15:55 PST. <15413.58187.884431.562406@thomasm-u1.cisco.com> Date: Sun, 06 Jan 2002 15:28: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: I sure hope that nobody's making the assumption that you need to be a mobile node to send BU's and/or HAO's. => by definition if a node which sends BUs is a mobile node. But I agree that HAOs are useful for nodes which are not mobile nodes, so the BCE check is not a good solution. My provider doesn't care diddly squat about any of this, nor is it likely that if I tunnel to the 6bone they're going to care much either. => my proposal is not based on traditional unicast RPF ingress filtering done by routers, it is based on firewalls at the border of source sites. But don't believe RPF checks are obsolete, the idea is to use it against traditional DDoS and to use enhanced ingress filtering against the iDDoS threat from HAOs. If this is your only line of defense of protecting CN's from senders of malicious HAO's, I'm pretty skeptical. => enhanced ingress and anti-spoofing filterings are based on the knowledge of bindings. If there should be no HAO sender in a site, the extra ingress filtering rule is just "drop packets with a HAO". If there should be no home agent in a site, the extra anti-spoofing filtering rule is just "applies anti-spoofing to addresses in HAOs". So in common cases the job is easy and even scalable. RPF checks "work" mainly because they are so painless for ISP's to implement. => I don't believe this is so easy but this is an indication that ISPs are ready to implement a kind of access control which gives them no direct benefit. IMHO we can trust smart ingress filtering as much as current ingress filtering... Anything beyond that is likely to be a complete non-starter. => we'll see... We (IETF) can't do far more than to provide technical solutions. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 10:47: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 KAA24144 for ; Sun, 6 Jan 2002 10:47: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 IAA05579; Sun, 6 Jan 2002 08:46: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 HAA05075; Sun, 6 Jan 2002 07:46:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06FjaNg008137 for ; Sun, 6 Jan 2002 07:45:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06FjaAl008136 for mobile-ip-dist; Sun, 6 Jan 2002 07:45:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06FjWNg008129 for ; Sun, 6 Jan 2002 07:45:32 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21427 for ; Sun, 6 Jan 2002 07:45:36 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-1.kolumbus.fi [193.229.5.107]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03874 for ; Sun, 6 Jan 2002 07:45:34 -0800 (PST) Received: from jariws1 ([62.248.238.9]) by fep07-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020106154508.POPS1587.fep07-app.kolumbus.fi@jariws1>; Sun, 6 Jan 2002 17:45:08 +0200 Message-ID: <007f01c196c9$36d053a0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pekka Nikander" , Cc: , "'Erik Nordmark'" References: <3C385158.8010201@nomadiclab.com> Subject: [mobile-ip] Re: A threat RR doesn't solve and that doesn't seem to exist in IPv4 Date: Sun, 6 Jan 2002 17:45:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree that this attack exists and seems to be beyond what regular IPv4 holes allowed. There seems to be a few differences with respect to v6+RR vs. v4. What Pekka describes is an attack where the attacker can move the effect of the attack forwards in time. There's also another attack where the attacker can move most of actual attack work elsewhere. For instance, instead of bombing a third party himself, if he is on the home - CN path, he can create a falso binding entry at the CN, and have the CN send all or most packets towards the victim. In this attack we move the attack in space, not time. Interestingly, this particular attack seems to apply to CGA as well in a limited fashion, since you can still bomb a network with CGA even if host bombing can't be performed. (Protocols like CAM-DH use RR to verify the correctness of the upper part of the address and CGA for the lower part.) As for the significance of Pekka's and other attacks, I'm not sure what to say yet. It does seem bad that one has to worry about past breaches and not just the current state of the network. On the other hand, rules about maximum BCE lifetimes may help here. We've also heard arguments that on a local LAN most of the threats are already present (but not in a permanent way as described by Pekka), and that we are already dependent on routers doing their job. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 11:06: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 LAA24283 for ; Sun, 6 Jan 2002 11:06:24 -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 JAA08445; Sun, 6 Jan 2002 09:05: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 IAA18719; Sun, 6 Jan 2002 08:05:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06G4lNg008352 for ; Sun, 6 Jan 2002 08:04:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06G4lEi008351 for mobile-ip-dist; Sun, 6 Jan 2002 08:04:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06G4hNg008344 for ; Sun, 6 Jan 2002 08:04:43 -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 IAA06182 for ; Sun, 6 Jan 2002 08:04:47 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07032 for ; Sun, 6 Jan 2002 08:04:45 -0800 (PST) Received: from jariws1 ([62.248.238.9]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020106160444.HCXG11987.fep01-app.kolumbus.fi@jariws1>; Sun, 6 Jan 2002 18:04:44 +0200 Message-ID: <009301c196cb$e5232de0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: References: <3C385531.8050606@nomadiclab.com> Subject: Re: [mobile-ip] A proposed MIPv6 security policy statement Date: Sun, 6 Jan 2002 18:05:00 +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 > If the BU is protected only > with return reachability (RR), the maximun lifetime > of the binding SHOULD NOT exceed MAX_RR_BU_LIFETIME minutes. Hmm... perhaps we should make this a MUST NOT? > If the BU is protected with cryptographically generated > addresses (CGA) or by stronger local means, e.g. by > employing AAA or a local PKI, the maximum lifetime of > the binding is a matter of local policy. > I think that statement might serve us in desiging the > MIPv6 security solution in such a way that it allows > flexibility of mechanisms without opening too many > vulnerabilities. This sounds pretty good in my opinion. In particular the limitation of binding cache entry lifetimes does help a lot towards reducing the effects of the future attack. In the past I have been very much worried that any 2-party decisions about "low" or "high" security levels in Mobile IP are not going to work very well. The reason for this is that the victims could be someone else than the 2 parties. For instance, if I'm at any place in the Internet routing infrastructure, I can pick a set of home networks and CNs that are on my different sides, and then initiate bombing attacks to victims through e.g. web streams opened at the CNs. (CoA test make this somewhat harder to do.) With the rules you wrote Pekka, the effects are further reduced a bit because the attacker has to stay in the routing infrastructure almost as long as he wants his attack to last. However, the third party attacks are still possible. (Draft-aura-mipv6-bu-attacks-00.txt describes also some Internet business issue with "low" and "high" security levels in section 6.2.) Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 11:22: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 LAA24390 for ; Sun, 6 Jan 2002 11:22:19 -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 JAA10905; Sun, 6 Jan 2002 09:21: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 IAA19637; Sun, 6 Jan 2002 08:21:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GKlNg008485 for ; Sun, 6 Jan 2002 08:20:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GKlW8008484 for mobile-ip-dist; Sun, 6 Jan 2002 08:20: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GKhNg008477; Sun, 6 Jan 2002 08:20:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23685; Sun, 6 Jan 2002 08:20:48 -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 JAA13958; Sun, 6 Jan 2002 09:20: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 g06GKgb06875; Sun, 6 Jan 2002 17:20:42 +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 RAA20993; Sun, 6 Jan 2002 17:20:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g06GKgQ10673; Sun, 6 Jan 2002 17:20:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061620.g06GKgQ10673@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Fri, 04 Jan 2002 20:10:17 +0200. <3C35F009.6020202@nomadiclab.com> Date: Sun, 06 Jan 2002 17:20:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > - to do better ingress filtering based on AAA for sites where there are > some mobile nodes (aka visited sites). Why do you assume that AAA would be used everywhere where there are mobile nodes? => this (to use AAA everywhere where there are mobile nodes) is the price to pay to have an alternative to bidirectional tunnels with home agents, i.e. to make mobile IPv6 better than mobile IPv4 with reverse tunneling (i.e. real world mobile IPv4). For example, if I am visiting with my friends at their place, why couldn't I just use their private WLAN to connect my wireless PDA to the Internet? => this is a problem of responsibility and trust between you, your friends and their ISP(s). You already have it for network access, with my proposal you only have a new "mobile node" option... If I could not use their private WLAN, I would consider that as a flaw in the design if the Internet. => there is a flaw in the laws of Economics: not everything is free for ever. Similarily, our local university campus provides open WLAN for anyone, for anyone to connect to the Internet. => same answer. It is so much simpler to run these kinds of networks without any kinds of authentication that they will continue to exist, even though many current open WLAN networks may turn into requiring some kind of authentication. => yes, there are still some bad guys in the world... But even when they start to require authentication and/or authorization, that authentication or authorization is more likely to be based on 802.1x or PANA than AAA, => I don't understand your argument: 802.1x or PANA are parts of an AAA system. and even if RADIUS/DIAMETER is used, the non-ISP connectivity providers are unlikely to be part of the AAA infrastruture. => I believe your argument is that all AAA systems are not instances of the AAA architecture. This is an AAA issue which is not in the scope of IPv6 and mobile WGs. For example, I run an open WLAN at my home, and even though I may require some kind of authentication in the future, it is very unlikely that I would run RADIUS or DIAMETER. => again this is a problem of trust and responsability. If your neighbors want to harm you, IMHO the wild Internet access provided by open WLAN is enough. So one day you'll secure it (or your ISP will ask you to secure it), this day the possibility to accommodate mobile nodes shall become an option. Thus, making your system to help at all, it would require that EVERYBODY ELSE FORBIDS Home Address Option altogether. => everybody else is better than everybody (:-). It is not only a mobile host that can send HAO, any host can send it. => this argument is mainly against BCE checks in CNs solution. If an intruder can break into 10 million poorly protected home PCs, they can be converted into MN looking devices that send fake HAOs. => our job is to make "they can be converted into MN looking devices" a detail, i.e. this adds no new major security threat. Sure the ISP can drop all packets containing HAO sent from their home customer sites, but that would break the ability to use your PDA/other device through your friend's WLAN while visiting at their place. => again the same answer. Do you see my point now? => BTW I have a friend with a private WLAN (not an open one, he uses WEP and a MAC address filter, i.e. common private WLAN security tools). When I visit him I use my laptop with a secure bidir tunnel to my office (I use SSH, in the best open WLAN example I know (IETF meetings) most of us use SSH or IPsec (or both)). I don't use real mobility because I don't know how to roam between private WLANs, i.e. this is a nomadic situation where I use two identities, a remote one using a secure bidir tunnel and a local one for short and/or local interactions like web browsing or printing. So if I understand the constraints with my proposal on private WLANs, they are not a good example. > - to do better anti-spoofing filtering for sites from where some mobile > nodes are (aka home sites). I do not argue with that part. You draft may well have some value protecting the home sites of MNs. => my concern is more sites that are not home sites (their anti-spoofing filtering must be enhanced, fortunately this is very easy). > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. As I said above, either you must assume that any site can host MNs (in addition to CNs), ---or--- you must forbid sending HAO containing packets from those sites that are assumed not tho host MNs. => I can't see a problem: they don't take the responsability, I don't trust them... I stress this idea and its relationship with network access control because the ingress filtering is not a reply to DDoS but a reply to source address spoofing: DDoS is still possible but sources can be traced back, i.e. know who has given the network access to attacker nodes. RFC 2827 summary finishes by this statement: It is the responsibility of all network administrators to ensure they do not become the unwitting source of an attack of this nature. My main point is that forbidding HAOs to be sent from the majority of the Internet would largely foil the purpose of Mobile IPv6. => I don't believe that because I don't assume the same things about mobile IPv6 applicability. My point is that almost every home will, in the future, be a potential site hosting MNs. => this is a point where we obviously disagree. > => this is very unrealistic because this forgets the third letter of AAA. > And of course this doesn't go well with the responsible use of the network > principle. Most homes do not even know about responsible use of network principle. => if they read the contract between them and their ISPs they should know. It is just that since you can buy an Apple Airport (or whatever) from your local shop, and set it up within minutes, that will happen. Actually, it is already happening in many places in the US and scandinavia. => I've already answered about private WLANs. Remember me setting up an WLAN access point at IPCN'2001 in Paris? => this was like IETF meetings: a typical nomadic environment, no need of real mobility because there was no other network to move to keeping connections. I believe the issue in in the *local* area, but with a public WWAN associated ISPs should manage a proper network access control, at least in order to implement the third A of AAA (:-). > Now, the point is that those are also exactly the organizations > that are most _unlikely_ to use advanced ingress filtering methods, > > => the solution in this case is just to filter out HAO, i.e. to refuse > mobile nodes. ... and what I am saying, such a practise is unreasonable and would severly restrict our possibility to use the future Internet. In other words, madating that ingress filtering MUST refuse HAO (unless special means is used to ensure that the Home Address is valid), besides being expensive and unrealistic, would result in MIPv6 being used only be the telecom vendors, not by the rest of us. => the only scenario where this can harm is a roaming from a public WWAN to a visited private LAN, do you agree? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 11:45:36 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24580 for ; Sun, 6 Jan 2002 11:45:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10503; Sun, 6 Jan 2002 08:44: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 IAA21367; Sun, 6 Jan 2002 08:44:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GhtNg008670 for ; Sun, 6 Jan 2002 08:43:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GhtZn008669 for mobile-ip-dist; Sun, 6 Jan 2002 08:43: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GhoNg008662; Sun, 6 Jan 2002 08:43:51 -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 IAA25161; Sun, 6 Jan 2002 08:43:55 -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 JAA05102; Sun, 6 Jan 2002 09:44:58 -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 g06Ghnb07750; Sun, 6 Jan 2002 17:43: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 RAA21198; Sun, 6 Jan 2002 17:43:50 +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 g06GhnQ10753; Sun, 6 Jan 2002 17:43:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061643.g06GhnQ10753@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: "Pekka Nikander" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Fri, 04 Jan 2002 20:56:48 +0200. <007101c19551$90358240$8a1b6e0a@arenanet.fi> Date: Sun, 06 Jan 2002 17:43: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: In your previous mail you wrote: > There is no constraint on sites where are the regular correspondent nodes > (aka correspondent domains) which should be the vast majority of sites. I am concerned that this would be an obstacle to deploying MIPv6: I couldn't put my node to network X because X will not get AAA within five years. => don't forget you still can use a bidirectional tunnel with your home agent, so this is a constraint for the standard mode of MIPv6, not the anti-optimized but optionaly really secure mode ((secure) bidir tunnel). We have already some problems with the (route) optimized mode, I believe we shouldn't like to lost standard mode too. Uh... there are legitimate uses for accounting and AAA but I really don't think we should impose configuration and AAA in all situations. There's plenty of examples where there is no business or security need for complicated configuration or even accounting. Such as closed company => there should be no security issue in a closed company or free university networks, => there is a problem for them but I don't believe this is very different than for the Internet access. A balance between the freedom and the responsability in case of problems has to be found. or my access-paid-by-visa WLAN. => I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made with WLANs). In this case the problem is very easy to use, even statically (i.e. with a home address bound to the VISA account). Of course I expect the mobile support will be in the offered service list, something we all like to get but perhaps is not understood by operators... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 11:59:05 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24714 for ; Sun, 6 Jan 2002 11:59:04 -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 IAA11812; Sun, 6 Jan 2002 08:58: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 IAA22153; Sun, 6 Jan 2002 08:58:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GvINg008860 for ; Sun, 6 Jan 2002 08:57:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GvIal008859 for mobile-ip-dist; Sun, 6 Jan 2002 08:57:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06Gv4Ng008833; Sun, 6 Jan 2002 08:57: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 IAA26497; Sun, 6 Jan 2002 08:57:09 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16241; Sun, 6 Jan 2002 08:57:07 -0800 (PST) Received: from jariws1 ([62.248.238.9]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020106165705.ZPFV24037.fep02-app.kolumbus.fi@jariws1>; Sun, 6 Jan 2002 18:57:05 +0200 Message-ID: <00c901c196d3$359f9040$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" Cc: "Pekka Nikander" , , References: <200201061643.g06GhnQ10753@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Sun, 6 Jan 2002 18:57:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => don't forget you still can use a bidirectional tunnel with your home > agent, so this is a constraint for the standard mode of MIPv6, > not the anti-optimized but optionaly really secure mode ((secure) bidir > tunnel). We have already some problems with the (route) optimized mode, > I believe we shouldn't like to lost standard mode too. AAA-based solution would allow you to keep the standard mode, but at a cost which would propably prevent some good size fraction of nodes from using the optimised mode. The BCE check solution allows you to keep the optimised mode in wide usage, but does force you to go back to bidirectional tunneling if you didn't do RO. Take your pick what is the right tradeoff here, but my preference is the last one. > or my access-paid-by-visa WLAN. > > => I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made > with WLANs). In this case the problem is very easy to use, even > statically (i.e. with a home address bound to the VISA account). > Of course I expect the mobile support will be in the offered service list, > something we all like to get but perhaps is not understood by operators... Right. You expect the support to be there. So, instead of me turning on MIPv6 when my code supports it and your code supports it, we have to wait five years before VISA deploys the technology for both of us. And for that, we get to pay a montly service fee! By the way, didn't we already decide that a global infrastructure linking people to their home addresses was out of the question? I don't think it matters whether the acronym for this infrastructure was PKI, DNS, or AAA? Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 11:59: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 LAA24728 for ; Sun, 6 Jan 2002 11:59:19 -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 IAA11924; Sun, 6 Jan 2002 08:58: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 IAA22232; Sun, 6 Jan 2002 08:58:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06GvFNg008857 for ; Sun, 6 Jan 2002 08:57:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06GvFoE008856 for mobile-ip-dist; Sun, 6 Jan 2002 08:57:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06Gv3Ng008826; Sun, 6 Jan 2002 08:57:03 -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 IAA26493; Sun, 6 Jan 2002 08:57:07 -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 IAA16240; Sun, 6 Jan 2002 08:57:06 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g06Gv4b08215; Sun, 6 Jan 2002 17:57:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA21331; Sun, 6 Jan 2002 17:57:04 +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 g06Gv4Q10837; Sun, 6 Jan 2002 17:57:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061657.g06Gv4Q10837@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Was Node Mobility a Requirement for IPng? In-reply-to: Your message of Fri, 04 Jan 2002 14:26:53 CST. <933FADF5E673D411B8A30002A5608A0E0152FC17@zrc2c012.us.nortel.com> Date: Sun, 06 Jan 2002 17:57:04 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Does anyone know if node mobility was a requirement for IPng during the debates among the proposals? => I believe it was but which kind of mobility? At least the current Mobile IPv4 situation, i.e. bidirectional tunnel between the mobile node and its home agent. If so was SIPP supposed to rely on MIPv6 to fullfill this requirement or are these really disjunct with MIPv6 being an add on. => I don't believe for SIPP but PIP has some support for mobility (look at the "Pip Near-term Arch" document section 14 "Host Mobility", some of us preciously kept some copies of it). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 12:34:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24985 for ; Sun, 6 Jan 2002 12:34: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 KAA21909; Sun, 6 Jan 2002 10:33: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 JAA25044; Sun, 6 Jan 2002 09:33:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06HWmNg009127 for ; Sun, 6 Jan 2002 09:32:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06HWmlq009126 for mobile-ip-dist; Sun, 6 Jan 2002 09: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06HWjNg009119 for ; Sun, 6 Jan 2002 09:32: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 JAA11214 for ; Sun, 6 Jan 2002 09:32:50 -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 JAA11047 for ; Sun, 6 Jan 2002 09:32:49 -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 g06HWkb17463 for ; Sun, 6 Jan 2002 18:32:46 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA21678 for ; Sun, 6 Jan 2002 18:32:46 +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 g06HWkQ11098 for ; Sun, 6 Jan 2002 18:32:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201061732.g06HWkQ11098@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sat, 05 Jan 2002 14:50:30 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C1A0@Esealnt861.al.sw.ericsson.se> Date: Sun, 06 Jan 2002 18:32:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: While I do believe that AAA will be available at some stage, in most networks, I still don't favour this solution because: - I firmly believe that an infrastructureless solution is the natural, scalable and more reliable way to go here. It is a natural continuation of the MIPv6 philosophy which is always e2e. => but can you describe an infrastructureless solution better than BCE checks by CNs (which work only for HAOs sent by MN with active bindings)? - Relying on ingress filtering at all for the HAO is not a good idea. => you've reversed the proposal. The issue is that HAOs defeat simple ingress filtering (and similar security features), the proposal just gets back ingress filtering (with all the technical and practical limitations of ingress filtering). Relying on some intermediate node to do something, when no one will ever have a clue about whether this node has done it or not, seems like the wrong approach to me. Basically this is telling the CN to accept packets, because the MIPv6 spec says (potentially if this approach is adopted) that ingress filtering was done at the sender's default router. Doesn't seem right. => first I never proposed to do ingress filtering at the sender's default router (this kind of job is more for a real firewall). Second you lost sight of the target: provide ingress filtering in presence of HAOs. - From a practical point of view, it will take a very long time before we can get the entire framework for AAAv6 finished. So if timing is a concern (I'm regularly reminded !) then it's probably a good idea not to delay the spec more than we have to. => this is not a problem, remember the target. Now we have no more to discuss if the ingress filtering with HAOs issue is an important issue (i.e. enough for drastic solutions) or not (i.e. just forget it): we have a workable (in the future) solution. - Looking at this from a different angle, does it really matter if the MN reverse tunnels to the HA ? => this is another issue. I believe we *must* keep this solution (so I insisted to have a short statement in the I-D about it). But I'd like to have a better standard mode (i.e. the triangular routing). The main obstacle was the ingress filtering issue, it is no more in the way. I mean, if the CN doesn't accept the BU, currently, there will be triangular routing. So, do we really know that reverse tunnelling will make the situation much worse ?? I don't know. => For security or simplicity the reverse tunneling is far better but triangular routing should be more efficient if the home agent is not in the path between the MN and the CN or if it is not very close to the MN or the CN (for instance for communication with CNs in the home site the bidir tunneling is better, and works with site-local addresses (consider the tunnel being an extension of the home site)). That's all from me. Needless to say, that I did write a draft on using AAA for generating keys for BU authentication, but frankly, after => I prefer to use AAA as a trusted third party and for the transport of security stuff for the BSA establishment before the home registration. investigating the CGA mechanisms, I won't pursue => the issue with CGA mechanisms is they seems to be encumbred by IPRs. the AAA option anymore. Infrastructureless solutions are much more scalable and easier to deploy IMHO. => AAA has never been a candidate for all cases. But when you have it IMHO you should use it. Today there is no discussion about the security of the home registration but AAA has its place there. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 6 13:43: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 NAA25420 for ; Sun, 6 Jan 2002 13:43: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 LAA02964; Sun, 6 Jan 2002 11:41: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 KAA29644; Sun, 6 Jan 2002 10:42:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06IfHNg009402 for ; Sun, 6 Jan 2002 10:41:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g06IfHqj009401 for mobile-ip-dist; Sun, 6 Jan 2002 10:41: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g06IfANg009386; Sun, 6 Jan 2002 10:41:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02879; Sun, 6 Jan 2002 10:41:16 -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 KAA20093; Sun, 6 Jan 2002 10:41:15 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 36971A; Sun, 6 Jan 2002 20:41:41 +0200 (EET) Message-ID: <3C389A41.4000702@nomadiclab.com> Date: Sun, 06 Jan 2002 20:41:05 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7+) Gecko/20020102 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201061620.g06GKgQ10673@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, I wrote: > Thus, making your system to help at all, it would require that > EVERYBODY ELSE FORBIDS Home Address Option altogether. Francis Dupont wrote: > => everybody else is better than everybody (:-). I think the main reason for our disagreement is that you mostly seem to think that MIPv6 will be employed by operators. I don't. If MIPv6 will ever become common, I certainly want to run my own MIPv6 Home Agent, in the same way I am running my own DNS server, my own SMTP server, etc. That is, the only service that I buy is IP connectivity, and I really really really want to have an Internet that allows you to buy IP connectivity, and provide all of the rest of the infrastructure yourself. I don't want to be part of a global AAA. [Personally, I would consider such a requirement fascist.] Now, returning to the real issue. I just want to second Jari Arkko's statement: A. We seem to agree that HAO may be dangerous since it potentially makes IP traceback more difficult. B. There seems to be two possible solutions: B.1 Make the Binding Cache hard state instead of a cache. That is, mandate that CN accepts HAO if and only if there is a corresponding binding in the binding cache. (Or, at minimum, that it keeps trace of received HAOs for traceback purposes.) B.2 Mandate that every ingress router everywhere in the Internet either checks that the HAO is legitimate, or drops it. That is, my (possibly flawed) understanding of your ingress filtering draft requires B.2. If B.2 was mandated, the CN could accept HAO and rely that it is authentic. On the B.1 case, on the other hand, it is the CN's responsibility to decide whether to rely on HAO or not. As far as I can see, that is the difference. As a practical result, B.1 allows anybody to use MIPv6 security protocols (whatever it will be), establish bindings, and use HAOs. B.2, on the other hand, would restrict where you can use BUs, and that your home agent must be part of the still-not-existing global AAA infrastructure so that you could use HAO. As a result, all the work that we have done with RR and CGA would be unnecessary, since you would mandate AAA, and while you are mandating it, you just could use it for basic MIPv6 security as well. Francis, if you insist to keep your opinion that B.2 with all its consequences is better, there is nothing I can do. On the other hand, if I have really misunderstood the practical consequences of your draft, please enlighten me, and explain in detail how you expect it to work so that MIPv6 route optimization could still be used by private persons and small organizations that are not part of the alledged global AAA infrastructure. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 04:24:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12240 for ; Mon, 7 Jan 2002 04:24:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21815; Mon, 7 Jan 2002 02:23: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 BAA22748; Mon, 7 Jan 2002 01:23:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g079MINg010282 for ; Mon, 7 Jan 2002 01:22:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g079MI1g010281 for mobile-ip-dist; Mon, 7 Jan 2002 01:22: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g079MFNg010274; Mon, 7 Jan 2002 01:22:15 -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 BAA22650; Mon, 7 Jan 2002 01:22:19 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06893; Mon, 7 Jan 2002 02:22:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g079MAb14981; Mon, 7 Jan 2002 10:22:10 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA02374; Mon, 7 Jan 2002 10:22: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 g079MAQ13141; Mon, 7 Jan 2002 10:22:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201070922.g079MAQ13141@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jari Arkko" cc: "Pekka Nikander" , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 06 Jan 2002 18:57:22 +0200. <00c901c196d3$359f9040$8a1b6e0a@arenanet.fi> Date: Mon, 07 Jan 2002 10:22: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: > => don't forget you still can use a bidirectional tunnel with your home > agent, so this is a constraint for the standard mode of MIPv6, > not the anti-optimized but optionaly really secure mode ((secure) bidir > tunnel). We have already some problems with the (route) optimized mode, > I believe we shouldn't like to lost standard mode too. AAA-based solution would allow you to keep the standard mode, but at a cost which would propably prevent some good size fraction of nodes from using the optimised mode. The BCE check solution allows you to keep the optimised mode in wide usage, but does force you to go back to bidirectional tunneling if you didn't do RO. Take your pick what is the right tradeoff here, but my preference is the last one. => your argument is based on the bet that full CN function will be implemented by everybody and enabled everywhere. IMHO this is a very dangerous bet... > or my access-paid-by-visa WLAN. > > => I believe this is not a WLAN but a network of WLANs (i.e. a WWAN made > with WLANs). In this case the problem is very easy to use, even > statically (i.e. with a home address bound to the VISA account). > Of course I expect the mobile support will be in the offered service list, > something we all like to get but perhaps is not understood by operators... Right. You expect the support to be there. => the "even statically" is only an example of what can be done. So, instead of me turning on MIPv6 when my code supports it and your code supports it, => this (when your code supports it) is the real question... we have to wait five years before VISA deploys the technology for both of us. => not VISA, our ISPs (and far less than five years). And for that, we get to pay a montly service fee! => if it is VISA, we'll pay a monthly fee for no service (:-)! By the way, didn't we already decide that a global infrastructure linking people to their home addresses was out of the question? => not exactly, the key term is "rely on". I don't think it matters whether the acronym for this infrastructure was PKI, DNS, or AAA? => I agree but it is not forbidden to get advantages of it, only to rely on it. As we don't rely on ingress filtering for defense against DDoS, I can't see a problem to propose to use AAA in order to improve ingress filtering. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 05:53: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 FAA12790 for ; Mon, 7 Jan 2002 05:53:09 -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 CAA24502; Mon, 7 Jan 2002 02:52:19 -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 CAA00883; Mon, 7 Jan 2002 02:52:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ApENg010560 for ; Mon, 7 Jan 2002 02:51:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07ApE1E010559 for mobile-ip-dist; Mon, 7 Jan 2002 02:51: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ApANg010552; Mon, 7 Jan 2002 02:51:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17311; Mon, 7 Jan 2002 02:51:16 -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 DAA01834; Mon, 7 Jan 2002 03:51:15 -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 g07Ap9b26741; Mon, 7 Jan 2002 11:51: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 LAA04055; Mon, 7 Jan 2002 11:51: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 g07Ap8Q13420; Mon, 7 Jan 2002 11:51:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 06 Jan 2002 20:41:05 +0200. <3C389A41.4000702@nomadiclab.com> Date: Mon, 07 Jan 2002 11:51:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I think the main reason for our disagreement is that you mostly seem to think that MIPv6 will be employed by operators. I don't. If MIPv6 will ever become common, I certainly want to run my own MIPv6 Home Agent, in the same way I am running my own DNS server, my own SMTP server, etc. That is, the only service that I buy is IP connectivity, and I really really really want to have an Internet that allows you to buy IP connectivity, and provide all of the rest of the infrastructure yourself. I don't want to be part of a global AAA. [Personally, I would consider such a requirement fascist.] => first the term requirement is too strong, second the recommendation for AAA in home domains is for your protection because without remote network access control if a bad guy tries to use an address in your (home) prefix you can't just reply "no, this is mine". Now, returning to the real issue. I just want to second Jari Arkko's statement: A. We seem to agree that HAO may be dangerous since it potentially makes IP traceback more difficult. => we agree. B. There seems to be two possible solutions: B.1 Make the Binding Cache hard state instead of a cache. That is, mandate that CN accepts HAO if and only if there is a corresponding binding in the binding cache. (Or, at minimum, that it keeps trace of received HAOs for traceback purposes.) B.2 Mandate that every ingress router everywhere in the Internet either checks that the HAO is legitimate, or drops it. => in both cases the term mandate is far too strong. That is, my (possibly flawed) understanding of your ingress filtering draft requires B.2. If B.2 was mandated, the CN could accept HAO and rely that it is authentic. On the B.1 case, on the other hand, it is the CN's responsibility to decide whether to rely on HAO or not. => I agree, the whole issue is where to put the responsability (or who trust to). As far as I can see, that is the difference. As a practical result, B.1 allows anybody to use MIPv6 security protocols (whatever it will be), establish bindings, and use HAOs. B.2, on the other hand, would restrict where you can use BUs, => this is not a restriction: the responsability is put on senders, so we trust (or filter out) senders. This is exactly the same for the current ingress filtering: we trust source address because ISPs say we can (they may use a tool which makes source address spoofing impossible). and that your home agent must be part of the still-not-existing global AAA infrastructure so that you could use HAO. => as I've said, this *recommendation* is for your protection: without remote network access control you can be a target... As a result, all the work that we have done with RR and CGA would be unnecessary, since you would mandate AAA, and while you are mandating it, you just could use it for basic MIPv6 security as well. => no, I never propose to base MIPv6 security on AAA. If I believe that AAA is a fine alternative for MN-HA security (I tried full IPsec, this works but this is so heavy and inefficient than near everything else should be better :-), but AAA for MN-CN security is possible only in some very special cases. Francis, if you insist to keep your opinion that B.2 with all its consequences is better, there is nothing I can do. On the other hand, if I have really misunderstood the practical consequences of your draft, please enlighten me, and explain in detail how you expect it to work so that MIPv6 route optimization could still be used by private persons and small organizations that are not part of the alledged global AAA infrastructure. => first, kill the idea to use (or to rely on) AAA for the general MN-CN case. Second, don't forget the target: we have a nasty attack, DDoS with source address spoofing, and a reply, ingress filtering, which is not used by every ISPs and is not very efficient against DDoSs (just because it is a reply to source address spoofing, not DDoSs themselves). HAO may be dangerous since it potentially makes IP traceback (ingress filtering is the only deploied tool which provides IP traceback) more difficult. The idea is to improve ingress filtering in order to get back the previous situation (the one before HAO). The obvious solution is to make the knowledge of bindings available to ingress filtering devices. My proposal is to use the local network access control in order to carry this knowledge from MNs to ingress filtering devices, this assumes only that there is a local network access control (of any kind) and ingress filtering devices are between the Internet access and the site, and have enough capabilities (i.e. the firewall(s) which already filter(s) inbound traffic). If there is a AAA infrastructure and if both the local and remote network access controls are connected to this infrastructure you have two extra benefits: the remote network access control works locally and ingress filtering devices can verify bindings: without an AAA connection between local/visited and remote/home domain, ingress filtering devices can only check HAOs against registered bindings (IMHO this is enough to make spoofing based on HAOs unattractive). With an AAA connection, bindings can be verifed when they are declared/registered. This is a far stronger property, we'd like to get it in an ideal world (a world where there are AAA infrastructures :-). In summary participation to a global AAA infrastructure is not needed, it has just many new advantages (and should be discussed in the AAA WG mailing list, not here). Regards Francis.Dupont@enst-bretagne.fr PS: I'll add in the draft a statement against BCE checks (they work only for mobility) and an extra space between the "network access control" and the "AAA" paragraphs (showing there is no dependency). From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 08:28: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 IAA14052 for ; Mon, 7 Jan 2002 08:28:11 -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 GAA00763; Mon, 7 Jan 2002 06:27: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 FAA12548; Mon, 7 Jan 2002 05:27:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07DQRNg010852 for ; Mon, 7 Jan 2002 05:26:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07DQRIn010851 for mobile-ip-dist; Mon, 7 Jan 2002 05:26: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07DQONg010844 for ; Mon, 7 Jan 2002 05:26:24 -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 FAA12481 for ; Mon, 7 Jan 2002 05:26:28 -0800 (PST) Received: from web14605.mail.yahoo.com (web14605.mail.yahoo.com [216.136.224.85]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA07483 for ; Mon, 7 Jan 2002 06:27:35 -0700 (MST) Message-ID: <20020107132627.64616.qmail@web14605.mail.yahoo.com> Received: from [203.197.117.226] by web14605.mail.yahoo.com via HTTP; Mon, 07 Jan 2002 05:26:27 PST Date: Mon, 7 Jan 2002 05:26:27 -0800 (PST) From: Durga Prasad Pandey Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> 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 Could you please direct me to some online begineer's tutorial/other resaource on Mobile IP. I will appreciate your kind effort. Thanks Durga ===== Believe in yourself I do. Assistant Online Editor: ACM Crossroads Magazine www.acm.org/crossroads/ VISIT MY HOMEPAGE AT : www.geocities.com/dpsmiles VIEW MY pics AT: www.geocities.com/dpsmiles/dp1.jpg __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 09:09: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 JAA14742 for ; Mon, 7 Jan 2002 09:09:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20373; Mon, 7 Jan 2002 07:07: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 GAA16831; Mon, 7 Jan 2002 06:08:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07E7PNg010983 for ; Mon, 7 Jan 2002 06:07:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07E7Pim010982 for mobile-ip-dist; Mon, 7 Jan 2002 06:07:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07E7LNg010975 for ; Mon, 7 Jan 2002 06:07:21 -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 GAA16961 for ; Mon, 7 Jan 2002 06:07:27 -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 GAA12850 for ; Mon, 7 Jan 2002 06:07:26 -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 JAA14533; Mon, 7 Jan 2002 09:07:23 -0500 (EST) Message-Id: <200201071407.JAA14533@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-le-mobileip-dh-01.txt Date: Mon, 07 Jan 2002 09:07: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: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Dynamic Diffie Hellman based Key Distribution for Mobile IPv6 Author(s) : S. Faccin, F. Le Filename : draft-le-mobileip-dh-01.txt Pages : 9 Date : 04-Jan-02 Mobile IP [1] requires several security associations: the Mobile Node must share a security association with its Home agent and its Correspondent Nodes to send the binding update; these messages must be authenticated to prevent potential denial of service attacks [2]. The MN and the Home Agent can have a static security association, established at the configuration time, but the case of the Correspondent Node is more complex since it cannot be assumed that the MN and the CN have any pre-established security association. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-le-mobileip-dh-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-le-mobileip-dh-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-le-mobileip-dh-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: <20020104143541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-le-mobileip-dh-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-le-mobileip-dh-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020104143541.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 09:21: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 JAA15050 for ; Mon, 7 Jan 2002 09:21:28 -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 HAA27634; Mon, 7 Jan 2002 07:20: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 GAA05259; Mon, 7 Jan 2002 06:20:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EJDNg011111 for ; Mon, 7 Jan 2002 06:19:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07EJDXO011110 for mobile-ip-dist; Mon, 7 Jan 2002 06:19:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EJANg011103 for ; Mon, 7 Jan 2002 06:19:10 -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 GAA03700 for ; Mon, 7 Jan 2002 06:19:15 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26996 for ; Mon, 7 Jan 2002 07:18:56 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g07EJDJ02959 for ; Mon, 7 Jan 2002 15:19:13 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 07 15:19:09 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:10:18 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1A1@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] RE: Is RR only enough ? Date: Mon, 7 Jan 2002 15:18: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: Hi Erik, [Also Pekka N, the attack we've been discussing here is the same one you outlined in your mail] > > => Well, this is a much simpler attack. That is, assuming > > the MITM is in the right location, this attack > > is easily done by one BU and steals all connections. > > So your point is that the attack program that a hacker > needs to write > would be significantly shorter and easier to develop? > You're probably right, but I don't think that means there > is more harm - once > the attack software is written and distributed to the > attackers out there > they can cause the same amount of harm. => You're right, sorry I wrote the last mail in a haste and should have clarified my point a lot more. I see some common assumptions between the attacks you mention in 'today's Internet' and the attack I'm referring too. These common assumptions are basically that MITM is in the right location. Now there are differences between the two types of attacks (the one you refer to and the one I mentioned on this thread). The 2 major differences are: 1. You implied that today's MITM attacks (or at least the ones you mentioned in this thread) can be avoided be e2e encryption. The attack I'm referring to can not be avoided by e2e encryption. 2. If I understood you correctly, you were implying that the MITM in the scenario you mentioned is intercepting packets. I.e. the MITM has the ability to receive the packets, modify them and hence cause a situation where both a MN-CN connection 'goes through him'. On the other hand, in the attack I'm referring to, the MITM only needs to 'see' the packets addressed to the Home address of the MN. He doesn't need to intercept any packets. So lets consider this scenario: - Bad Guy is on the path between the CN and the HA. For simplicity lets assume Bad Guy is on an ethernet. - Bad Guy forms an address based on the RA on that ethernet. Bad Guy also puts his card in promiscuous mode. - Bad Guy sees one packet addressed to the MN's Home address. From that he gets the CN's address and the MN's home address (he could have the home address before anyway, it would be public knowledge). - No Bad Guy can launch this attack regardless of whether e2e security is used between the MN and CN. So I think the significant differences between our attack scenarios are (1) and (2). In particular, I believe (1) is a dangerous difference. Sorry for not making myself clearer before. > > > Furthermore, if the MITM happens to be close enough > > to the HA, he can do this attack for all MNs served > > by that HA (assuming that he is close enough so > > that most of the traffic addressed to the HA will > > be seen by him). > > Yes, but this doesn't seem any more diffenrent than an > attacker close to > the border router of e.g. sun.com being able to be a MiTM for most > of the traffic to/from all of Sun. => Yep. You're right > > > I would assume that in the cases you mention, the > > MITM would have to do more work to be able > > to steal a TCP connection for example. Actually > > I don't know how the MITM can 'steal' the TCP > > connection in the scenario you mention. Please > > note that I'm talking about stealing the existing > > conneciton (receiving the information addressed > > to the MN), rather than modifying packets and > > causing the connection to be dropped. > > I depends what the attacker want to do. > For instance with the TCP packet stream in both directions > the attacker > can easily respond to a HTTP get from the MN to the CN which > completely different data, while consuming the actual HTTP > response from the > CN. > > In the TCP MiTM case I don't think a DoS attack is needed on the MN. > The attacker on path is presumably capable of supressing > packets from > being delivered as was as injecting its own (spoofed) packets. => Here is why I think you imply that the attacker can 'receive' packets or intercept them. I don't know how to assess whether an attack is significantly worse than another, perhaps someone can point me to some general guidelines, but AFAICS, this attack (I mention above) seems to be significantly different from the ones existing today. Just to overload this email a bit, I'd like to suggest that IF all agree that this attack is significantly different from today's attacks we can choose between two options I have in mind: - CGAs combined with RR as one obvious option - Extending BU3WAY or BUSEC to make them BU4WAY :) So in this case the MN would send 'half' the secret through the HA, and the other half directly from its CoA. The CN would also reply in both paths (i.e. one to the Home address and one to the CoA). One assumption: ingress filtering on source addresses is widely used. Based on this suggestion and the assumption above, the attacker will not be able to use the MN's Home address as a source address since the packet will be dropped by ingress filtering. I don't know if this is a realistic scenario (assuming ingress filtering everywhere). But... just a thought. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 09:28:40 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15269 for ; Mon, 7 Jan 2002 09:28:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23773; Mon, 7 Jan 2002 06:27:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06262; Mon, 7 Jan 2002 06:27:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EQhNg011253 for ; Mon, 7 Jan 2002 06:26:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07EQhDo011252 for mobile-ip-dist; Mon, 7 Jan 2002 06:26:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EQeNg011245 for ; Mon, 7 Jan 2002 06:26: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 GAA18689 for ; Mon, 7 Jan 2002 06:26:45 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04050 for ; Mon, 7 Jan 2002 07:26:45 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g07EQiJ12395 for ; Mon, 7 Jan 2002 15:26:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 07 15:26:43 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:17:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1A2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Hesham Soliman (ERA)" , "'Erik Nordmark'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Mon, 7 Jan 2002 15:26:25 +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: Pekka, > On the question of whether RR alone could provide security > that is in par with IPv4 security, I think I have came up > with an attack scenario that RR alone does not block (see > below). => Yes I think we're talking about the same attack. But I'm not sure about your assumption of the BSA. However, this attack is certainly fairly far fetched, > and I _personally_ could imagine that being vulnerable to > this one _might_ be acceptable. => I don't know what the odds are, but IMO the entire security discussion should be held on a certain level of abstraction that allows the chosen mechanism to survive unexpected and future scenarios. > The attack scenario: > > Let us consider an attacker A, a corrensponding node CN, and > a pre-selected mobile node MN whose home address is HoA. > Now, A has decided to steal all traffic that CN will > initiate towards MN. To do so, it somehow arranges itself > _once_ to the path between CN and MN's HA. It may do this, > for example, by visiting the network where CN is located, > where MN's HA is located, or any network in between. => Yes > > While being at the path between CN and MN's HA, the attacker > creates a binding (and a corresponding BSA) at CN. This will > succeed, since A knows MN's home address and it can foil the > RR test. As a result, CN believes that MN is currently located > at the adddress given by A, and therefor whenever it sends > packets to MN, it will send them to the attacker. Thus, A > is able to steal all connections initiated by CN towards MN. > Furthermore, if CN does not check the return routability > of the MN's home address if there is already an existing BSA, > then the attacker can keep up the faulty binding as long as it > wishes, simply by renewing the binding and BSA periodically. > To renew, it no longer needs to be at the path between the CN > and the MN's HA. => This is where I'm not sure we agree. I think if we do RR, we most definitely would not want to have a BSA. The reason: Exactly this scenario you mention. Actually, I'm not sure if Erik and Mike intentionally did so in their proposals, but that was my assumption. I agree with the intial part of the attack, but I don't think the BSA should be formed and hence the attack is only limited to the time where the atacker is still on the CN-HA path. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 09:38:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15546 for ; Mon, 7 Jan 2002 09:38:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07563; Mon, 7 Jan 2002 07:37: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 GAA07509; Mon, 7 Jan 2002 06:37:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EZoNg011411 for ; Mon, 7 Jan 2002 06:35:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07EZoki011410 for mobile-ip-dist; Mon, 7 Jan 2002 06:35: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EZkNg011403 for ; Mon, 7 Jan 2002 06:35:46 -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 GAA19670 for ; Mon, 7 Jan 2002 06:35:50 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06246 for ; Mon, 7 Jan 2002 07:35:31 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g07EZmK06445 for ; Mon, 7 Jan 2002 15:35:48 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 07 15:35:47 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:26:56 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1A4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jari Arkko'" , Pekka Nikander , mobile-ip@sunroof.eng.sun.com Cc: "Hesham Soliman (ERA)" , "'Erik Nordmark'" Subject: [mobile-ip] RE: A threat RR doesn't solve and that doesn't seem to exist in I Pv4 Date: Mon, 7 Jan 2002 15:35:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I agree that this attack exists and seems to be beyond what regular > IPv4 holes allowed. > > There seems to be a few differences with respect to v6+RR vs. v4. > What Pekka describes is an attack where the attacker can move > the effect of the attack forwards in time. => Yes but only if the attacker is still on the CN-HA path. I didn't think any proposals were suggesting BSA establishment with RR only, but I might be severely wrong (it has happened :)) Anyway, it is good yto document this assumption as Pekka suggested in his text. > > As for the significance of Pekka's and other attacks, I'm not sure > what to say yet. It does seem bad that one has to worry about > past breaches and not just the current state of the > network. On the other > hand, rules about maximum BCE lifetimes may help here. => I think, more importantly, rules about when a BSA can be established will provide the answers. That is, is the chosen method secure enough to result in a BSA between the MN (which maybe an ttacker!) and CN ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 09:53:05 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16043 for ; Mon, 7 Jan 2002 09:53: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 GAA02842; Mon, 7 Jan 2002 06:51: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 GAA09136; Mon, 7 Jan 2002 06:51:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EoONg011558 for ; Mon, 7 Jan 2002 06:50:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07EoNiO011556 for mobile-ip-dist; Mon, 7 Jan 2002 06:50:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07EoKNg011548 for ; Mon, 7 Jan 2002 06:50:20 -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 GAA09009 for ; Mon, 7 Jan 2002 06:50:25 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12612 for ; Mon, 7 Jan 2002 07:51:30 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g07EoNK12050 for ; Mon, 7 Jan 2002 15:50:23 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jan 07 15:50:22 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:50:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1A6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jari Arkko Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Mon, 7 Jan 2002 15:49:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => I believe this is not a WLAN but a network of WLANs > (i.e. a WWAN made > with WLANs). In this case the problem is very easy to use, even > statically (i.e. with a home address bound to the VISA account). => I agree you can still use it, but definitely not in this way. Home address is bound to the HA and NOT the AAAH server. Please let's not go down the MIPv4-AAA-wedding road ! I could have my HA@home and visa paying my access bills. No need for Visa to know my Home address. They should know my identity of course, NAI, IMSI, credit card number ....etc but absolutely no need to know my Home address, which I can change regularly. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 11:32:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19535 for ; Mon, 7 Jan 2002 11:32:38 -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 JAA27929; Mon, 7 Jan 2002 09:31: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 IAA05242; Mon, 7 Jan 2002 08:31:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07GU8Ng011886 for ; Mon, 7 Jan 2002 08:30:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07GU8Ob011885 for mobile-ip-dist; Mon, 7 Jan 2002 08:30: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07GU2Ng011870; Mon, 7 Jan 2002 08:30:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22646; Mon, 7 Jan 2002 08:30:05 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02401; Mon, 7 Jan 2002 09:30:36 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g07GT9X28639; Mon, 7 Jan 2002 18:29:09 +0200 Date: Mon, 7 Jan 2002 18:29:09 +0200 (EET) From: Pekka Savola To: cc: Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201041612.g04GCaQ03314@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, 4 Jan 2002, Francis Dupont wrote: > About section 2 on Correspondent Nodes; could you elaborate in the > document why exactly solution is too drastic? > > => because this gives no choice between bidirectional tunnel and > route optimization, so in some cases mobile IPv6 becomes far less > attractive. The real impact depends on how mobile IPv6 is used, > in fact one can argue that bidirectional tunnels are enough, but > I don't believe that mobile-ip list members will agree... Nothing prevents from applying some kind of RR tests to HAO (without BU) use too. The HAO implementation would just be a .. little .. more complicated.. but then again it hasn't been defined in the spec anyway. > Note that BCE check is not > the only way to ensure legitimity of HAO: if it's secured by AH, it's ok; > if some SUCV/.. weak authentication method is used, it's probably also ok; > the same might even apply to return routability. It's too early to crush > CN solutions. > > => these CN solutions have the same cost than full routing optimization, > so I consider them as BCE check variants. See above. > (I think the solution for HAO should most likely consist of two separate, > "strong-enough" layers, one mandated at CN, one possible at firewalls, but > that's not the topic of this draft). > > => one mandated at CN == no third choice. One must be available for CN, because CN cannot trust the source if it isn't authenticated or in some form authorized. [snip rest] I won't get into this more here, because I must say I agree almost 100% with comments from Pekka Nikander, Jari Arkko et al. (You should be very, very afraid if you ever venture in Finland, Francis ;-). One point I've made before: perhaps the check is trivial, but IMO _the most important thing_ is that *every* site could easily check from incoming packets with HAO, whether the HAO is is spoofed to belong to *destination site in question* or some other site the destination site trust at some level. This form of spoofing can be protected against now. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 12:25: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 MAA21595 for ; Mon, 7 Jan 2002 12:25:23 -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 KAA10084; Mon, 7 Jan 2002 10:24:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15770; Mon, 7 Jan 2002 09:24:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07HNaNg012144 for ; Mon, 7 Jan 2002 09:23:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07HNaVN012143 for mobile-ip-dist; Mon, 7 Jan 2002 09:23:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07HNTNg012128; Mon, 7 Jan 2002 09:23:29 -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 JAA04110; Mon, 7 Jan 2002 09:23:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17974; Mon, 7 Jan 2002 09:23:33 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g07HNVb26193; Mon, 7 Jan 2002 18:23:31 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA12500; Mon, 7 Jan 2002 18:23:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g07HNUQ15139; Mon, 7 Jan 2002 18:23:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201071723.g07HNUQ15139@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 18:29:09 +0200. Date: Mon, 07 Jan 2002 18:23:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Nothing prevents from applying some kind of RR tests to HAO (without BU) use too. The HAO implementation would just be a .. little .. more complicated.. but then again it hasn't been defined in the spec anyway. => I believe the ".. little .. more complicated.." is a joke, isn't it? > (I think the solution for HAO should most likely consist of two > separate, "strong-enough" layers, one mandated at CN, one possible > at firewalls, but that's not the topic of this draft). > > => one mandated at CN == no third choice. One must be available for CN, because CN cannot trust the source if it isn't authenticated or in some form authorized. => again, if you rely on routing optimization (RO) or something equivalent then you close the door to the third choice (aka triangular routing). IMHO HAO has nothing to do with RO: if for sanity HAOs can be checked against the BCE (i.e. if they don't match something is wrong), the only way to reply to the iDDoS threat by this way is to mandate the check and to forbid HAOs without RO. [snip rest] I won't get into this more here, because I must say I agree almost 100% with comments from Pekka Nikander, Jari Arkko et al. (You should be very, very afraid if you ever venture in Finland, Francis ;-). => so you agree to kill triangular routing? One point I've made before: perhaps the check is trivial, but IMO _the most important thing_ is that *every* site could easily check from incoming packets with HAO, whether the HAO is is spoofed to belong to *destination site in question* or some other site the destination site trust at some level. => so the easiest solution for someone which doesn't want to implement or enable RO is just to drop HAOs. In France we have an expression for that: "la politique du pire". Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 13:37: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 NAA23874 for ; Mon, 7 Jan 2002 13:37: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 KAA20867; Mon, 7 Jan 2002 10:36:47 -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 KAA04654; Mon, 7 Jan 2002 10:36:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07IZuNg012501 for ; Mon, 7 Jan 2002 10:35:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07IZuw1012500 for mobile-ip-dist; Mon, 7 Jan 2002 10:35:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07IZpNg012493 for ; Mon, 7 Jan 2002 10:35:52 -0800 (PST) Received: from lillen ([129.146.99.209]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g07IZp305518; Mon, 7 Jan 2002 19:35:51 +0100 (MET) Date: Mon, 7 Jan 2002 19:33:10 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Re: A threat RR doesn't solve and that doesn't seem to exist in IPv4 To: Pekka Nikander Cc: mobile-ip@sunroof.eng.sun.com, hesham.soliman@era.ericsson.se, "'Erik Nordmark'" In-Reply-To: "Your message with ID" <3C385158.8010201@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: > The attack scenario: > > Let us consider an attacker A, a corrensponding node CN, and > a pre-selected mobile node MN whose home address is HoA. > Now, A has decided to steal all traffic that CN will > initiate towards MN. To do so, it somehow arranges itself > _once_ to the path between CN and MN's HA. It may do this, > for example, by visiting the network where CN is located, > where MN's HA is located, or any network in between. > > While being at the path between CN and MN's HA, the attacker > creates a binding (and a corresponding BSA) at CN. This will > succeed, since A knows MN's home address and it can foil the > RR test. As a result, CN believes that MN is currently located > at the adddress given by A, and therefor whenever it sends > packets to MN, it will send them to the attacker. Thus, A > is able to steal all connections initiated by CN towards MN. > Furthermore, if CN does not check the return routability > of the MN's home address if there is already an existing BSA, > then the attacker can keep up the faulty binding as long as it > wishes, simply by renewing the binding and BSA periodically. > To renew, it no longer needs to be at the path between the CN > and the MN's HA. Yes, this is a valid attack when there is a BSA. If the BSA can be refreshed without re-verifying the RR property then the BSA and binding can be maintained forever without the attacker having to reappear on the path. > But I certainly think there seems to be reason to make CGAs a > preferred and recommended practise, and to be recommended that > bindings that have not been protected with CGA should have relatively > short lifetime, and not be renewable without full RR test upon renewal. A possible approach to limit the potential damage would be to have some reasonable lifetime for the BSA (1 hour? 1 day?) and require that when the BSA is refreshed (new keys etc) the RR test is invoked. That approach would prevent an attacker for gaining access forever. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 13:50:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24516 for ; Mon, 7 Jan 2002 13:50:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15332; Mon, 7 Jan 2002 11:49:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07891; Mon, 7 Jan 2002 10:49:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ImaNg012647 for ; Mon, 7 Jan 2002 10:48:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07ImaAI012646 for mobile-ip-dist; Mon, 7 Jan 2002 10:48: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07ImRNg012628; Mon, 7 Jan 2002 10:48:28 -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 KAA07589; Mon, 7 Jan 2002 10:48:33 -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 LAA03911; Mon, 7 Jan 2002 11:48:33 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07ImVt28740; Mon, 7 Jan 2002 12:48:31 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 12:46:43 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01530670@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Was Node Mobility a Requirement for IPng? Date: Mon, 7 Jan 2002 12:47:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C197AB.C695EA80" Sender: owner-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_01C197AB.C695EA80 Content-Type: text/plain; charset="iso-8859-1" Francis, Thanks for the insight. These mobility and namespace things seem to keep coming up over and over in different groups with different names. Might as well call a duck a duck. I was just wondering if they affected the choice at all and if SIPP and MIPv6 were supposed to equal the functionality somehow. The add-on syndrome has proven to not give us ubiquity of any sort which IMO is what you want for a network layer. Thanks again, Glenn > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Sunday, January 06, 2002 10:57 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Was Node Mobility a Requirement for IPng? > > > Does anyone know if node mobility was a requirement for > IPng during the > debates among the proposals? > > => I believe it was but which kind of mobility? At least the current > Mobile IPv4 situation, i.e. bidirectional tunnel between the > mobile node > and its home agent. > > If so was SIPP supposed to rely on MIPv6 to fullfill this > requirement or are > these really disjunct with MIPv6 being an add on. > > => I don't believe for SIPP but PIP has some support for mobility > (look at the "Pip Near-term Arch" document section 14 "Host Mobility", > some of us preciously kept some copies of it). > > Regards > > Francis.Dupont@enst-bretagne.fr > ------_=_NextPart_001_01C197AB.C695EA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Was Node Mobility a Requirement for IPng? =

Francis,

Thanks for the insight. These mobility and namespace = things seem to keep coming up over and over in different groups with = different names. Might as well call a duck a duck. I was just wondering = if they affected the choice at all and if SIPP and MIPv6 were supposed = to equal the functionality somehow. The add-on syndrome has proven to = not give us ubiquity of any sort which IMO is what you want for a = network layer.

Thanks again,

Glenn

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@en= st-bretagne.fr]
> Sent: Sunday, January 06, 2002 10:57 AM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: ipng@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Was Node Mobility a = Requirement for IPng?
>
>
>    Does anyone know if node = mobility was a requirement for
> IPng during the
>    debates among the proposals? =
>    
> =3D> I believe it was but which kind of = mobility? At least the current
> Mobile IPv4 situation, i.e. bidirectional = tunnel between the
> mobile node
> and its home agent.
>
>    If so was SIPP supposed to = rely on MIPv6 to fullfill this
> requirement or are
>    these really disjunct with = MIPv6 being an add on.
>    
> =3D> I don't believe for SIPP but PIP has = some support for mobility
> (look at the "Pip Near-term Arch" = document section 14 "Host Mobility",
> some of us preciously kept some copies of = it).
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>

------_=_NextPart_001_01C197AB.C695EA80-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 13:58: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 NAA24735 for ; Mon, 7 Jan 2002 13:58:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01437; Mon, 7 Jan 2002 10:57: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 KAA11095; Mon, 7 Jan 2002 10:57:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07IvCNg012805 for ; Mon, 7 Jan 2002 10:57:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07IvBGN012804 for mobile-ip-dist; Mon, 7 Jan 2002 10:57: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07Iv7Ng012797 for ; Mon, 7 Jan 2002 10:57:08 -0800 (PST) Received: from lillen ([129.146.99.209]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g07Iv4307542; Mon, 7 Jan 2002 19:57:04 +0100 (MET) Date: Mon, 7 Jan 2002 19:54:23 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] RE: Is RR only enough ? To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C1A1@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > 1. You implied that today's MITM attacks (or at > least the ones you mentioned in this thread) > can be avoided be e2e encryption. The attack I'm > referring to can not be avoided by e2e encryption. If e2e security is done right any MiTM attack would just be capable of performing a DoS attack by preventing communication. "Done right" assumes that the peers some how know the identity of each other and the public keys associated with those identities and that's what is required to be able to securely be able to communicate with a known entity. > 2. If I understood you correctly, you were implying > that the MITM in the scenario you mentioned is > intercepting packets. I.e. the MITM has the ability > to receive the packets, modify them and hence cause > a situation where both a MN-CN connection 'goes > through him'. On the other hand, in the attack I'm > referring to, the MITM only needs to 'see' the > packets addressed to the Home address of the MN. > He doesn't need to intercept any packets. Yes, there is such a subtle difference. But Maruc Leech said in the MobileIP meeting in SLC that for on-path attacks we shouldn't worry about the distiction between an active and a passive attacker. This seem to make sense to me - if somebody uses ARP/ND spoofing to gain access on multi-access links or hacks a switch/router in the path it would be easy for them to modify packets. > So lets consider this scenario: > > - Bad Guy is on the path between the CN and the HA. > For simplicity lets assume Bad Guy is on an ethernet. > > - Bad Guy forms an address based on the RA on that > ethernet. Bad Guy also puts his card in promiscuous > mode. > > - Bad Guy sees one packet addressed to the MN's Home > address. From that he gets the CN's address and > the MN's home address (he could have the home address > before anyway, it would be public knowledge). > > - No Bad Guy can launch this attack regardless of whether > e2e security is used between the MN and CN. But without binding updates the additional piece that is needed in today's internet is to spoof the ARP packets for the routers' and victim's IP addresses and now all packets will go through the attacker. There is a subtle difference in that an ARP spoofing attack might be more "visible" than snooping the wire - if an admin happens to look at the content of the ARP cache during the attack the admin might observe that it doesn't look like the router's Ethernet address. But an admin is pretty unlikely to look. > I don't know how to assess whether an attack is > significantly worse than another, perhaps someone > can point me to some general guidelines, but AFAICS, > this attack (I mention above) seems to be significantly > different from the ones existing today. I agree there are differences but I find them rather subtle. I don't have a magic way to tell the difference other than by trying to put myself in the shoes of a determined attacker. If the attacker can get access to a multi-access link in the path what can be done? If the attacker can break a switch/router in the path what can be done? > Just to overload this email a bit, I'd like to suggest > that IF all agree that this attack is significantly > different from today's attacks we can choose between > two options I have in mind: > > - CGAs combined with RR as one obvious option I agree that CGA+RR is stronger than just RR. I'm just trying to make sure we all understand what the differences are in terms of residual attacks. > - Extending BU3WAY or BUSEC to make them BU4WAY :) > So in this case the MN would send 'half' the secret > through the HA, and the other half directly from > its CoA. The CN would also reply in both paths > (i.e. one to the Home address and one to the CoA). BU4WAY wouldn't address an attacker on the CN's link, right? I think it is easier to attack at the edges (where there are lots of hosts) than in the middle of the network. And even with BU4WAY an attacker between the CN and HA can just claim to itself be the CoA, thus it would be on both of the paths. > One assumption: ingress filtering on source addresses > is widely used. > > Based on this suggestion and the assumption above, > the attacker will not be able to use the MN's Home > address as a source address since the packet will be > dropped by ingress filtering. If the attacker is on the path between the HA and the CN it sits on the path where packets normally tracel what have the HoA as a source thus ingress filtering can't filter those out. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 15:29: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 PAA27130 for ; Mon, 7 Jan 2002 15:29:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12140; Mon, 7 Jan 2002 12:28:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04617; Mon, 7 Jan 2002 12:28:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KRdNg013177 for ; Mon, 7 Jan 2002 12:27:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07KRdNT013176 for mobile-ip-dist; Mon, 7 Jan 2002 12:27: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07KRWNg013161; Mon, 7 Jan 2002 12:27: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 MAA25482; Mon, 7 Jan 2002 12:27:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03124; Mon, 7 Jan 2002 12:27:36 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g07KRYP30420; Mon, 7 Jan 2002 22:27:34 +0200 Date: Mon, 7 Jan 2002 22:27:34 +0200 (EET) From: Pekka Savola To: cc: Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201071723.g07HNUQ15139@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 7 Jan 2002, Francis Dupont wrote: > Nothing prevents from applying some kind of RR tests to HAO (without BU) > use too. The HAO implementation would just be a .. little .. more > complicated.. but then again it hasn't been defined in the spec anyway. > > => I believe the ".. little .. more complicated.." is a joke, isn't it? Of course. :-) [snip] > I won't get into this more here, because I must say I agree almost 100% > with comments from Pekka Nikander, Jari Arkko et al. (You should be very, > very afraid if you ever venture in Finland, Francis ;-). > > => so you agree to kill triangular routing? What's the point of it, really? If you don't want routing optiomization, nothing prevents you from establishing tunnels to your home agent: no need for HAO etc. either then. This is probably better for TCP and the like which like symmetric propagation properties. > One point I've made before: perhaps the check is trivial, but IMO _the > most important thing_ is that *every* site could easily check from > incoming packets with HAO, whether the HAO is is spoofed to belong to > *destination site in question* or some other site the destination site > trust at some level. > > => so the easiest solution for someone which doesn't want to implement > or enable RO is just to drop HAOs. In France we have an expression for > that: "la politique du pire". Sure, if that only means the connections will break if the MN moves. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 7 17:13:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29388 for ; Mon, 7 Jan 2002 17:13:36 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28106; Mon, 7 Jan 2002 15:12: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 OAA19616; Mon, 7 Jan 2002 14:12:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07MBqNg013484 for ; Mon, 7 Jan 2002 14:11:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g07MBqjN013483 for mobile-ip-dist; Mon, 7 Jan 2002 14:11: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g07MBoNg013476 for ; Mon, 7 Jan 2002 14:11:51 -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 RAA15627 for ; Mon, 7 Jan 2002 17:11:56 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA15603 for mobile-ip@sunroof.eng.sun.com; Mon, 7 Jan 2002 17:12:37 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g04G45Ng003251; Fri, 4 Jan 2002 08:04:05 -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 IAA03625; Fri, 4 Jan 2002 08:04:09 -0800 (PST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14157; Fri, 4 Jan 2002 08:04:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id g04G45F30252; Fri, 4 Jan 2002 11:04:05 -0500 To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> From: stanislav shalunov Date: 04 Jan 2002 11:04:01 -0500 In-Reply-To: <200201041537.g04FbdQ03170@givry.rennes.enst-bretagne.fr> Message-ID: <871yh6gl1q.fsf@cain.internet2.edu> Lines: 14 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis Dupont writes: > => ingress filtering has more problems with IPv4, mainly because it > was not considered from the beginning. But it is already a BCP and > it seems that most ISPs use it (feedback from ISPs please). With IPv4, Abilene (and most large R&E networks I am familiar with), don't do ingress filtering because of problems with multihoming. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ A fool's brain digests philosophy into folly, science into superstition, and art into pedantry. Hence University education. -- G. B. Shaw From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 05:34: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 FAA18672 for ; Tue, 8 Jan 2002 05:33:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21630; Tue, 8 Jan 2002 02:32:57 -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 CAA01750; Tue, 8 Jan 2002 02:32:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AVxNg014994 for ; Tue, 8 Jan 2002 02:31:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08AVxuv014993 for mobile-ip-dist; Tue, 8 Jan 2002 02:31: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08AVqNg014978; Tue, 8 Jan 2002 02:31:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10381; Tue, 8 Jan 2002 02:31:57 -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 DAA21428; Tue, 8 Jan 2002 03:31: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 g08AVsb22165; Tue, 8 Jan 2002 11:31: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 LAA24887; Tue, 8 Jan 2002 11:31: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 g08AVrQ18185; Tue, 8 Jan 2002 11:31:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201081031.g08AVrQ18185@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 07 Jan 2002 22:27:34 +0200. Date: Tue, 08 Jan 2002 11:31: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: Sure, if that only means the connections will break if the MN moves. => no, that only means the only solution is to use a bidirectional tunnel with the home agent (i.e. we are back to the current mobile IPv4 situation). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 06:11: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 GAA19080 for ; Tue, 8 Jan 2002 06:11:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08066; Tue, 8 Jan 2002 04:10:33 -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 DAA05825; Tue, 8 Jan 2002 03:10:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08B9vNg015272 for ; Tue, 8 Jan 2002 03:09:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08B9vEj015271 for mobile-ip-dist; Tue, 8 Jan 2002 03:09:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08B9oNg015255; Tue, 8 Jan 2002 03:09:50 -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 DAA15811; Tue, 8 Jan 2002 03:09:54 -0800 (PST) Received: from cgprelay.ua.pt (smtprelay.ua.pt [193.136.80.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14407; Tue, 8 Jan 2002 03:09:51 -0800 (PST) Received: from [193.136.92.65] (HELO trantor.it.pt) by cgprelay.ua.pt (CommuniGate Pro SMTP 3.5.2) with ESMTP id 933335; Tue, 08 Jan 2002 11:09:44 +0000 Received: from verne.av.it.pt (verne.av.it.pt [193.136.92.50]) by trantor.it.pt (sendmail) with ESMTP id 683542C1A; Tue, 8 Jan 2002 11:09:12 +0000 (PWT) Received: from IT/SpoolDir by verne.av.it.pt (Mercury 1.47); 8 Jan 02 11:07:20 GMT Received: from SpoolDir by IT (Mercury 1.47); 8 Jan 02 11:07:02 GMT Received: from loliveira (193.136.92.235) by verne.av.it.pt (Mercury 1.47); 8 Jan 02 11:06:58 GMT Message-ID: <006e01c19877$f23786e0$eb5c88c1@loliveira> From: =?iso-8859-1?Q?Lu=EDs_Miguel_Oliveira?= To: Cc: Subject: [mobile-ip] IPv6 Mobility in transition scenarios Date: Tue, 8 Jan 2002 11:09:06 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C19834.E3CC6870" 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: This is a multi-part message in MIME format. ------=_NextPart_000_006B_01C19834.E3CC6870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am to study IPv6 mobility in transition scenarios. This type of = scenarios involves a MN that change to different IPv4, IPv6 or IPv4/IPv6 = network.=20 The correspondent node could be IPV4 or IPv6. Which must be the requirements of the Home Network, Foreign Network, the = MN and the HA? And what are the requirements for the transition = IPv4<->IPv6 mechanisms? Thanks in advance. _________________________________ Luis Miguel L. de Oliveira loliveira@av.it.pt ; loliveira@ipt.pt IPT - Instituto Polit=E9cnico de Tomar Quinta do Contador - Estrada da Serra 2300 TOMAR Instituto de Telecomunica=E7=F5es Campus Universit=E1rio de Santiago 3810-193 AVEIRO - PORTUGAL _________________________________ ------=_NextPart_000_006B_01C19834.E3CC6870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am to study = IPv6 mobility=20 in transition scenarios. This type of scenarios involves a MN that = change to=20 different IPv4, IPv6 or IPv4/IPv6 network.

The correspondent = node=20 could be IPV4 or IPv6.

Which must be the = requirements of the Home Network, Foreign Network, the MN and the HA? = And what=20 are the requirements for the transition IPv4<->IPv6=20 mechanisms?

Thanks in=20 advance.

_________________________________
Luis Miguel L. de = Oliveira
loliveira@av.it.pt ; loliveira@ipt.pt
 
IPT - Instituto Polit=E9cnico de = Tomar
Quinta do=20 Contador - Estrada da Serra
2300 TOMAR
 
Instituto de = Telecomunica=E7=F5es
Campus=20 Universit=E1rio de Santiago
3810-193 AVEIRO -=20 PORTUGAL
_________________________________
------=_NextPart_000_006B_01C19834.E3CC6870-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 07:43: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 HAA19866 for ; Tue, 8 Jan 2002 07:43: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 FAA15763; Tue, 8 Jan 2002 05:41: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 EAA14323; Tue, 8 Jan 2002 04:42:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08CfRNg015553 for ; Tue, 8 Jan 2002 04:41:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08CfQfh015552 for mobile-ip-dist; Tue, 8 Jan 2002 04:41: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08CfNNg015545 for ; Tue, 8 Jan 2002 04:41:23 -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 EAA13322 for ; Tue, 8 Jan 2002 04:41:28 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13862 for ; Tue, 8 Jan 2002 04:41:27 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g08CfPJ17838 for ; Tue, 8 Jan 2002 13:41:26 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jan 08 13:41:09 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 13:41:25 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1B4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RE: Is RR only enough ? Date: Tue, 8 Jan 2002 13:41: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: > If e2e security is done right any MiTM attack would just be > capable of > performing a DoS attack by preventing communication. > "Done right" assumes that the peers some how know the > identity of each > other and the public keys associated with those identities > and that's what is required to be able to securely be able > to communicate with > a known entity. => Sure, but it was suggested that TLS or other upper layer security mechanisms can be used to avoid these types of attacks today. I don't think they would help avoid this attack using the BU. Also, I agree with what you say about security "Done right", implying the identity exchange between the two parties, but perhaps we should document somewhere (in the ultimate solution) that this will override any other security mechanism for BUs. I.e. if there is "proper" SAs already established, they should be sufficient for the MN to send a BU without the need to run any other mechanism. (proper is per the definition you mention above and/or any other additions deemed necessary) > Yes, there is such a subtle difference. > But Maruc Leech said in the MobileIP meeting in SLC that for on-path > attacks we shouldn't worry about the distiction between an active > and a passive attacker. > This seem to make sense to me - if somebody uses ARP/ND > spoofing to gain access > on multi-access links or hacks a switch/router in the path > it would be easy > for them to modify packets. > => So the difference is that the BU attacker will not have to modify anything, which makes him more dangerous if: 1. upper layer security is used (not IPsec) 2. If IPsec is used but the CN still accepts RR for BU. (strange situation that we should not allow of course). I agree with the ARP case, However, ND has the potential of being secure, but even if it was secured (somehow keys are distributed), this problem would still exist. Of course having secure ND does not imply that no one will launch attacks outside the link. > > But without binding updates the additional piece that is needed > in today's internet is to spoof the ARP packets for the routers' > and victim's IP addresses and now all packets will go > through the attacker. > > There is a subtle difference in that an ARP spoofing attack > might be more > "visible" than snooping the wire - if an admin happens to > look at the > content of the ARP cache during the attack the admin might > observe that it > doesn't look like the router's Ethernet address. => Exactly. > But an admin is pretty unlikely to look. => I'll take your word for it :), I haven't admined before, but I know it's pretty unlikely for anyone to read ARP caches without noticing a problem, so I think you're right. But as you said above, should a problem be noticed, there would be a way to trace it. I know the difference is subtle and I'm not trying to say it's good enough to discredit any mechanisms, but I just wanted to bring it up so at least we know it can exist and be aware of that when deciding on the tradeoffs. > I agree there are differences but I find them rather subtle. > I don't have a magic way to tell the difference other than > by trying to > put myself in the shoes of a determined attacker. If the > attacker can get > access to a multi-access link in the path what can be done? > If the attacker can break a switch/router in the path what > can be done? => I agree. To me it seems easier to be in the path than be required to compromise a router/switch. But as you said you can get the same effect with ARP. So we come to two very subtle differences really: - The BU attacker does not need to modify any information in the packet. This makes the attack work if end users were relying on upper layer security (TLS or app). - The BU attacker does not disturb any other nodes on link, so it's harder to discover that there is a problem. Basically the only way to locate the attacker is through the CN's Binding Cache or if someone is looking for HAO inside the packets. Both cases are unlikely. > > I agree that CGA+RR is stronger than just RR. > I'm just trying to make sure we all understand what the > differences are > in terms of residual attacks. => Absolutely, as I said I only wanted to bring it up so that we can cover more of the possibilities and hopefully end up with more 'awarness' in our tradeoffs. > > BU4WAY wouldn't address an attacker on the CN's link, right? => Right. > I think it is easier to attack at the edges (where there > are lots of hosts) > than in the middle of the network. => Sure, but my understanding was that this is always possible and is not specific to MIPv6. > > If the attacker is on the path between the HA and the CN > it sits on the path where packets normally tracel what have > the HoA as a source > thus ingress filtering can't filter those out. => True, BU4WAY wouldn't help with that. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 11:15:36 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27703 for ; Tue, 8 Jan 2002 11:15:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12274; Tue, 8 Jan 2002 07:54:42 -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 HAA06574; Tue, 8 Jan 2002 07:54:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08FrsNg015899 for ; Tue, 8 Jan 2002 07:53:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08FrrKR015898 for mobile-ip-dist; Tue, 8 Jan 2002 07:53:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08FroNg015891 for ; Tue, 8 Jan 2002 07:53:50 -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 HAA05806 for ; Tue, 8 Jan 2002 07:53:54 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21279 for ; Tue, 8 Jan 2002 08:53:54 -0700 (MST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g08Fs3Q09076 for ; Tue, 8 Jan 2002 09:54:03 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 8 Jan 2002 09:53:53 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 8 Jan 2002 09:53:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1985C.AB8178A8" Subject: RE: [mobile-ip] IPv6 Mobility in transition scenarios Date: Tue, 8 Jan 2002 09:53:52 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD38F@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] IPv6 Mobility in transition scenarios Thread-Index: AcGYNT5ZcphqQAQnEdar0gAIx6S5QwAJ1fxw From: "Patil Basavaraj (NET/Dallas)" To: X-OriginalArrivalTime: 08 Jan 2002 15:53:52.0979 (UTC) FILETIME=[ABCC4A30:01C1985C] Sender: owner-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_01C1985C.AB8178A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Take a look at this draft. It provides all the scenarios and possible solutions. =20 draft-ietf-ngtrans-moving-00.txt =20 -Basavaraj -----Original Message----- From: ext Lu=EDs Miguel Oliveira [mailto:loliveira@av.it.pt] Sent: Tuesday, January 08, 2002 1:09 PM To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: [mobile-ip] IPv6 Mobility in transition scenarios Hi, =20 I am to study IPv6 mobility in transition scenarios. This type of scenarios involves a MN that change to different IPv4, IPv6 or IPv4/IPv6 network.=20 The correspondent node could be IPV4 or IPv6. Which must be the requirements of the Home Network, Foreign Network, the MN and the HA? And what are the requirements for the transition IPv4<->IPv6 mechanisms? Thanks in advance. _________________________________ Luis Miguel L. de Oliveira loliveira@av.it.pt ; loliveira@ipt.pt =20 IPT - Instituto Polit=E9cnico de Tomar Quinta do Contador - Estrada da Serra 2300 TOMAR =20 Instituto de Telecomunica=E7=F5es Campus Universit=E1rio de Santiago 3810-193 AVEIRO - PORTUGAL _________________________________ ------_=_NextPart_001_01C1985C.AB8178A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Take a=20 look at this draft. It provides all the scenarios and possible=20 solutions.
 
draft-ietf-ngtrans-moving-00.txt
 
-Basavaraj
-----Original Message-----
From: ext Lu=EDs Miguel = Oliveira=20 [mailto:loliveira@av.it.pt]
Sent: Tuesday, January 08, 2002 = 1:09=20 PM
To: mobile-ip@sunroof.eng.sun.com
Cc:=20 ipng@sunroof.eng.sun.com
Subject: [mobile-ip] IPv6 Mobility = in=20 transition scenarios

Hi,
 
I am to study = IPv6=20 mobility in transition scenarios. This type of scenarios involves a MN = that=20 change to different IPv4, IPv6 or IPv4/IPv6 network. =

The = correspondent node=20 could be IPV4 or IPv6.

Which must be = the=20 requirements of the Home Network, Foreign Network, the MN and the HA? = And what=20 are the requirements for the transition IPv4<->IPv6=20 mechanisms?

Thanks in=20 advance.

_________________________________
Luis Miguel L. de = Oliveira
loliveira@av.it.pt ; loliveira@ipt.pt
 
IPT - Instituto Polit=E9cnico de = Tomar
Quinta do=20 Contador - Estrada da Serra
2300 TOMAR
 
Instituto de = Telecomunica=E7=F5es
Campus=20 Universit=E1rio de Santiago
3810-193 AVEIRO -=20 = PORTUGAL
_________________________________
------_=_NextPart_001_01C1985C.AB8178A8-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 13:22:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03558 for ; Tue, 8 Jan 2002 13:22:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03119; Tue, 8 Jan 2002 11:21:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11366; Tue, 8 Jan 2002 10:21:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08IKdNg016225 for ; Tue, 8 Jan 2002 10:20:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08IKdwC016224 for mobile-ip-dist; Tue, 8 Jan 2002 10:20: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08IKWNg016209; Tue, 8 Jan 2002 10:20:32 -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 KAA20345; Tue, 8 Jan 2002 10:20:36 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13796; Tue, 8 Jan 2002 11:20:36 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g08IKQJ22990; Tue, 8 Jan 2002 10:20:26 -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 AAQ11895; Tue, 8 Jan 2002 10:19:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA13118; Tue, 8 Jan 2002 10:20:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15419.14441.941556.661985@thomasm-u1.cisco.com> Date: Tue, 8 Jan 2002 10:20:25 -0800 (PST) To: Francis Dupont Cc: Michael Thomas , Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201081739.g08HdiQ21918@givry.rennes.enst-bretagne.fr> References: <15419.8414.384615.139500@thomasm-u1.cisco.com> <200201081739.g08HdiQ21918@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Phil suggested I add mobileip back which was dropped somewhere along the way] Francis, I'm not sure we're communicating, so let me be a little more explicit with what I had in mind: 1) MN arrives on new AR 2) It sends a packet using its home address as the *source* address -- no HAO at all. 3) AR recognizes that the source address is not one of the subnets it subtends and sends an ICMP message to MN which explains the problem 4) MN sends AR a normal CN binding update 5) AR lifts the restriction for that source address 6) MN now sends packets as in (2), but unimpeded If MN knows that there is likely to be a source address check on AR, it can delete steps 2 and 3. ICMP seems like a natural here because the router really is reporting a network problem back to MN (or not MN if a host were incorrectly configured, etc). If this is a subset of your proposal, fine. It does seem that what I propose gets rid of the HAO altogether which you don't seem to agree with. However, may I suggest that it's the AAA part that has become the lightning rod? And that maybe it shouldn't be quite so ambitious? :-) Mike Francis Dupont writes: > In your previous mail you wrote: > > No, actually, it was to have the MN send the > BU's directly to the access router. On a router > the BU just has an additional effect of removing > any restrictions on source addresses it will > let through. > > => I believed your proposal was BU snooping. But you can name it > as you'd like, the purpose is to provide the knowledge of bindings, > so there is no deep difference with my proposal (i.e. I can say > you use a non-standard network access control device, as I don't > specify one (I only give an example with AAA because it is the best > on the paper) I could argue your proposal is included in mine :-). > > Hence Pekka's question about use of ICMP was correct. > > => I am reluctant to define new ICMPs for anything. There is already > a format for BUs, why a new thing? > > Another point: HAOs are inside packets, to look at them is legitimate > for my firewall but not for any router on the path, i.e. I'd like > to have the check done once and others to trust it (this idea is > exactly the network access control). > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 13:56: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 NAA05027 for ; Tue, 8 Jan 2002 13:56:27 -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 LAA26541; Tue, 8 Jan 2002 11:55: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 KAA22673; Tue, 8 Jan 2002 10:55:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08IskNg016444 for ; Tue, 8 Jan 2002 10:54:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08IskSC016443 for mobile-ip-dist; Tue, 8 Jan 2002 10:54: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08IshNg016436 for ; Tue, 8 Jan 2002 10:54:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10335 for ; Tue, 8 Jan 2002 10:54:47 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24394 for ; Tue, 8 Jan 2002 10:54:46 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08Ish019620 for ; Tue, 8 Jan 2002 12:54:44 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 12:52:58 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01590CB4@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: IPv6 ingress filtering early access Date: Tue, 8 Jan 2002 12:54:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19875.D602AE20" Sender: owner-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_01C19875.D602AE20 Content-Type: text/plain; charset="iso-8859-1" Mike, This sounds like a pretty good idea to me to remove the need for tunneling overhead. How can we guarantee that topological checks are not on anywhere in the interior of the network, though? Glenn > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, January 08, 2002 12:20 PM > To: Francis Dupont > Cc: Michael Thomas; Pekka Nikander; Jari Arkko; > ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access > > > [Phil suggested I add mobileip back which was > dropped somewhere along the way] > > Francis, > > I'm not sure we're communicating, so let me be a little > more explicit with what I had in mind: > > 1) MN arrives on new AR > 2) It sends a packet using its home address as the > *source* address -- no HAO at all. > 3) AR recognizes that the source address is not one of > the subnets it subtends and sends an ICMP message > to MN which explains the problem > 4) MN sends AR a normal CN binding update > 5) AR lifts the restriction for that source address > 6) MN now sends packets as in (2), but unimpeded > > If MN knows that there is likely to be a source > address check on AR, it can delete steps 2 and 3. > ICMP seems like a natural here because the router > really is reporting a network problem back to MN > (or not MN if a host were incorrectly configured, > etc). > > If this is a subset of your proposal, fine. It > does seem that what I propose gets rid of the HAO > altogether which you don't seem to agree with. > However, may I suggest that it's the AAA part that > has become the lightning rod? And that maybe it > shouldn't be quite so ambitious? :-) > > Mike > > Francis Dupont writes: > > In your previous mail you wrote: > > > > No, actually, it was to have the MN send the > > BU's directly to the access router. On a router > > the BU just has an additional effect of removing > > any restrictions on source addresses it will > > let through. > > > > => I believed your proposal was BU snooping. But you can name it > > as you'd like, the purpose is to provide the knowledge of bindings, > > so there is no deep difference with my proposal (i.e. I can say > > you use a non-standard network access control device, as I don't > > specify one (I only give an example with AAA because it is the best > > on the paper) I could argue your proposal is included in mine :-). > > > > Hence Pekka's question about use of ICMP was correct. > > > > => I am reluctant to define new ICMPs for anything. There > is already > > a format for BUs, why a new thing? > > > > Another point: HAOs are inside packets, to look at them is > legitimate > > for my firewall but not for any router on the path, i.e. I'd like > > to have the check done once and others to trust it (this idea is > > exactly the network access control). > > > > Regards > > > > Francis.Dupont@enst-bretagne.fr > ------_=_NextPart_001_01C19875.D602AE20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: IPv6 ingress filtering early access

Mike,

This sounds like a pretty good idea to me to remove the need for tunneling overhead.

How can we guarantee that topological checks are not on anywhere in the interior of the network, though?

Glenn

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, January 08, 2002 12:20 PM
> To: Francis Dupont
> Cc: Michael Thomas; Pekka Nikander; Jari Arkko;
> ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access
>
>
> [Phil suggested I add mobileip back which was
>  dropped somewhere along the way]
>
> Francis,
>
> I'm not sure we're communicating, so let me be a little
> more explicit with what I had in mind:
>
> 1) MN arrives on new AR
> 2) It sends a packet using its home address as the
>    *source* address -- no HAO at all.
> 3) AR recognizes that the source address is not one of
>    the subnets it subtends and sends an ICMP message
>    to MN which explains the problem
> 4) MN sends AR a normal CN binding update
> 5) AR lifts the restriction for that source address
> 6) MN now sends packets as in (2), but unimpeded
>
> If MN knows that there is likely to be a source
> address check on AR, it can delete steps 2 and 3.
> ICMP seems like a natural here because the router
> really is reporting a network problem back to MN
> (or not MN if a host were incorrectly configured,
> etc).
>
> If this is a subset of your proposal, fine. It
> does seem that what I propose gets rid of the HAO
> altogether which you don't seem to agree with.
> However, may I suggest that it's the AAA part that
> has become the lightning rod? And that maybe it
> shouldn't be quite so ambitious? :-)
>
>        Mike
>
> Francis Dupont writes:
>  >  In your previous mail you wrote:
>  >
>  >       No, actually, it was to have the MN send the
>  >       BU's directly to the access router. On a router
>  >       the BU just has an additional effect of removing
>  >       any restrictions on source addresses it will
>  >       let through.
>  >
>  > => I believed your proposal was BU snooping. But you can name it
>  > as you'd like, the purpose is to provide the knowledge of bindings,
>  > so there is no deep difference with my proposal (i.e. I can say
>  > you use a non-standard network access control device, as I don't
>  > specify one (I only give an example with AAA because it is the best
>  > on the paper) I could argue your proposal is included in mine :-).
>  >
>  >       Hence Pekka's question about use of ICMP was correct.
>  >
>  > => I am reluctant to define new ICMPs for anything. There
> is already
>  > a format for BUs, why a new thing?
>  >
>  > Another point: HAOs are inside packets, to look at them is
> legitimate
>  > for my firewall but not for any router on the path, i.e. I'd like
>  > to have the check done once and others to trust it (this idea is
>  > exactly the network access control).
>  >
>  > Regards
>  >
>  > Francis.Dupont@enst-bretagne.fr
>

------_=_NextPart_001_01C19875.D602AE20-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 14:31: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 OAA06763 for ; Tue, 8 Jan 2002 14:31: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 LAA25821; Tue, 8 Jan 2002 11:29:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05652; Tue, 8 Jan 2002 11:28:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08JS1Ng016677 for ; Tue, 8 Jan 2002 11:28:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08JS1A9016676 for mobile-ip-dist; Tue, 8 Jan 2002 11:28:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08JRwNg016669 for ; Tue, 8 Jan 2002 11:27:58 -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 LAA05492 for ; Tue, 8 Jan 2002 11:28:02 -0800 (PST) Received: from yn-server1.yodanetworks.com ([208.253.26.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03295 for ; Tue, 8 Jan 2002 12:29:08 -0700 (MST) Received: by yn-server1.yodanetworks.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Jan 2002 14:27:02 -0500 Message-ID: <95F30C6F1B56D4118F9200508BC75B3A31A4BA@yn-server1.yodanetworks.com> From: "Kota, Ravikumar" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Any pointer on mobile ip simulators Date: Tue, 8 Jan 2002 14:26:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Can anybody help me to get some light about simulators available for mobile ip and required equipment to run them. Thansk alot Ravikumar Kota From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 15:17: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 PAA08886 for ; Tue, 8 Jan 2002 15:17:07 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15359; Tue, 8 Jan 2002 12:15:23 -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 MAA06236; Tue, 8 Jan 2002 12:15:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08KELNg016840 for ; Tue, 8 Jan 2002 12:14:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08KELEN016839 for mobile-ip-dist; Tue, 8 Jan 2002 12:14: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08KEJNg016832 for ; Tue, 8 Jan 2002 12:14:19 -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 PAA09154 for ; Tue, 8 Jan 2002 15:14:23 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA11221 for mobile-ip@sunroof.eng.sun.com; Tue, 8 Jan 2002 15:15:04 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g080xWNg013756 for ; Mon, 7 Jan 2002 16:59:32 -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 QAA03553 for ; Mon, 7 Jan 2002 16:59:37 -0800 (PST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16218 for ; Mon, 7 Jan 2002 16:59:37 -0800 (PST) Received: from yasmine.ece.arizona.edu (yasmine [128.196.28.123]) by tiquini.ece.arizona.edu (8.12.1/8.12.1) with ESMTP id g080xa2n015614 for ; Mon, 7 Jan 2002 17:59:36 -0700 (MST) Received: (from krunz@localhost) by yasmine.ece.arizona.edu (8.10.2+Sun/8.10.2) id g0812mI02493 for mobile-ip@sunroof.eng.sun.com; Mon, 7 Jan 2002 18:02:48 -0700 (MST) Date: Mon, 7 Jan 2002 18:02:48 -0700 (MST) Message-Id: <200201080102.g0812mI02493@yasmine.ece.arizona.edu> From: krunz@ece.arizona.edu To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobicom 2002 - CFP Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Appologies if you receive multiple copies of this Call for Papers ] ********************************************************************* Call for Papers *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Submission Deadline: March 1, 2002 ********************************************************************* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: - No longer than 12 pages (double column); in font no smaller than 10 points - Fit properly on US Letter-sized paper (8.5 ' 11 inches) with reasonable margins - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier,Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: * Paper submissions due: March 1, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu ORGANIZING COMMITTEE: * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Monmouth Internet Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Chair: Suresh Singh, Portland State University * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 15:59:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10306 for ; Tue, 8 Jan 2002 15:59:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21538; Tue, 8 Jan 2002 13:58: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 MAA27432; Tue, 8 Jan 2002 12:58:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08KvcNg017076 for ; Tue, 8 Jan 2002 12:57:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g08KvcmD017075 for mobile-ip-dist; Tue, 8 Jan 2002 12: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g08KvYNg017068 for ; Tue, 8 Jan 2002 12:57:34 -0800 (PST) Received: from lillen ([129.146.99.209]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g08KvU317870; Tue, 8 Jan 2002 21:57:30 +0100 (MET) Date: Tue, 8 Jan 2002 21:54:46 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] RE: Is RR only enough ? To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C1B4@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: > > If e2e security is done right any MiTM attack would just be > > capable of > > performing a DoS attack by preventing communication. > > "Done right" assumes that the peers some how know the > > identity of each > > other and the public keys associated with those identities > > and that's what is required to be able to securely be able > > to communicate with > > a known entity. > > => Sure, but it was suggested that TLS or other upper > layer security mechanisms can be used to avoid > these types of attacks today. I don't think they > would help avoid this attack using the BU. By "these attacks" do you mean the DoS impact of the attacks or the an attack that can modify the content of the communication? The DoS attack by a MiTM can never be prevented. The modification of content can be prevented with TLS, IPsec, etc. > Also, I agree with what you say about security > "Done right", implying the identity exchange between > the two parties, but perhaps we should document > somewhere (in the ultimate solution) that this will > override any other security mechanism for BUs. > I.e. if there is "proper" SAs already established, > they should be sufficient for the MN to send > a BU without the need to run any other mechanism. You're skipping a few steps. If you want to use an existing SA (IPsec, SSL, whatever) to protect BUs the identities associated with the SA needs to be quite different than what you'd get for other use of security. E.g. when using SSL to a website you'd like to know that the identity is www.example.com; when sending secure email to me you'd like the identity to be erik.nordmark@sun.com, but for a BU the identity you'd need is the home IP address. Using security associated with one type of identity for something else isn't likely to get the security you'd expect. Thus my personal opinion is that we should make the BU security be independent of other (content-oriented) security. Thus if folks want to use IPsec or SSL you'd still use the same BU security mechanism. > => So the difference is that the BU attacker > will not have to modify anything, which makes > him more dangerous if: > > 1. upper layer security is used (not IPsec) > 2. If IPsec is used but the CN still accepts > RR for BU. (strange situation that we should > not allow of course). > > I agree with the ARP case, However, ND has the potential > of being secure, but even if it was secured (somehow > keys are distributed), this problem would still exist. ND has the potential to be secure because of the IPsec pixie dust in the security considerations section??? (Yes, I've learned some things since that document became a draft standard without anybody having implemented ND secured by IPsec.) > I know the difference is subtle and I'm not trying > to say it's good enough to discredit any mechanisms, > but I just wanted to bring it up so at least we know > it can exist and be aware of that when deciding > on the tradeoffs. We're in agreement that we need to understand the residual threats for the different approaches. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 22:42:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19270 for ; Tue, 8 Jan 2002 22:42:25 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19386; Tue, 8 Jan 2002 20:40:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10505; Tue, 8 Jan 2002 19:40:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g093diNg017552 for ; Tue, 8 Jan 2002 19:39:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g093diMk017551 for mobile-ip-dist; Tue, 8 Jan 2002 19:39: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g093dfNg017544 for ; Tue, 8 Jan 2002 19:39:41 -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 TAA01761 for ; Tue, 8 Jan 2002 19:39:46 -0800 (PST) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03963 for ; Tue, 8 Jan 2002 19:39:45 -0800 (PST) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 41BA65D01E; Wed, 9 Jan 2002 12:39:43 +0900 (JST) Date: Wed, 09 Jan 2002 12:38:46 +0900 (JST) Message-Id: <20020109.123846.34978814.ernst@sfc.wide.ad.jp> To: mobile-ip@sunroof.eng.sun.com, RKota@cratosnetworks.com Subject: Re: [mobile-ip] Any pointer on mobile ip simulators From: Thierry Ernst In-Reply-To: <95F30C6F1B56D4118F9200508BC75B3A31A4BA@yn-server1.yodanetworks.com> References: <95F30C6F1B56D4118F9200508BC75B3A31A4BA@yn-server1.yodanetworks.com> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) 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 Well, you better use NS-2, it's free, you only need a PC (Linux, Solaris), and most published papers have run simulations using NS. Mobile IPv4 has been contributed to NS-2 a long time ago and is part of the official distribution. See ns-2 web page: http://www.isi.edu/nsnam/ns/ As for Mobile IPv6, I have contributed code (called MobiWan), but it's not part of the official distribution yet. It is designed with NS-2 version b6. See my web page about MobiWan: http://www.inrialpes.fr/planete/pub/mobiwan/ Be aware that it comes with no guarantees and that some people that tried to use it had many difficultites to make it run, and even to compile it. I think recent compilers don't compile my code. Though, it compiles and run perfectly on my Solaris OS, with a not-too-recent compiler, for my own simulations. Depending on my availability, I may port the code to the current version of NS-2 (b9), so that it becomes an official part of the distribution. Hope this helps, Thierry - WIDE Project. > Hi all, > > Can anybody help me to get some light about simulators available for mobile > ip and required equipment to run them. > > > Thansk alot > Ravikumar Kota From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 8 23:15: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 XAA19599 for ; Tue, 8 Jan 2002 23:15:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12763; Tue, 8 Jan 2002 20:13:58 -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 UAA05261; Tue, 8 Jan 2002 20:13:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g094CvNg017687 for ; Tue, 8 Jan 2002 20:12:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g094Cv5E017686 for mobile-ip-dist; Tue, 8 Jan 2002 20:12: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g094CsNg017679 for ; Tue, 8 Jan 2002 20:12:54 -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 UAA05152 for ; Tue, 8 Jan 2002 20:12:59 -0800 (PST) Received: from eyou.com ([61.136.62.74]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA15210 for ; Tue, 8 Jan 2002 21:12:57 -0700 (MST) Received: (qmail 84221 invoked by alias); 9 Jan 2002 12:12:57 +0800 Received: from unknown (HELO eyou.com) (172.16.2.1) by 172.16.1.2 with SMTP; 9 Jan 2002 12:12:57 +0800 Received: (qmail 5783 invoked by uid 65534); 9 Jan 2002 12:12:57 +0800 Date: 9 Jan 2002 12:12:57 +0800 Message-ID: <20020109121257.5782.qmail@eyou.com> From: "Weishuai Yang" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Any pointer on mobile ip simulators Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I'm trying to simulate Fast Handover on the base of Mobiwan contributed by Thierry. I successfully run it on Red Hat 7.2, although I really take pains to make it run. I'm reading Thierry's code right now. Best Regards, Weishuai Yang ÔÚÄúµÄŔ´ĐĹÖĐĚáµ˝ >Well, you better use NS-2, it's free, you only need a PC (Linux, >Solaris), and most published papers have run simulations using NS. > >Mobile IPv4 has been contributed to NS-2 a long time ago and is part >of the official distribution. See ns-2 web page: >http://www.isi.edu/nsnam/ns/ > >As for Mobile IPv6, I have contributed code (called MobiWan), but it's >not part of the official distribution yet. It is designed with NS-2 >version b6. See my web page about MobiWan: >http://www.inrialpes.fr/planete/pub/mobiwan/ Be aware that it comes >with no guarantees and that some people that tried to use it had many >difficultites to make it run, and even to compile it. I think recent >compilers don't compile my code. Though, it compiles and run >perfectly on my Solaris OS, with a not-too-recent compiler, for my own >simulations. > >Depending on my availability, I may port the code to the >current version of NS-2 (b9), so that it becomes an official part of >the distribution. > >Hope this helps, >Thierry - WIDE Project. > > >> Hi all, >> >> Can anybody help me to get some light about simulators available for mobile >> ip and required equipment to run them. >> >> >> Thansk alot >> Ravikumar Kota > > > --http://www.eyou.com --Îȶ¨żÉżżµÄĂâ·Ńµç×ÓĐĹĎä ÓďŇôÓĘĽţ ŇƶŻĘéÇ© ČŐŔú·ţÎń ÍřÂç´ć´˘...ŇÚÓĘδľˇ From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 03:56: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 DAA01371 for ; Wed, 9 Jan 2002 03:56:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA03360; Wed, 9 Jan 2002 00:54:12 -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 AAA21626; Wed, 9 Jan 2002 00:53:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g098quNg018065 for ; Wed, 9 Jan 2002 00:52:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g098qtgh018064 for mobile-ip-dist; Wed, 9 Jan 2002 00:52: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g098qqNg018057 for ; Wed, 9 Jan 2002 00:52: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 AAA16591 for ; Wed, 9 Jan 2002 00:52: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 BAA11024 for ; Wed, 9 Jan 2002 01:52: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 g098qtb10107; Wed, 9 Jan 2002 09:52: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 JAA15675; Wed, 9 Jan 2002 09:52: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 g098qsQ24582; Wed, 9 Jan 2002 09:52:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201090852.g098qsQ24582@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Charlie Perkins Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Thu, 03 Jan 2002 15:17:54 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C18D@Esealnt861.al.sw.ericsson.se> Date: Wed, 09 Jan 2002 09:52:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-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: > => you should recognize piggy-backing is less useful on an Ethernet > or a 802.11b/802.11a. I consider piggy-backing as an > over-optimization > (as RSVP in fact) in most cases, i.e. this really makes sense with > some link-layers which are very hard (i.e. too expensive) to improve > (this is the case of mobile phone in Europe, nobody wants to buy > a second license in some countries just to get more bandwidth :-). => It actually does NOT make any sense for the expensive, hard ..etc link layers. => my text is not clear enough, the "i.e. this really makes sense..." is more about RSVP than piggy-backing (you know I don't like piggy-backing at all). Regards Francis.Dupont@enst-bretagne.fr PS: > So the question is, where does this optimisation make sense ? => obviously not end-to-end (piggy-backing is end-to-end, so any link-layer argument in favor of it is weak). From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 04:09: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 EAA01529 for ; Wed, 9 Jan 2002 04:09:34 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07563; Wed, 9 Jan 2002 01:07: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 BAA18447; Wed, 9 Jan 2002 01:07:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0996iNg018263 for ; Wed, 9 Jan 2002 01:06:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0996i6g018262 for mobile-ip-dist; Wed, 9 Jan 2002 01: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0996dNg018255 for ; Wed, 9 Jan 2002 01:06:39 -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 BAA09579 for ; Wed, 9 Jan 2002 01:06:45 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08313 for ; Wed, 9 Jan 2002 02:07:53 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0996gJ16504 for ; Wed, 9 Jan 2002 10:06:42 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jan 09 10:06:03 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 09:57:11 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Janos Miskolczi (ETH)" Subject: RE: [mobile-ip] HMIPv6 test Date: Wed, 9 Jan 2002 10:05:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi HMIP experts, Greg already summarized what happened at the event in question. I cannot add anything special. Some more details about the contact persons whom you can contact in case of any further questions: AT-CRC: Greg.Daley@eng.monash.edu.au Ericsson - ERA: Martti.Kuparinen@iki.fi Ericsson - R&D Hungary, Conformance Lab: Janos.Miskolczi@eth.ericsson.se, Lajos.Zaccomer@eth.ericsson.se Regards, Lajos Zaccomer -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Thursday, December 20, 2001 7:44 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6 test a quick question. Who are the contact persons for these implementations? Vijay "Hesham Soliman (ERA)" wrote: > > Hi all, > > Just a quick note to inform you that a small > interop test was held before IETF in which > HMIPv6 ver-4 was tested. > There were implementations from Ericsson, > Monash University, and test cases from > conformance lab in Ericsson. > > Regards, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 05:36:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02132 for ; Wed, 9 Jan 2002 05:36:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13693; Wed, 9 Jan 2002 03:34: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 CAA07744; Wed, 9 Jan 2002 02:34:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09AXmNg018424 for ; Wed, 9 Jan 2002 02:33:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09AXmGL018423 for mobile-ip-dist; Wed, 9 Jan 2002 02:33: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09AXjNg018416; Wed, 9 Jan 2002 02:33:45 -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 CAA06981; Wed, 9 Jan 2002 02:33:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13053; Wed, 9 Jan 2002 03:33:50 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g09AXab21950; Wed, 9 Jan 2002 11:33: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 LAA17521; Wed, 9 Jan 2002 11:33:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g09AXWQ24892; Wed, 9 Jan 2002 11:33:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 10:20:25 PST. <15419.14441.941556.661985@thomasm-u1.cisco.com> Date: Wed, 09 Jan 2002 11:33:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: [Phil suggested I add mobileip back which was dropped somewhere along the way] I'm not sure we're communicating, so let me be a little more explicit with what I had in mind: 1) MN arrives on new AR => many (academic or R&D) sites I know don't use firewalls (they use a router for filtering) but have a passive management box which detects new addresses and builds a database with MAC, IP, name, location, etc, something very useful in case of problems. So even if classical network access control is not performed on 1) at the first packet, unusual behaviors are detected (i.e. there is a passive and without automatic reaction kind of network access control). At the opposite I know some (commercial) ISPs which use the (traditional) network access control to punch holes in the firewall for outbound traffic, i.e. all source addresses are blocked by default and network access control is used to open some of them (in AAA term the authorized resource is the Internet access): this is ingress filtering at the address level, usually it is done at the access device (e.g. modem) level too. 2) It sends a packet using its home address as the *source* address -- no HAO at all. => I propose that the packet is sent to the home agent (or something similar). 3) AR recognizes that the source address is not one of the subnets it subtends and sends an ICMP message to MN which explains the problem => perhaps I should add a statement in the draft with a requirement (modulo ICMP rate limitation) for ICMPs when a HAO is filtered out. I believe a router should implement this by default but a detailed text should help. What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option), as the router is not the destination of the packet the MN should understand what's happened. Note that 1 (Destination Unreachable) - 1 (administratively prohibited) is too ambiguous. 4) MN sends AR a normal CN binding update => 4) is what I consider as a kind of network access control. 5) AR lifts the restriction for that source address => the difference with my proposal is here, I propose to accept corresponding HAOs, you propose to directly open the ingress filtering. See more comments after. 6) MN now sends packets as in (2), but unimpeded If MN knows that there is likely to be a source address check on AR, it can delete steps 2 and 3. => i.e. active/reactive modes. ICMP seems like a natural here because the router really is reporting a network problem back to MN (or not MN if a host were incorrectly configured, etc). => in any case ICMP errors have to be sent when packets are dropped, I believe we can reach a consensus about this very quickly. If this is a subset of your proposal, fine. It does seem that what I propose gets rid of the HAO altogether which you don't seem to agree with. => in order to get rid of the HAO your proposal has to be supported on every ingress filtering devices where a packet from the MN can go though. This is not in fact like path MTU discovery (which is already difficult to get in the real world) because your proposal uses a signaling with all the usual problems of signaling (scalability, security, ...). Even if to get rid of the HAO would be very nice, I don't believe this will work in practice. To summary this has the same kind of problems (i.e. limitations) than micro-mobility (i.e. mobility based on host routing). However, may I suggest that it's the AAA part that => I insist about AAA: AAA is not an essential part of my proposal, it only brings extra goodies: - an instance of network access control which is well known and already has proposed extensions for (mobile) IPv6 - remote network access control - a connection between local and remote access control. has become the lightning rod? And that maybe it shouldn't be quite so ambitious? :-) => too ambitious for a global deployment, and for local/special cases I am afraid that micro-mobility is more attractive (it gets rid of the routing header too). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 06:26: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 GAA02477 for ; Wed, 9 Jan 2002 06:26:41 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA14707; Wed, 9 Jan 2002 03:24:58 -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 DAA02132; Wed, 9 Jan 2002 03:24:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09BO5Ng018602 for ; Wed, 9 Jan 2002 03:24:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09BO594018601 for mobile-ip-dist; Wed, 9 Jan 2002 03:24:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09BO1Ng018594 for ; Wed, 9 Jan 2002 03:24:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06434 for ; Wed, 9 Jan 2002 03:24:07 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00724 for ; Wed, 9 Jan 2002 03:24:07 -0800 (PST) Received: from pichnet (pichnet.u-strasbg.fr [130.79.90.171]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id MAA11119 for ; Wed, 9 Jan 2002 12:23:57 +0100 From: "Nicolas Montavont" To: Subject: RE: [mobile-ip] Any pointer on mobile ip simulators Date: Wed, 9 Jan 2002 12:26:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020109121257.5782.qmail@eyou.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: Content-Transfer-Encoding: 8bit Hi Weishuai, I'm also trying to implement the fast handover, more exactly the tunnel-based handover at first. I also use Mobiwan from Thierry. I will keep you informed about my progress if you want. Regards, Nicolas Montavont montavont@dpt-info.u-strasbg.fr -----Message d'origine----- De : owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Weishuai Yang Envoyé : mercredi 9 janvier 2002 05:13 Ŕ : mobile-ip@sunroof.eng.sun.com Objet : Re: [mobile-ip] Any pointer on mobile ip simulators Hi, I'm trying to simulate Fast Handover on the base of Mobiwan contributed by Thierry. I successfully run it on Red Hat 7.2, although I really take pains to make it run. I'm reading Thierry's code right now. Best Regards, Weishuai Yang ÔÚÄúµÄŔ´ĐĹÖĐĚáµ˝ >Well, you better use NS-2, it's free, you only need a PC (Linux, >Solaris), and most published papers have run simulations using NS. > >Mobile IPv4 has been contributed to NS-2 a long time ago and is part >of the official distribution. See ns-2 web page: >http://www.isi.edu/nsnam/ns/ > >As for Mobile IPv6, I have contributed code (called MobiWan), but it's >not part of the official distribution yet. It is designed with NS-2 >version b6. See my web page about MobiWan: >http://www.inrialpes.fr/planete/pub/mobiwan/ Be aware that it comes >with no guarantees and that some people that tried to use it had many >difficultites to make it run, and even to compile it. I think recent >compilers don't compile my code. Though, it compiles and run >perfectly on my Solaris OS, with a not-too-recent compiler, for my own >simulations. > >Depending on my availability, I may port the code to the >current version of NS-2 (b9), so that it becomes an official part of >the distribution. > >Hope this helps, >Thierry - WIDE Project. > > >> Hi all, >> >> Can anybody help me to get some light about simulators available for mobile >> ip and required equipment to run them. >> >> >> Thansk alot >> Ravikumar Kota > > > --http://www.eyou.com --Îȶ¨żÉżżµÄĂâ·Ńµç×ÓĐĹĎä ÓďŇôÓĘĽţ ŇƶŻĘéÇ© ČŐŔú·ţÎń ÍřÂç´ć´˘...ŇÚÓĘδľˇ From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 08:20: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 IAA03489 for ; Wed, 9 Jan 2002 08:20:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA11955; Wed, 9 Jan 2002 05: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 FAA14134; Wed, 9 Jan 2002 05:18:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09DHTNg018903 for ; Wed, 9 Jan 2002 05:17:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09DHTXv018902 for mobile-ip-dist; Wed, 9 Jan 2002 05:17:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09DHQNg018895 for ; Wed, 9 Jan 2002 05:17:26 -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 FAA17455 for ; Wed, 9 Jan 2002 05:17:33 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02771 for ; Wed, 9 Jan 2002 05:17:32 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g09DHVJ14343 for ; Wed, 9 Jan 2002 14:17:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jan 09 14:17:27 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 14:08:34 +0100 Message-ID: From: "Lajos Zaccomer (ETH)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] bitstring for calculating Authentication Data Date: Wed, 9 Jan 2002 14:17:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Can anyone tell me, why does not the bitstring for calculating Authentication Data of a BA contain the reserved field? In case of BU, all the reserved octets are included. Including that mysterious octet in the bitstring would simplify calculation. Otherwise, the reserved field of BU should be removed either. Zacco From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 08:30: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 IAA03619 for ; Wed, 9 Jan 2002 08:30:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15668; Wed, 9 Jan 2002 03:28:08 -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 DAA02560; Wed, 9 Jan 2002 03:28:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09BRPNg018693 for ; Wed, 9 Jan 2002 03:27:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09BROp5018692 for mobile-ip-dist; Wed, 9 Jan 2002 03:27: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09BRLNg018685 for ; Wed, 9 Jan 2002 03:27:21 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23797 for ; Wed, 9 Jan 2002 03:27:27 -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 DAA18107 for ; Wed, 9 Jan 2002 03:27:22 -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 g09BRKb31384 for ; Wed, 9 Jan 2002 12:27:20 +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 MAA18574 for ; Wed, 9 Jan 2002 12:27:20 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g09BRKQ25043 for ; Wed, 9 Jan 2002 12:27:20 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201091127.g09BRKQ25043@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Tue, 08 Jan 2002 12:54:01 CST. <933FADF5E673D411B8A30002A5608A0E01590CB4@zrc2c012.us.nortel.com> Date: Wed, 09 Jan 2002 12:27:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: This sounds like a pretty good idea to me to remove the need for tunneling overhead. => I agree but you can also remove the routing header too, i.e. the tunneling overhead in the other way. This is named micro-mobility or mobility based on host routing, and is almost as applicable as Michael's proposal (i.e. it has exactly the same scalability issue, all involved ingress filtering devices must be configured, for micro mobility this is for all involved routers). Regards Francis.Dupont@enst-bretagne.fr PS: Michael's proposal is like a combination of path MTU discovery (ingress filter devices send back ICMP errors when they drop packets) and signaling (in order to punch holes in ingress filters). From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 13:42:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10348 for ; Wed, 9 Jan 2002 13:42:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24320; Wed, 9 Jan 2002 11:40: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 KAA02052; Wed, 9 Jan 2002 10:40:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09IdMNg019964 for ; Wed, 9 Jan 2002 10:39:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09IdMKp019963 for mobile-ip-dist; Wed, 9 Jan 2002 10:39: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09IdINg019949 for ; Wed, 9 Jan 2002 10:39:18 -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 KAA15733 for ; Wed, 9 Jan 2002 10:39:25 -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 LAA10298 for ; Wed, 9 Jan 2002 11:39:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24684 for ; Wed, 9 Jan 2002 10:39:20 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g09IdKc03246 for ; Wed, 9 Jan 2002 10:39:20 -0800 X-mProtect: Wed, 9 Jan 2002 10:39:20 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.205, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCcs2qU; Wed, 09 Jan 2002 10:39:18 PST Message-ID: <3C3C8DA1.9070309@iprg.nokia.com> Date: Wed, 09 Jan 2002 10:36:17 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] bitstring for calculating Authentication Data References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it was a slip. In my implementation, I include the reserved field in the Binding Acknowledgement. Vijay Lajos Zaccomer (ETH) wrote: > Hi all, > > Can anyone tell me, why does not the bitstring for calculating Authentication Data of a BA contain the reserved field? > In case of BU, all the reserved octets are included. Including that mysterious octet in the bitstring would simplify calculation. Otherwise, the reserved field of BU should be removed either. > > Zacco > From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 14:19: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 OAA12897 for ; Wed, 9 Jan 2002 14:19: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 MAA21387; Wed, 9 Jan 2002 12:17: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 LAA00941; Wed, 9 Jan 2002 11:17:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09JGrNg020184 for ; Wed, 9 Jan 2002 11:16:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09JGrbZ020183 for mobile-ip-dist; Wed, 9 Jan 2002 11:16: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09JGoNg020176 for ; Wed, 9 Jan 2002 11:16:50 -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 LAA24410 for ; Wed, 9 Jan 2002 11:16:56 -0800 (PST) Received: from smtpgw6.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27693 for ; Wed, 9 Jan 2002 12:16:56 -0700 (MST) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id g09JGt226576 for ; Wed, 9 Jan 2002 13:16:55 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89) id ; Wed, 9 Jan 2002 13:16:55 -0600 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC8809FB398E@pkcexv018.sprintspectrum.com> From: "Schubert, John" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Introduction and MIP security question Date: Wed, 9 Jan 2002 13:16:54 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) 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 just joined this list and wanted to introduce myself briefly and ask a question at the same time. I am a System Support Engineer for Sprint, providing 2nd tier technical support for the Packet Control Function (PCF), as well as other packet data devices for markets that use a Lucent 5ESS MSC (in other words, I do not have to worry about Nortel switches). I am working with the installers and program managers that are installing the PCFs between the Base Controllers (BSC)s and the Packet Data Serving Nodes (PDSN) as Sprint prepares for 3G. We are using a "Simple IP" version of MIP, so the PDSN is both the FA and HA (with traffic leaving the PDSN and arriving directly on the IP network). My question is: Is this an appropriate forum to learn and discuss security issues regarding safeguards between the Customer Data Network (e.g. the IP packets containing customer voice, and application data) and the Operational Data Network (e.g. the IP packets destined for the AAA, PCF and other backoffice equipment) in the MIP environment? I did poke around the archives. Any additional sources of information would be greatly appreciated. I'm not responsibile for network security, per se, but I would like to understand it so I can help out as best I can. Thanks for your time, > John Schubert > NTAC Engineer: National Technical Assistance Center - West > * Office: (949) 225-2887 > * PCS: (949) 400-9701 > * Fax: (949) 225-2904 > * E-Mail: jschub01@sprintspectrum.com > From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 9 14:31: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 OAA13380 for ; Wed, 9 Jan 2002 14:31:01 -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 LAA19548; Wed, 9 Jan 2002 11:29: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 LAA04094; Wed, 9 Jan 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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09JS0Ng020322 for ; Wed, 9 Jan 2002 11:28:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g09JRxEn020321 for mobile-ip-dist; Wed, 9 Jan 2002 11:27: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g09JRrNg020306; Wed, 9 Jan 2002 11:27:53 -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 LAA16115; Wed, 9 Jan 2002 11:27:59 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00423; Wed, 9 Jan 2002 12:27:58 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g09JRiF23420; Wed, 9 Jan 2002 11:27:44 -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 AAQ37759; Wed, 9 Jan 2002 11:27:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA13717; Wed, 9 Jan 2002 11:27:43 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.39343.715475.192551@thomasm-u1.cisco.com> Date: Wed, 9 Jan 2002 11:27:43 -0800 (PST) To: Francis Dupont Cc: Michael Thomas , Pekka Nikander , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> References: <15419.14441.941556.661985@thomasm-u1.cisco.com> <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit As originally advertised, I am now convinced that this was indeed a crazy idea -- a bit too good to be true. Thanks for the link on the "loose" RPF checking; I wasn't aware of that. Having to signal many routers in the path would be a non-starter, and ISP's certainly have incentive to perform the loose RPF, therefore this is an insurmountable obstacle. Oh well. Mike Francis Dupont writes: > In your previous mail you wrote: > > [Phil suggested I add mobileip back which was > dropped somewhere along the way] > > I'm not sure we're communicating, so let me be a little > more explicit with what I had in mind: > > 1) MN arrives on new AR > > => many (academic or R&D) sites I know don't use firewalls > (they use a router for filtering) but have a passive management box > which detects new addresses and builds a database with MAC, IP, > name, location, etc, something very useful in case of problems. > So even if classical network access control is not performed on 1) > at the first packet, unusual behaviors are detected (i.e. there is > a passive and without automatic reaction kind of network access control). > At the opposite I know some (commercial) ISPs which use the (traditional) > network access control to punch holes in the firewall for outbound > traffic, i.e. all source addresses are blocked by default and > network access control is used to open some of them (in AAA term > the authorized resource is the Internet access): this is ingress > filtering at the address level, usually it is done at the access > device (e.g. modem) level too. > > 2) It sends a packet using its home address as the > *source* address -- no HAO at all. > > => I propose that the packet is sent to the home agent (or something > similar). > > 3) AR recognizes that the source address is not one of > the subnets it subtends and sends an ICMP message > to MN which explains the problem > > => perhaps I should add a statement in the draft with a requirement > (modulo ICMP rate limitation) for ICMPs when a HAO is filtered out. > I believe a router should implement this by default but a detailed > text should help. > What ICMP? I propose 4 (Parameter Problem) - 2 (unrecognized IPv6 option), > as the router is not the destination of the packet the MN should > understand what's happened. Note that 1 (Destination Unreachable) - > 1 (administratively prohibited) is too ambiguous. > > 4) MN sends AR a normal CN binding update > > => 4) is what I consider as a kind of network access control. > > 5) AR lifts the restriction for that source address > > => the difference with my proposal is here, I propose to accept > corresponding HAOs, you propose to directly open the ingress filtering. > See more comments after. > > 6) MN now sends packets as in (2), but unimpeded > > If MN knows that there is likely to be a source > address check on AR, it can delete steps 2 and 3. > > => i.e. active/reactive modes. > > ICMP seems like a natural here because the router > really is reporting a network problem back to MN > (or not MN if a host were incorrectly configured, > etc). > > => in any case ICMP errors have to be sent when packets are dropped, > I believe we can reach a consensus about this very quickly. > > If this is a subset of your proposal, fine. It > does seem that what I propose gets rid of the HAO > altogether which you don't seem to agree with. > > => in order to get rid of the HAO your proposal has to be > supported on every ingress filtering devices where a packet > from the MN can go though. This is not in fact like path MTU > discovery (which is already difficult to get in the real world) > because your proposal uses a signaling with all the usual > problems of signaling (scalability, security, ...). > Even if to get rid of the HAO would be very nice, I don't > believe this will work in practice. To summary this has the > same kind of problems (i.e. limitations) than micro-mobility > (i.e. mobility based on host routing). > > However, may I suggest that it's the AAA part that > > => I insist about AAA: AAA is not an essential part of > my proposal, it only brings extra goodies: > - an instance of network access control which is well known > and already has proposed extensions for (mobile) IPv6 > - remote network access control > - a connection between local and remote access control. > > has become the lightning rod? And that maybe it > shouldn't be quite so ambitious? :-) > > => too ambitious for a global deployment, and for local/special cases > I am afraid that micro-mobility is more attractive (it gets rid > of the routing header too). > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 10 09: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 JAA15257 for ; Thu, 10 Jan 2002 09:18:19 -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 HAA22888; Thu, 10 Jan 2002 07:17:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22075; Thu, 10 Jan 2002 06:17:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AEGGNg021712 for ; Thu, 10 Jan 2002 06:16:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AEGGOM021711 for mobile-ip-dist; Thu, 10 Jan 2002 06:16: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.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AEG7Ng021704 for ; Thu, 10 Jan 2002 06:16:08 -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 GAA21454 for ; Thu, 10 Jan 2002 06:15:35 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11380 for ; Thu, 10 Jan 2002 07:15:34 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0AEFXJ12605 for ; Thu, 10 Jan 2002 15:15:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jan 10 15:15:19 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 15:15:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1C5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RE: Is RR only enough ? Date: Thu, 10 Jan 2002 15:15:00 +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 g0AEGDNg021705 Sender: owner-mobile-ip@sunroof.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 So this is an attempt to summarise where we are in the discussion. I have made 2 claims as to why this attack is different from today's MITM attacks and to show that RR only would not be enough. These two claims are: 1. The attacker does not have to be a router/switch but can be an end host snooping the link layer. You mentioned that the difference here is subtle because an attacker can overwrite the ARP cache of a router today, and receive all the packets addressed to a legitimate router. I agree that the difference here is very subtle, and unless someone can show that this is significantly different I am inclined to think that this can go in the same container as 'today's MITM attacks' and therefore would add no new harm. 2. The attack can be done despite the presence of e2e security. E2E security (encryption)can be used today to stop these attacks. (I'm excluding DoS-based attacks). Now I think this point is still valid for RR only mechanisms, and I'll try to explain why below in my comments. > > => Sure, but it was suggested that TLS or other upper > > layer security mechanisms can be used to avoid > > these types of attacks today. I don't think they > > would help avoid this attack using the BU. > > By "these attacks" do you mean the DoS impact of the attacks or the > an attack that can modify the content of the communication? => I meant the latter (modifying the content). > The DoS attack by a MiTM can never be prevented. => Agreed. > The modification of content can be prevented with TLS, IPsec, etc. => Agreed. But the connection hijacking which is what I was concerned about, will not be prevented by TLS..etc if RR only is used for the BU. More below. > > Also, I agree with what you say about security > > "Done right", implying the identity exchange between > > the two parties, but perhaps we should document > > somewhere (in the ultimate solution) that this will > > override any other security mechanism for BUs. > > I.e. if there is "proper" SAs already established, > > they should be sufficient for the MN to send > > a BU without the need to run any other mechanism. > > You're skipping a few steps. > > If you want to use an existing SA (IPsec, SSL, whatever) to > protect BUs > the identities associated with the SA needs to be quite different > than what you'd get for other use of security. > E.g. when using SSL to a website you'd like to know that > the identity > is www.example.com; when sending secure email to me you'd like the > identity to be erik.nordmark@sun.com, but for a BU the > identity you'd need > is the home IP address. => Fully agree. I know this contradicts my earlier (inaccurately generalising statement). > > Using security associated with one type of identity for > something else > isn't likely to get the security you'd expect. => Makes sense. > > Thus my personal opinion is that we should make the BU > security be independent > of other (content-oriented) security. Thus if folks want to > use IPsec or SSL > you'd still use the same BU security mechanism. => We're in agreement here. But my point is that, should this BU security mechanism be RR only, MITM can hijack a connection and receive the content that was intended for the legitimate MN. The will happen, despite the presence of e2e security (SSL, TLS, IPsec ...etc) which äwas setup based on the relevant identity. Now this is the major difference from today's networks. We agree (I think) that e2e security would stop connection hijacking (by MITM) today, but it will not stop it if we rely on RR only for BU authentication / authorisation. > > => So the difference is that the BU attacker > > will not have to modify anything, which makes > > him more dangerous if: > > > > 1. upper layer security is used (not IPsec) > > 2. If IPsec is used but the CN still accepts > > RR for BU. (strange situation that we should > > not allow of course). > > > > I agree with the ARP case, However, ND has the potential > > of being secure, but even if it was secured (somehow > > keys are distributed), this problem would still exist. > > ND has the potential to be secure because of the IPsec pixie dust > in the security considerations section??? (Yes, I've > learned some things > since that document became a draft standard without anybody > having implemented > ND secured by IPsec.) => I guess it's a key distribution problem (not exactly a small problem :)) but I always assume that between routers (or in a small network) shared secrets maybe sufficient. But that is not a generic, scalable solution of course. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 10 09:29: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 JAA15404 for ; Thu, 10 Jan 2002 09:29:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01589; Thu, 10 Jan 2002 06:28:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25797; Thu, 10 Jan 2002 06:28:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AERONg021859 for ; Thu, 10 Jan 2002 06:27:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4/Submit) id g0AERO2l021858 for mobile-ip-dist; Thu, 10 Jan 2002 06:27:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta4+Sun/8.12.2.Beta4) with ESMTP id g0AERLNg021851 for ; Thu, 10 Jan 2002 06:27:21 -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 GAA25590 for ; Thu, 10 Jan 2002 06:27:29 -0800 (PST) Received: from web14605.mail.yahoo.com (web14605.mail.yahoo.com [216.136.224.85]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA03068 for ; Thu, 10 Jan 2002 06:27:28 -0800 (PST) Message-ID: <20020110142726.1215.qmail@web14605.mail.yahoo.com> Received: from [203.197.117.226] by web14605.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 06:27:26 PST Date: Thu, 10 Jan 2002 06:27:26 -0800 (PST) From: Durga Prasad Pandey Subject: RE: [mobile-ip] RE: Is RR only enough ? To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C1C5@Esealnt861.al.sw.ericsson.se> 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: Hesham from the discussions of this WG, it seems that the main discussions on M IP nowadays is regarding security issues. I am considering an UG research project in mobile IP. Might this(security issues in mobile IP) be a good area in your opinion. Regards Durga __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 13 12:49: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 MAA13009 for ; Sun, 13 Jan 2002 12:49: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 JAA25089; Sun, 13 Jan 2002 09:47:58 -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 JAA02851; Sun, 13 Jan 2002 09:47:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkmKE027107 for ; Sun, 13 Jan 2002 09:46:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0DHkm66027106 for mobile-ip-dist; Sun, 13 Jan 2002 09:46: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.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkTKE027074; Sun, 13 Jan 2002 09:46:29 -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 JAA04849; Sun, 13 Jan 2002 09:46:36 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02313; Sun, 13 Jan 2002 10:46:35 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 659876A907; Sun, 13 Jan 2002 19:46:22 +0200 (EET) Message-ID: <3C41A751.7010003@piuha.net> Date: Sun, 13 Jan 2002 17:27:13 +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: Francis Dupont Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201070922.g079MAQ13141@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => not exactly, the key term is "rely on". > > I don't think it matters whether the acronym for this > infrastructure was PKI, DNS, or AAA? > > => I agree but it is not forbidden to get advantages of it, only to rely > on it. As we don't rely on ingress filtering for defense against DDoS, > I can't see a problem to propose to use AAA in order to improve ingress > filtering. Yes, it's no problem to improve something. However, improving ingress filting with AAA is not the *whole* picture of what we are doing. You have to remember that by introducing HAO our first step is punching a mile wide hole to the ingress filtering system. And, in fact, you are not improving things by having a smart treatment of the HAO -- you're basically keeping the status quo that we already have with v4. So, in some areas that have both ingress filtering and aaa, you may keep the current status, if the aaa fix to ingress filtering is deployed fast enough. However, on other areas you are nuking an existing security measure some people are using. In this sense you are relying on AAA all over the place, just to keep things as they were before. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 13 12:49: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 MAA13020 for ; Sun, 13 Jan 2002 12:49:02 -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 KAA02185; Sun, 13 Jan 2002 10:48:01 -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 JAA02830; Sun, 13 Jan 2002 09:47:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkRKE027070 for ; Sun, 13 Jan 2002 09:46:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0DHkRG5027069 for mobile-ip-dist; Sun, 13 Jan 2002 09:46: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkOKE027062 for ; Sun, 13 Jan 2002 09:46:24 -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 JAA01698 for ; Sun, 13 Jan 2002 09:46:31 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01899 for ; Sun, 13 Jan 2002 10:46:30 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 87B5A6A908; Sun, 13 Jan 2002 19:46:23 +0200 (EET) Message-ID: <3C41ADE6.1090905@piuha.net> Date: Sun, 13 Jan 2002 17:55:18 +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: "'Erik Nordmark'" Cc: mobile-ip@sunroof.eng.sun.com, "Hesham Soliman (ERA)" Subject: Re: [mobile-ip] RE: Is RR only enough ? 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 > Thus my personal opinion is that we should make the BU security be independent > of other (content-oriented) security. Thus if folks want to use IPsec or SSL > you'd still use the same BU security mechanism. I agree. > ND has the potential to be secure because of the IPsec pixie dust > in the security considerations section? ND can be secure with IPsec, but only in the context of small and fixed networks. On larger networks, the manual keying gets too hard, particularly due to the funny way IPv6 invents new multicast addresses. Remember that you can't use IKE for ND keying since to run IKE you have to discover the peer's address... it's a chicken and egg problem. Given that you don't have automatic keying, you'll have to give up also replay protection, which could have interesting implications if someone bothered to think about it for a while. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 13 12:49:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13031 for ; Sun, 13 Jan 2002 12:49: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 JAA25062; Sun, 13 Jan 2002 09:47: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 JAA02839; Sun, 13 Jan 2002 09:47:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkjKE027104 for ; Sun, 13 Jan 2002 09:46:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0DHkiwY027103 for mobile-ip-dist; Sun, 13 Jan 2002 09:46: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.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHkSKE027072; Sun, 13 Jan 2002 09:46:28 -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 JAA02648; Sun, 13 Jan 2002 09:46:32 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13546; Sun, 13 Jan 2002 10:46:31 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 731086A909; Sun, 13 Jan 2002 19:46:25 +0200 (EET) Message-ID: <3C41B457.6080604@kolumbus.fi> Date: Sun, 13 Jan 2002 18:22:47 +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: Francis Dupont Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis writes: > and that your home agent must be part of the > still-not-existing global AAA infrastructure so that you could use HAO. > > => as I've said, this *recommendation* is for your protection: > without remote network access control you can be a target... Ah, but I think the issue is who the victims are. If *I* add protection in my network, that does *not* guarantee I won't be hit by reflection attacks from someone's network that only has regular ingress filtering (without the stateful and AAA patches). Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 13 12:50: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 MAA13068 for ; Sun, 13 Jan 2002 12:50: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 KAA02750; Sun, 13 Jan 2002 10:49:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03346; Sun, 13 Jan 2002 09:49:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHmHKE027174 for ; Sun, 13 Jan 2002 09:48:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta5+Sun/8.12.2.Beta5/Submit) id g0DHmH0K027173 for mobile-ip-dist; Sun, 13 Jan 2002 09:48: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.Beta5+Sun/8.12.2.Beta5) with ESMTP id g0DHm6KE027152; Sun, 13 Jan 2002 09:48: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 JAA12527; Sun, 13 Jan 2002 09:48:13 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15048; Sun, 13 Jan 2002 09:48:12 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 251FE6A908; Sun, 13 Jan 2002 19:48:04 +0200 (EET) Message-ID: <3C41C1D7.4070509@kolumbus.fi> Date: Sun, 13 Jan 2002 19:20:23 +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 Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201091033.g09AXWQ24892@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, We've had a very long discussion on what to do with MIPv6 Home Address Options and Ingress Filtering, basically centering around (a) solutions restricting HAOs to nodes that employ Route Optimization, (b) solutions employing AAA in firewalls, and (c) solutions that discard HAOs altogether and use BU authentication procedures (e.g. RR) from the access router to the MN. I'm not sure we are near consensus yet -- though we could be, it's hard to say on the list because just a handful of people have participated the discussion. In any case, I'm thinking about how to go forward in a practical manner. We need a solution. And we don't have much time to redesign MIPv6, so I'd really like to see a solution that doesn't need too much new work. But how do we decide between a-c? I have a proposal. But first, let me make some observations: - Most people do seem to agree that HAO reflection is an issue that needs to be dealt with somehow. - A restriction can be relaxed easier than tightened. User groups with better technology can run relaxed versions, or future standard versions can have relaxed rules if we see that the infrastructure around us allows it. - As a general rule, I'd like the Internet to use end-to-end mechanisms more than network assistance. This isn't just an architectural principle, but it will also ensure that we can deploy our things without waiting for providers to catch up. - The different solutions have different impacts on various use cases of MIPv6. Some benefit regular MNs, some those that use RO with a CN, for instance. So, my proposal is as follows: 1. We will not use the alternative (c), because it is not an end-to-end mechanism, because multi-hop ingress filtering could generate delays, and because scalability of intermediate routers with ingress filtering feature might become a question mark if there's a lot of state to hold. As a tradeoff, we have to carry HAOs in our packets. 2. We will have a two-phased approach to the MIPv6 spec and its treatment of reflection attacks: the first phase uses method (a) and the second phase relaxes the rules to allow also (b). The first phase will be put to the MIPv6 RFC. When and if experience shows that we can have AAA-based filtering in access routers and firewalls, an extension can be defined to allow the more relaxed use of HAOs. Comments or other proposals are welcome. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 05:02: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 FAA00559 for ; Mon, 14 Jan 2002 05:02: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 DAA19035; Mon, 14 Jan 2002 03:01:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16044; Mon, 14 Jan 2002 02:01: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 g0E9xe2Q028044 for ; Mon, 14 Jan 2002 01:59:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0E9xenG028043 for mobile-ip-dist; Mon, 14 Jan 2002 01:59: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 g0E9xa2Q028036; Mon, 14 Jan 2002 01:59: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 BAA22878; Mon, 14 Jan 2002 01:59:43 -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 CAA11496; Mon, 14 Jan 2002 02:59:42 -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 g0E9xY505787; Mon, 14 Jan 2002 10:59:34 +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 KAA03071; Mon, 14 Jan 2002 10:59:34 +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 g0E9xXQ45670; Mon, 14 Jan 2002 10:59:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201140959.g0E9xXQ45670@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Sun, 13 Jan 2002 19:20:23 +0200. <3C41C1D7.4070509@kolumbus.fi> Date: Mon, 14 Jan 2002 10:59:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: We've had a very long discussion on what to do with MIPv6 Home Address Options and Ingress Filtering, basically centering around (a) solutions restricting HAOs to nodes that employ Route Optimization, (b) solutions employing AAA in firewalls, and (c) solutions that => for (b) I prefer network access control (AAA is only one way to provide it). discard HAOs altogether and use BU authentication procedures (e.g. RR) from the access router to the MN. I'm not sure we are near consensus yet -- though we could be, it's hard to say on the list because just a handful of people have participated the discussion. => so it seems we have to wait for the face-to-face meeting. I have a proposal. But first, let me make some observations: - Most people do seem to agree that HAO reflection is an issue that needs to be dealt with somehow. => we have to deal with it but we don't need a stronger solution than today ingress filtering which is a BCP, i.e. something like a SHOULD. - A restriction can be relaxed easier than tightened... => this doesn't work in practice because this is a security issue. In the functionality vs security tradeoff, networking people always choose the security, especially when they get no direct benefit from the functionality. There are only a few counter examples (ingress filtering is one of them). - As a general rule, I'd like the Internet to use end-to-end mechanisms more than network assistance. => ingress filtering is network assistance and is enough. If we try a strong solution we'll get more security (i.e. a reply to a minor improvement to an attack) and we'll weaken the functionality (i.e. we'll lose the triangular routing). This isn't just an architectural principle, but it will also ensure that we can deploy our things without waiting for providers to catch up. => clearly you don't believe in current ingress filtering. - The different solutions have different impacts on various use cases of MIPv6. Some benefit regular MNs, some those that use RO with a CN, for instance. => HAO is not MIPv6 only (i.e. be prepared to relax it :-). So, my proposal is as follows: 1. We will not use the alternative (c), because it is not an end-to-end mechanism, because multi-hop ingress filtering could generate delays, and because scalability of intermediate routers with ingress filtering feature might become a question mark if there's a lot of state to hold. As a tradeoff, we have to carry HAOs in our packets. => I agree: (c) is unrealistic. 2. We will have a two-phased approach to the MIPv6 spec and => no, a two phase approach won't work because we'll stay at the first phase. And you put the burden on the wrong people: this is an ingress filtering problem, not a MIPv6 one, so the solution should be in an ingress filtering improvement, not in a new restriction for MIPv6. its treatment of reflection attacks: the first phase uses method (a) and the second phase relaxes the rules to allow also (b). The first phase will be put to the MIPv6 RFC. => if there is a consensus to do that, I propose to split the MIPv6 document into a basic one about bidirectional tunneling with the home agent and a special one about routing optimization, i.e. the lost of the triangular routing should not have only drawbacks. When and if experience shows that we can have AAA-based filtering in access routers and firewalls, an extension can be defined to allow the more relaxed use of HAOs. => this won't have interest, as soon as the use of HAOs will be marginal, it will no more be considered as a real world security threat. Today firewall people have the choice between to ignore HAOs (easy way for them because they have nothing to do) and to filter them out (easy too but they are reluctant to kill HAO). My proposal is to give a third solution (how to do an intelligent filtering), your solution is to kill the HAO for them (so they won't complain :-). Of course your proposal is safe, but I believe the price is a bit too high. Frankly MIPv6 has already enough problems... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 05:07: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 FAA00643 for ; Mon, 14 Jan 2002 05:07:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21913; Mon, 14 Jan 2002 03:06: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 CAA17035; Mon, 14 Jan 2002 02:06: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 g0EA652Q028145 for ; Mon, 14 Jan 2002 02:06:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EA65Kw028144 for mobile-ip-dist; Mon, 14 Jan 2002 02:06:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EA622Q028137; Mon, 14 Jan 2002 02:06: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 CAA09257; Mon, 14 Jan 2002 02:06:08 -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 DAA01090; Mon, 14 Jan 2002 03:06:07 -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 g0EA62507088; Mon, 14 Jan 2002 11:06:02 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03241; Mon, 14 Jan 2002 11:06:02 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0EA62Q45746; Mon, 14 Jan 2002 11:06:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201141006.g0EA62Q45746@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Pekka Nikander , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 13 Jan 2002 18:22:47 +0200. <3C41B457.6080604@kolumbus.fi> Date: Mon, 14 Jan 2002 11:06:02 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > and that your home agent must be part of the > still-not-existing global AAA infrastructure so that you could use HAO. > > => as I've said, this *recommendation* is for your protection: > without remote network access control you can be a target... Ah, but I think the issue is who the victims are. If *I* add protection in my network, that does *not* guarantee I won't => there is *no* guarantee with ingress filtering: its purpose is not to make source address spoofing impossible, it is to make it enough unattractive. be hit by reflection attacks from someone's network that only has regular ingress filtering (without the stateful and AAA patches). => you have forgotten the purpose of ingress filtering. To get the level of security you seems to want, AH should be mandatory (its use, not its implementation). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 05:19: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 FAA00757 for ; Mon, 14 Jan 2002 05:19:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11803; Mon, 14 Jan 2002 02:18:08 -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 CAA18789; Mon, 14 Jan 2002 02: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 g0EAH12Q028258 for ; Mon, 14 Jan 2002 02:17:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EAH1aY028257 for mobile-ip-dist; Mon, 14 Jan 2002 02:17: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 g0EAGw2Q028250; Mon, 14 Jan 2002 02:16: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 CAA10110; Mon, 14 Jan 2002 02:17:04 -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 DAA03102; Mon, 14 Jan 2002 03:17:03 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0EAGj508937; Mon, 14 Jan 2002 11:16: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 LAA03510; Mon, 14 Jan 2002 11:16:45 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0EAGhQ45796; Mon, 14 Jan 2002 11:16:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201141016.g0EAGhQ45796@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: Pekka Nikander , ipng@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Sun, 13 Jan 2002 17:27:13 +0200. <3C41A751.7010003@piuha.net> Date: Mon, 14 Jan 2002 11:16: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: > I don't think it matters whether the acronym for this > infrastructure was PKI, DNS, or AAA? > > => I agree but it is not forbidden to get advantages of it, only to rely > on it. As we don't rely on ingress filtering for defense against DDoS, > I can't see a problem to propose to use AAA in order to improve ingress > filtering. => I should have added that there are two possible improvements to ingress filtering: network access control and full AAA. The first one keeps the status quo, the second gives more. Yes, it's no problem to improve something. However, improving ingress filting with AAA is not the *whole* picture of what we are doing. You have to remember that by introducing HAO our first step is punching a mile wide hole to the ingress filtering system. And, in fact, you are not improving things by having a smart treatment of the HAO -- you're basically keeping the status quo that we already have with v4. => this is about (any kind of) network access control. So, in some areas that have both ingress filtering and aaa, you may keep the current status, if the aaa fix to ingress filtering is deployed fast enough. However, on other areas you are nuking an existing security measure some people are using. In this sense you are relying on AAA all over the place, => please replace AAA by network access control. just to keep things as they were before. => I don't see a problem: we have *not* ingress filtering performed everywhere today. We don't need an absolute solution, we need only to make HAO spoofing enough unattractive as we did need to make source address spoofing enough unattractive... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 09:43: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 JAA03272 for ; Mon, 14 Jan 2002 09:42:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA29876; Mon, 14 Jan 2002 06:41:59 -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 GAA23443; Mon, 14 Jan 2002 06:41: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 g0EEeH2Q028738 for ; Mon, 14 Jan 2002 06:40:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EEeHFM028737 for mobile-ip-dist; Mon, 14 Jan 2002 06:40: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 g0EEeD2Q028730 for ; Mon, 14 Jan 2002 06:40: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 GAA09351 for ; Mon, 14 Jan 2002 06:40:18 -0800 (PST) Received: from iiic.ethz.ch (rif-giga.iiic.ethz.ch [129.132.179.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26960 for ; Mon, 14 Jan 2002 06:40:17 -0800 (PST) Received: from iiic.ethz.ch (airport6.ethz.ch [129.132.30.9]) by iiic.ethz.ch (8.9.3/8.9.3) with ESMTP id PAA04034 for ; Mon, 14 Jan 2002 15:40:16 +0100 (MET) Message-ID: <3C42EDE0.5D8720D4@iiic.ethz.ch> Date: Mon, 14 Jan 2002 15:40:32 +0100 From: Thomas Heinis X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IP address of new access router Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, I have got some problems concerning the Mobile Determined Handover described in draft 3 for Fast Handovers for Mobile IPv6. The MN sends a Router Solicitation for Proxy message to the old access router containing the link local address of the new access router. After that, the old access router is supposed to send a Handover Initiation to the new access router. Wherefrom does the old access router know the IP address of the new access router(unless NAR is a neighbour of the OAR)? The OAR only has the link local address of NAR sent by MN in the Router Solicitation for Proxy. Furthermore I don't really see wherefrom OAR has the prefix information about NAR it should send back to the MN in the Proxy Router Advertisement? Please forgive me if this is the wrong mailing list or if these questions have already been discussed(I've had a look at the archives but didn't find anything). Regards Thomas From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 09:49: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 JAA03365 for ; Mon, 14 Jan 2002 09:49:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02829; Mon, 14 Jan 2002 06:48: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 GAA25714; Mon, 14 Jan 2002 06:48: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 g0EElF2Q028791 for ; Mon, 14 Jan 2002 06:47:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EElFUg028790 for mobile-ip-dist; Mon, 14 Jan 2002 06:47: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 g0EElC2Q028783 for ; Mon, 14 Jan 2002 06:47:12 -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 GAA04613 for ; Mon, 14 Jan 2002 06:46:58 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05000 for ; Mon, 14 Jan 2002 07:46:58 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Jan 2002 09:41:40 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 09:41:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Based on the feedback we'll be making draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt a working group item and waiting on the interoperation with VPN gateways until there is a larger constituency of interest in the WG. > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 10:16: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 KAA03868 for ; Mon, 14 Jan 2002 10:16: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 IAA19097; Mon, 14 Jan 2002 08:14: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 HAA01529; Mon, 14 Jan 2002 07:14: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 g0EFD82Q028853 for ; Mon, 14 Jan 2002 07:13:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EFD8Wk028852 for mobile-ip-dist; Mon, 14 Jan 2002 07:13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EFD52Q028845 for ; Mon, 14 Jan 2002 07:13:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10432 for ; Mon, 14 Jan 2002 07:13:11 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08575 for ; Mon, 14 Jan 2002 07:13:11 -0800 (PST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.28 2002/01/02 21:40:45 root Exp $) with ESMTP id g0EFCn921162 for ; Mon, 14 Jan 2002 15:12:49 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.11 2001/11/09 23:28:01 root Exp $) with SMTP id g0EFCrG22284 for ; Mon, 14 Jan 2002 15:12:53 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011407124107309 for ; Mon, 14 Jan 2002 07:12:41 -0800 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 07:13:10 -0800 Message-ID: <0DCC27458EB5D51181840002A507069EE30D88@orsmsx117.jf.intel.com> From: "Iyer, Prakash" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 07:13:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Was the consensus based on the number of companies. If so, as far as I remember there were only 2 or 3 companies driving NAT requirements and at least as many (if not more) interested in solving the VPN problem. I remember both George and James Kempf raising this issue for discussion and a couple of other vendors noting their interest on the [mobileip-nat-vpn] mailing list. As I had mentioned earlier there were requests on the IPSRA mailing list as well. Maybe the chairs can clarify the basis for this conclusion for the benefit of the working group. Thanks. -Prakash -----Original Message----- From: Phil Roberts [mailto:PRoberts@megisto.com] Sent: Monday, January 14, 2002 6:42 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Based on the feedback we'll be making draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt a working group item and waiting on the interoperation with VPN gateways until there is a larger constituency of interest in the WG. > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 10:24: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 KAA03973 for ; Mon, 14 Jan 2002 10:24:16 -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 HAA19460; Mon, 14 Jan 2002 07:22:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02920; Mon, 14 Jan 2002 07: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 g0EFJt2Q028938 for ; Mon, 14 Jan 2002 07:19:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EFJtcv028937 for mobile-ip-dist; Mon, 14 Jan 2002 07:19:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EFJq2Q028930 for ; Mon, 14 Jan 2002 07:19:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02622 for ; Mon, 14 Jan 2002 07:19:58 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22629 for ; Mon, 14 Jan 2002 08:19:58 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Jan 2002 10:14:40 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 10:14:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sure. When we asked during London there was a large constituency in the room that agreed about the NAT traversal problem. Not so with the VPN gateway traversal and there was some pushback in the private discussion about whether VPN gateway traversal was needed at all. If you can get enough folks to post on the MIP list that they're interested in VPN gateway traversal we can consider whether to pursue a draft on it. Phil > -----Original Message----- > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > Sent: Monday, January 14, 2002 10:13 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Was the consensus based on the number of companies. If so, as far as I > remember there were only > 2 or 3 companies driving NAT requirements and at least as > many (if not more) > interested in solving > the VPN problem. I remember both George and James Kempf > raising this issue > for discussion and a > couple of other vendors noting their interest on the > [mobileip-nat-vpn] > mailing list. As I had > mentioned earlier there were requests on the IPSRA mailing > list as well. > > Maybe the chairs can clarify the basis for this conclusion > for the benefit > of the working group. > Thanks. > > -Prakash > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@megisto.com] > Sent: Monday, January 14, 2002 6:42 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Based on the feedback we'll be making > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > a working group item and waiting on the interoperation with > VPN gateways > until there is > a larger constituency of interest in the WG. > > > > -----Original Message----- > > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 11:42:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06179 for ; Mon, 14 Jan 2002 11:42:48 -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 JAA24180; Mon, 14 Jan 2002 09:41: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 IAA26162; Mon, 14 Jan 2002 08:41:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EGef2Q029125 for ; Mon, 14 Jan 2002 08:40:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EGeeeU029124 for mobile-ip-dist; Mon, 14 Jan 2002 08:40: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 g0EGeb2Q029117 for ; Mon, 14 Jan 2002 08:40: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 IAA00548 for ; Mon, 14 Jan 2002 08:40:44 -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 JAA27389 for ; Mon, 14 Jan 2002 09:40:44 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA18799 for ; Mon, 14 Jan 2002 09:40:40 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA00149 for ; Mon, 14 Jan 2002 09:40:39 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 14 Jan 2002 09:40:37 -0700 Received: from crm.mot.com (nero.crm.mot.com [140.101.173.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id F2EB12EC84; Mon, 14 Jan 2002 17:37:24 +0100 (CET) Message-Id: <3C4309FC.5AB8157F@crm.mot.com> Date: Mon, 14 Jan 2002 17:40:28 +0100 From: Alexis Olivereau Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs References: Content-Type: multipart/mixed; boundary="------------A812EBB69B71CDE23DA8540F" Sender: owner-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. --------------A812EBB69B71CDE23DA8540F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am interested in that topic, too. Phil Roberts wrote: > If you can get enough folks to post on the MIP list that they're > interested in VPN gateway traversal we can consider whether to pursue > a draft on it. --------------A812EBB69B71CDE23DA8540F Content-Type: text/x-vcard; charset=us-ascii; name="Alexis.Olivereau.vcf" Content-Description: Card for Alexis Olivereau Content-Disposition: attachment; filename="Alexis.Olivereau.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Olivereau;Alexis tel;fax:+33 (0)1 69 35 25 01 tel;work:+33 (0)1 69 35 25 16 x-mozilla-html:TRUE org:MOTOROLA LABS;Networking and Applications Lab version:2.1 email;internet:Alexis.Olivereau@crm.mot.com title:Research Engineer adr;quoted-printable:;;Immeuble "Le Columbia"=0D=0AEspace Technologique St Aubin=0D=0A;Gif-sur-Yvette;;91193;FRANCE fn:Alexis Olivereau end:vcard --------------A812EBB69B71CDE23DA8540F-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 11: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 LAA06461 for ; Mon, 14 Jan 2002 11:50:21 -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 IAA05451; Mon, 14 Jan 2002 08:48:57 -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 IAA27459; Mon, 14 Jan 2002 08:47: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 g0EGkb2Q029238 for ; Mon, 14 Jan 2002 08:46:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EGkbIl029237 for mobile-ip-dist; Mon, 14 Jan 2002 08:46: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 g0EGkY2Q029230 for ; Mon, 14 Jan 2002 08:46: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 IAA02028 for ; Mon, 14 Jan 2002 08:46:41 -0800 (PST) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00456 for ; Mon, 14 Jan 2002 09:46:40 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs Date: Mon, 14 Jan 2002 11:46:30 -0500 Message-ID: Thread-Topic: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs Thread-Index: AcGdGn/NGH0eVdp3Sg6TktHEN4e0qwACSxGg From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0EGkY2Q029231 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit One more -----Original Message----- From: Alexis Olivereau [mailto:Alexis_Olivereau-AAO011@email.mot.com] Sent: Monday, January 14, 2002 10:40 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs I am interested in that topic, too. Phil Roberts wrote: > If you can get enough folks to post on the MIP list that they're > interested in VPN gateway traversal we can consider whether to pursue > a draft on it. From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 12:26: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 MAA08202 for ; Mon, 14 Jan 2002 12:26:27 -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 JAA24615; Mon, 14 Jan 2002 09:25:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04140; Mon, 14 Jan 2002 09:24: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 g0EHNr2Q029349 for ; Mon, 14 Jan 2002 09:23:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EHNr0P029348 for mobile-ip-dist; Mon, 14 Jan 2002 09:23:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EHNn2Q029341 for ; Mon, 14 Jan 2002 09:23:49 -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 JAA13015 for ; Mon, 14 Jan 2002 09:23:57 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29218 for ; Mon, 14 Jan 2002 09:23:56 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0EHO7Q19581 for ; Mon, 14 Jan 2002 11:24:07 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 14 Jan 2002 11:23:54 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 11:23:48 -0600 content-class: urn:content-classes:message Subject: [mobile-ip] Changes to RFC2002bis (Vers 8) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 14 Jan 2002 11:23:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD40B@daebe007.NOE.Nokia.com> Thread-Topic: List of changes to be sent to DL Thread-Index: AcGa5n5swJTLzgakEdaxgAAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 14 Jan 2002 17:23:48.0172 (UTC) FILETIME=[3A0FE8C0:01C19D20] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0EHNo2Q029342 Sender: owner-mobile-ip@sunroof.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 following changes have been made to draft-ietf-mobileip-rfc2002-bis-08.txt as it goes through the RFC editors process. A detailed list of all the other minor (editorial) changes was sent by Charlie on Dec 21st, 01 to the Mobile IP WG list. If you have any concerns about the following text, please let the editor (Charles Perkins) know about it, in addition to bringing it to the attention of the WG via the list. The deadline for commenting on this text is Wednesday, Jan 16th, 2002. 1. Section 2.3 1st Paragraph The following text has been added to the end of Paragraph 1: "All mobility agents MUST process packets that they receive addressed to the Mobile-Agents multicast group, at address 224.0.0.11. A mobile node MAY send an Agent Solicitation to 224.0.0.11. All mobility agents SHOULD respond to Agent Solicitations." 2. Section 3.8.3.1. IP/UDP Fields Currently reads: "This section provides the specific rules by which mobile nodes pick" Should be: "This section provides the specific rules by which home agents pick" 3. Section 3.7.2.3 IP Destination Address If the Registration Reply is generated by the Foreign Agent in order to reject the mobile node's Registration Request, and the Registration Request contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Request. Otherwise, if the Registration Reply is received from the Home Agent, and contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Reply. Otherwise, the IP Destination Address of the Registration Reply is set to be 255.255.255.255. Regards, -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 13:35:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11523 for ; Mon, 14 Jan 2002 13:35:31 -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 KAA01556; Mon, 14 Jan 2002 10:33: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 KAA23929; Mon, 14 Jan 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 g0EIUV2Q029524 for ; Mon, 14 Jan 2002 10:30:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EIUVOA029523 for mobile-ip-dist; Mon, 14 Jan 2002 10:30:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EIUS2Q029516 for ; Mon, 14 Jan 2002 10:30: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 KAA06311 for ; Mon, 14 Jan 2002 10:30:36 -0800 (PST) Received: from hotmail.com (f100.law9.hotmail.com [64.4.9.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22565 for ; Mon, 14 Jan 2002 11:30:35 -0700 (MST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Jan 2002 10:30:35 -0800 Received: from 63.78.179.4 by lw9fd.law9.hotmail.msn.com with HTTP; Mon, 14 Jan 2002 18:30:34 GMT X-Originating-IP: [63.78.179.4] From: "Govind Krishnamurthi" To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] IP address of new access router Date: Mon, 14 Jan 2002 13:30:34 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jan 2002 18:30:35.0240 (UTC) FILETIME=[8E75F680:01C19D29] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thomas, The issue of identifying the AR for handover is being discussed in the Seamoby WG as part of CAR discovery. Regards, Govind. >Hi all, >I have got some problems concerning the Mobile Determined Handover >described in draft 3 for Fast Handovers for Mobile IPv6. The MN sends a >Router Solicitation for Proxy message to the old access router >containing the link local address of the new access router. After that, >the old access router is supposed to send a Handover Initiation to the >new access router. Wherefrom does the old access router know the IP >address of the new access router(unless NAR is a neighbour of the OAR)? >The OAR only has the link local address of NAR sent by MN in the Router >Solicitation for Proxy. >Furthermore I don't really see wherefrom OAR has the prefix information >about NAR it should send back to the MN in the Proxy Router >Advertisement? > >Please forgive me if this is the wrong mailing list or if these >questions have already been discussed(I've had a look at the archives >but didn't find anything). > >Regards > >Thomas > _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 13:37: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 NAA11601 for ; Mon, 14 Jan 2002 13:37: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 KAA02590; Mon, 14 Jan 2002 10:35:55 -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 KAA20069; Mon, 14 Jan 2002 10:20: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 g0EIJI2Q029456 for ; Mon, 14 Jan 2002 10:19:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EIJIIq029455 for mobile-ip-dist; Mon, 14 Jan 2002 10:19:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EIJF2Q029448 for ; Mon, 14 Jan 2002 10:19:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20669 for ; Mon, 14 Jan 2002 10:19:22 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19059 for ; Mon, 14 Jan 2002 11:19:22 -0700 (MST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id 111674002F8 for ; Mon, 14 Jan 2002 10:19:22 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id KAA02962 for mobile-ip@sunroof.eng.sun.com; Mon, 14 Jan 2002 10:20:33 -0800 (PST) Date: Mon, 14 Jan 2002 10:20:33 -0800 (PST) From: Joe Lau Message-Id: <200201141820.KAA02962@strtio1.cup.hp.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs In-Reply-To: <3C43014B.C6748122@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Phil Roberts wrote: > > If you can get enough folks to post on the MIP list that > > they're interested in VPN gateway traversal we can > > consider whether to pursue a draft on it. > > OK, count me in then [as one who wants VPN gateway traversal]. Count me in as well. Joe Lau > > > > -----Original Message----- > > > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > > > Sent: Monday, January 14, 2002 10:13 AM > > > To: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > > NATs/VP Ns > > > > > > > > > Was the consensus based on the number of companies. If so, as far as I > > > remember there were only > > > 2 or 3 companies driving NAT requirements and at least as > > > many (if not more) > > > interested in solving > > > the VPN problem. I remember both George and James Kempf > > > raising this issue > > > for discussion and a > > > couple of other vendors noting their interest on the > > > [mobileip-nat-vpn] > > > mailing list. As I had > > > mentioned earlier there were requests on the IPSRA mailing > > > list as well. > > > > > > Maybe the chairs can clarify the basis for this conclusion > > > for the benefit > > > of the working group. > > > Thanks. > > > > > > -Prakash > > > > > > -----Original Message----- > > > From: Phil Roberts [mailto:PRoberts@megisto.com] > > > Sent: Monday, January 14, 2002 6:42 AM > > > To: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > > NATs/VP Ns > > > > > > > > > Based on the feedback we'll be making > > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > > a working group item and waiting on the interoperation with > > > VPN gateways > > > until there is > > > a larger constituency of interest in the WG. > > > > > > > > > > -----Original Message----- > > > > From: Patil Basavaraj (NET/Dallas) > > [mailto:Basavaraj.Patil@nokia.com] > > > Sent: Friday, January 04, 2002 6:59 PM > > > To: 'Mobile IP' > > > Subject: [mobile-ip] Consensus call - MIPv4 interopration > > > with NATs/VPNs > > > > > > > > > In London a design team was formed to investigate the problem of > > > Mobile IPv4 interoperation with NATs and VPNs. At the time there > > > was a clear constituency in the working group that having a solution > > > to NAT traversal was important. It was less clear to the > > > chairs that there was a clear interest in the working group for a > > > specification of the operation of Mobile IPv4 across VPN gateways. To > > > that end we propose that the following draft: > > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > > (the output of the design team) be made into a working group item for > > > progression on the Standards Track. Please let us know in the next > > > few days if you object to this. > > > > > > We would also like to hear feedback from the working group on > > > whether there is a perceived need for a solution to Mobile IPv4 > > > interoperation with VPN gateways. > > > > > > WG Chairs > > > > > -- > Regards, > Uri. > -=-=-<>-=-=- > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 13:40: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 NAA11782 for ; Mon, 14 Jan 2002 13:40: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 LAA28185; Mon, 14 Jan 2002 11:39: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 KAA26169; Mon, 14 Jan 2002 10:39: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 g0EIcT2Q029596 for ; Mon, 14 Jan 2002 10:38:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EIcTPV029595 for mobile-ip-dist; Mon, 14 Jan 2002 10:38: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 g0EIcQ2Q029588; Mon, 14 Jan 2002 10:38:26 -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 KAA27339; Mon, 14 Jan 2002 10:38:34 -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 KAA01525; Mon, 14 Jan 2002 10:38:33 -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 KAA07152; Mon, 14 Jan 2002 10:38:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0EIcWH32679; Mon, 14 Jan 2002 10:38:32 -0800 X-mProtect: Mon, 14 Jan 2002 10:38:32 -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 smtpd8KBd7c; Mon, 14 Jan 2002 10:38:31 PST Message-ID: <3C4325A7.D3EE2E73@iprg.nokia.com> Date: Mon, 14 Jan 2002 10:38:31 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> <3C41B457.6080604@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 Arkko wrote: > > Francis writes: > > > and that your home agent must be part of the > > still-not-existing global AAA infrastructure so that you could use HAO. > > > > => as I've said, this *recommendation* is for your protection: > > without remote network access control you can be a target... > > Ah, but I think the issue is who the victims are. If *I* add > protection in my network, that does *not* guarantee I won't > be hit by reflection attacks from someone's network that only > has regular ingress filtering (without the stateful and AAA > patches). you mean stateful or AAA patches, right? Vijay > > Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 13:43:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11968 for ; Mon, 14 Jan 2002 13:43: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 LAA00943; Mon, 14 Jan 2002 11:42: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 KAA26922; Mon, 14 Jan 2002 10:42: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 g0EIfj2Q029673 for ; Mon, 14 Jan 2002 10:41:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EIfeZj029672 for mobile-ip-dist; Mon, 14 Jan 2002 10:41: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 g0EIfb2Q029665 for ; Mon, 14 Jan 2002 10:41:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26696 for ; Mon, 14 Jan 2002 10:41:45 -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 LAA00080 for ; Mon, 14 Jan 2002 11:41:44 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0EIfgp11104 for ; Mon, 14 Jan 2002 12:41:43 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 12:41:43 -0600 Message-ID: From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 12:41:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D2B.1F079630" Sender: owner-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_01C19D2B.1F079630 Content-Type: text/plain; charset="iso-8859-1" I am interested in this problem. Actually, I have thought about this issue a year ago and have some ideas which might be useful. Mohamed Khalil Nortel Networks -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, January 14, 2002 9:15 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Sure. When we asked during London there was a large constituency in the room that agreed about the NAT traversal problem. Not so with the VPN gateway traversal and there was some pushback in the private discussion about whether VPN gateway traversal was needed at all. If you can get enough folks to post on the MIP list that they're interested in VPN gateway traversal we can consider whether to pursue a draft on it. Phil > -----Original Message----- > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > Sent: Monday, January 14, 2002 10:13 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Was the consensus based on the number of companies. If so, as far as I > remember there were only > 2 or 3 companies driving NAT requirements and at least as > many (if not more) > interested in solving > the VPN problem. I remember both George and James Kempf > raising this issue > for discussion and a > couple of other vendors noting their interest on the > [mobileip-nat-vpn] > mailing list. As I had > mentioned earlier there were requests on the IPSRA mailing > list as well. > > Maybe the chairs can clarify the basis for this conclusion > for the benefit > of the working group. > Thanks. > > -Prakash > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@megisto.com] > Sent: Monday, January 14, 2002 6:42 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Based on the feedback we'll be making > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > a working group item and waiting on the interoperation with > VPN gateways > until there is > a larger constituency of interest in the WG. > > > > -----Original Message----- > > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > ------_=_NextPart_001_01C19D2B.1F079630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Consensus call - MIPv4 interopration with = NATs/VP Ns

I am interested in this problem. Actually, I have = thought about this issue a year ago  and have some ideas which = might be useful.

Mohamed Khalil
Nortel Networks

-----Original Message-----
From: Phil Roberts [mailto:PRoberts@MEGISTO.com]
Sent: Monday, January 14, 2002 9:15 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: [mobile-ip] Consensus call - MIPv4 = interopration with
NATs/VP Ns


Sure.

When we asked during London there was a large = constituency in the room that
agreed about the NAT traversal problem.  Not so = with the VPN gateway
traversal
and there was some pushback in the private = discussion about whether VPN
gateway traversal was needed at all.  If you = can get enough folks to post on
the MIP list that they're interested in VPN gateway = traversal we can
consider
whether to pursue a draft on it.

Phil


> -----Original Message-----
> From: Iyer, Prakash [mailto:prakash.iyer@intel.com= ]
> Sent: Monday, January 14, 2002 10:13 AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Consensus call - MIPv4 = interopration with
> NATs/VP Ns
>
>
> Was the consensus based on the number of = companies. If so, as far as I
> remember there were only
> 2 or 3 companies driving NAT requirements and = at least as
> many (if not more)
> interested in solving
> the VPN problem. I remember both George and = James Kempf
> raising this issue
> for discussion and a
> couple of other vendors noting their interest = on the
> [mobileip-nat-vpn]
> mailing list. As I had
> mentioned earlier there were requests on the = IPSRA mailing
> list as well.
>
> Maybe the chairs can clarify the basis for this = conclusion
> for the benefit
> of the working group.
> Thanks.
>
> -Prakash
>
> -----Original Message-----
> From: Phil Roberts [mailto:PRoberts@megisto.com]
> Sent: Monday, January 14, 2002 6:42 AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Consensus call - MIPv4 = interopration with
> NATs/VP Ns
>
>
> Based on the feedback we'll be making
> = draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt
> a working group item and waiting on the = interoperation with
> VPN gateways
> until there is
> a larger constituency of interest in the = WG.
>
>
> > -----Original Message-----
> > From: Patil Basavaraj (NET/Dallas)
[mailto:Basavaraj.Patil@nokia.c= om]
> Sent: Friday, January 04, 2002 6:59 PM
> To: 'Mobile IP'
> Subject: [mobile-ip] Consensus call - MIPv4 = interopration
> with NATs/VPNs
>
>
> In London a design team was formed to = investigate the problem of
> Mobile IPv4 interoperation with NATs and = VPNs.  At the time there
> was a clear constituency in the working group = that having a solution
> to NAT traversal was important.  It was = less clear to the
> chairs that there was a clear interest in the = working group for a
> specification of the operation of Mobile IPv4 = across VPN gateways.  To
> that end  we propose that the following = draft:
> = draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt
> (the output of the design team) be made into a = working group item for
> progression on the Standards Track.  = Please let us know in the next
> few days if you object to this.
> 
> We would also like to hear feedback from the = working group on
> whether there is a perceived need for a = solution to Mobile IPv4
> interoperation with VPN gateways.
>
> WG Chairs
>

------_=_NextPart_001_01C19D2B.1F079630-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 13:44: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 NAA12103 for ; Mon, 14 Jan 2002 13:44:45 -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 LAA01905; Mon, 14 Jan 2002 11:43: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 KAA27211; Mon, 14 Jan 2002 10:43:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EIgo2Q029693 for ; Mon, 14 Jan 2002 10:42:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EIgnHJ029692 for mobile-ip-dist; Mon, 14 Jan 2002 10:42: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 g0EIgi2Q029685 for ; Mon, 14 Jan 2002 10:42:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24986 for ; Mon, 14 Jan 2002 10:42:43 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20264 for ; Mon, 14 Jan 2002 11:42:43 -0700 (MST) Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g0EIgeS04295 for ; Mon, 14 Jan 2002 10:42:40 -0800 (PST) Message-ID: <138e01c19d2b$524ac170$626015ac@DOCOMOALPER> From: "Alper Yegin" To: References: <3C42EDE0.5D8720D4@iiic.ethz.ch> Subject: Re: [mobile-ip] IP address of new access router Date: Mon, 14 Jan 2002 10:43:13 -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 Thomas, The oldAR can have a static table that maps L2 address of other ARs in the same domain to their IP addresses and the associated prefixes. Or, one can come up with a dynamic discovery protocol to do that, as Govind mentioned being discussed at seamoby. alper ----- Original Message ----- From: "Thomas Heinis" To: Sent: Monday, January 14, 2002 6:40 AM Subject: [mobile-ip] IP address of new access router > Hi all, > I have got some problems concerning the Mobile Determined Handover > described in draft 3 for Fast Handovers for Mobile IPv6. The MN sends a > Router Solicitation for Proxy message to the old access router > containing the link local address of the new access router. After that, > the old access router is supposed to send a Handover Initiation to the > new access router. Wherefrom does the old access router know the IP > address of the new access router(unless NAR is a neighbour of the OAR)? > The OAR only has the link local address of NAR sent by MN in the Router > Solicitation for Proxy. > Furthermore I don't really see wherefrom OAR has the prefix information > about NAR it should send back to the MN in the Proxy Router > Advertisement? > > Please forgive me if this is the wrong mailing list or if these > questions have already been discussed(I've had a look at the archives > but didn't find anything). > > Regards > > Thomas > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 13:53: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 NAA12574 for ; Mon, 14 Jan 2002 13:53: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 KAA09967; Mon, 14 Jan 2002 10:50:23 -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 KAA28701; Mon, 14 Jan 2002 10:50: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 g0EInC2Q029778 for ; Mon, 14 Jan 2002 10:49:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EInC3s029777 for mobile-ip-dist; Mon, 14 Jan 2002 10:49: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 g0EIn82Q029770; Mon, 14 Jan 2002 10:49:08 -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 KAA28360; Mon, 14 Jan 2002 10:49:16 -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 KAA26965; Mon, 14 Jan 2002 10:49:14 -0800 (PST) Received: from jariws1 ([62.248.239.228]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20020114184913.DDWE12197.fep06-app.kolumbus.fi@jariws1>; Mon, 14 Jan 2002 20:49:13 +0200 Message-ID: <003601c19d2c$2b3ca0c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , Cc: References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> <3C41B457.6080604@kolumbus.fi> <3C4325A7.D3EE2E73@iprg.nokia.com> Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access Date: Mon, 14 Jan 2002 20:49:16 +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 > > Ah, but I think the issue is who the victims are. If *I* add > > protection in my network, that does *not* guarantee I won't > > be hit by reflection attacks from someone's network that only > > has regular ingress filtering (without the stateful and AAA > > patches). > > you mean stateful or AAA patches, right? I believe the AAA-assisted ingress filtering has to be stateful, or? Otherwise you'd be asking for the right home address per packet. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 14:11: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 OAA13535 for ; Mon, 14 Jan 2002 14:11: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 MAA23163; Mon, 14 Jan 2002 12:10:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01134; Mon, 14 Jan 2002 11:10:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EJ9D2Q029866 for ; Mon, 14 Jan 2002 11:09:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EJ9DHe029865 for mobile-ip-dist; Mon, 14 Jan 2002 11:09:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EJ9A2Q029858 for ; Mon, 14 Jan 2002 11:09:10 -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 LAA00793 for ; Mon, 14 Jan 2002 11:09:16 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14374 for ; Mon, 14 Jan 2002 12:09:15 -0700 (MST) Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 14:09:12 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB946@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 14:08:32 -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: Hey Phil, I think the NAT traversal problem is relatively easier and the levkowetz-vaarala draft provides a pretty solid solution as a bases for the discussion. The VPN problem is harder and although some work has been done on this by a number of companies/people that participated in the NAT-MIP mailing list the solutions are not as well discussed as their NAT counterparts. Note that there seems to be a market out there for these things and although the technology is not as fundamental as basic Mobile IP, it is necessary if MIP is going to penetrate the corporate markets as well as the DSL/cable based home markets. I say the WG should pick this up... my 2 euro George -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, January 14, 2002 3:15 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Sure. When we asked during London there was a large constituency in the room that agreed about the NAT traversal problem. Not so with the VPN gateway traversal and there was some pushback in the private discussion about whether VPN gateway traversal was needed at all. If you can get enough folks to post on the MIP list that they're interested in VPN gateway traversal we can consider whether to pursue a draft on it. Phil > -----Original Message----- > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > Sent: Monday, January 14, 2002 10:13 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Was the consensus based on the number of companies. If so, as far as I > remember there were only > 2 or 3 companies driving NAT requirements and at least as > many (if not more) > interested in solving > the VPN problem. I remember both George and James Kempf > raising this issue > for discussion and a > couple of other vendors noting their interest on the > [mobileip-nat-vpn] > mailing list. As I had > mentioned earlier there were requests on the IPSRA mailing > list as well. > > Maybe the chairs can clarify the basis for this conclusion > for the benefit > of the working group. > Thanks. > > -Prakash > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@megisto.com] > Sent: Monday, January 14, 2002 6:42 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Based on the feedback we'll be making > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > a working group item and waiting on the interoperation with > VPN gateways > until there is > a larger constituency of interest in the WG. > > > > -----Original Message----- > > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 14:45:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15324 for ; Mon, 14 Jan 2002 14:45:09 -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 MAA19294; Mon, 14 Jan 2002 12: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 LAA19192; Mon, 14 Jan 2002 11:44: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 g0EJh62Q000021 for ; Mon, 14 Jan 2002 11:43:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EJh6E7000020 for mobile-ip-dist; Mon, 14 Jan 2002 11:43:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EJh22Q000013 for ; Mon, 14 Jan 2002 11:43:03 -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 LAA03143 for ; Mon, 14 Jan 2002 11:43:09 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21916 for ; Mon, 14 Jan 2002 11:43:03 -0800 (PST) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 40F1427AB; Mon, 14 Jan 2002 13:43:03 -0600 (CST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 04B81300; Mon, 14 Jan 2002 13:43:02 -0600 (CST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 8D57815D1; Mon, 14 Jan 2002 11:43:02 -0800 (PST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 21B481731; Mon, 14 Jan 2002 11:43:02 -0800 (PST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id OAA0000011906; Mon, 14 Jan 2002 14:42:36 -0500 (EST) From: Brian Haley USG Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id OAA0000003424; Mon, 14 Jan 2002 14:42:01 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA04846; Mon, 14 Jan 2002 14:42:02 -0500 Message-Id: <200201141942.AA04846@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com Subject: [mobile-ip] Changes to RA interval Date: Mon, 14 Jan 2002 14:42:02 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In draft 15 the minimum frequency of Router Advertisements was dropped to .05 seconds from .5 seconds, which a number of us already noticed. But I just realized that the maximum was never decreased from 1.5 seconds, so if I choose a random number between min and max, as RFC 2461 recommends, it will average out near the high end of the scale. Shouldn't the max be reduced to .15 seconds, which after looking at RFC 2461, falls into the "default" range of (min = .33 * max) ? I believe the reason behind the change was to help with movement detection, but it doesn't currently do that much better than draft 13. -Brian From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 15:14: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 PAA16954 for ; Mon, 14 Jan 2002 15:14:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10373; Mon, 14 Jan 2002 13:13: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 MAA00010; Mon, 14 Jan 2002 12:13: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 g0EKCc2Q000303 for ; Mon, 14 Jan 2002 12:12:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EKCc4J000302 for mobile-ip-dist; Mon, 14 Jan 2002 12:12:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EKCZ2Q000291; Mon, 14 Jan 2002 12:12:35 -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 MAA29754; Mon, 14 Jan 2002 12:12:41 -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 MAA11623; Mon, 14 Jan 2002 12:12:31 -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 MAA14719; Mon, 14 Jan 2002 12:12:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0EKCPI11477; Mon, 14 Jan 2002 12:12:25 -0800 X-mProtect: Mon, 14 Jan 2002 12:12:25 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRJq23M; Mon, 14 Jan 2002 12:12:24 PST Message-ID: <3C433BA8.9785AE7A@iprg.nokia.com> Date: Mon, 14 Jan 2002 12:12:24 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access References: <200201071051.g07Ap8Q13420@givry.rennes.enst-bretagne.fr> <3C41B457.6080604@kolumbus.fi> <3C4325A7.D3EE2E73@iprg.nokia.com> <003601c19d2c$2b3ca0c0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > > > Ah, but I think the issue is who the victims are. If *I* add > > > protection in my network, that does *not* guarantee I won't > > > be hit by reflection attacks from someone's network that only > > > has regular ingress filtering (without the stateful and AAA > > > patches). > > > > you mean stateful or AAA patches, right? > > I believe the AAA-assisted ingress filtering has to be > stateful, or? Otherwise you'd be asking for the right home > address per packet. Actually I was trying to say AAA or 'some kind of network access control'. ofcourse both are stateful. sorry about that. Vijay > > Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 16:25: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 QAA20083 for ; Mon, 14 Jan 2002 16:25:38 -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 JAA28341; Mon, 14 Jan 2002 09:06: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 IAA18140; Mon, 14 Jan 2002 08:06: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 g0EG5a2Q029030 for ; Mon, 14 Jan 2002 08:05:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0EG5ah5029029 for mobile-ip-dist; Mon, 14 Jan 2002 08:05:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0EG5X2Q029022 for ; Mon, 14 Jan 2002 08:05:33 -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 IAA18032 for ; Mon, 14 Jan 2002 08:05:39 -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 JAA06327 for ; Mon, 14 Jan 2002 09:05:39 -0700 (MST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0EG5b626264 for ; Mon, 14 Jan 2002 11:05:37 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA07984; Mon, 14 Jan 2002 11:05:33 -0500 (EST) Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA07980; Mon, 14 Jan 2002 11:05:32 -0500 (EST) Message-ID: <3C43014B.C6748122@lucent.com> Date: Mon, 14 Jan 2002 11:03:23 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VPNs 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 Phil Roberts wrote: > If you can get enough folks to post on the MIP list that > they're interested in VPN gateway traversal we can > consider whether to pursue a draft on it. OK, count me in then [as one who wants VPN gateway traversal]. > > -----Original Message----- > > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > > Sent: Monday, January 14, 2002 10:13 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > NATs/VP Ns > > > > > > Was the consensus based on the number of companies. If so, as far as I > > remember there were only > > 2 or 3 companies driving NAT requirements and at least as > > many (if not more) > > interested in solving > > the VPN problem. I remember both George and James Kempf > > raising this issue > > for discussion and a > > couple of other vendors noting their interest on the > > [mobileip-nat-vpn] > > mailing list. As I had > > mentioned earlier there were requests on the IPSRA mailing > > list as well. > > > > Maybe the chairs can clarify the basis for this conclusion > > for the benefit > > of the working group. > > Thanks. > > > > -Prakash > > > > -----Original Message----- > > From: Phil Roberts [mailto:PRoberts@megisto.com] > > Sent: Monday, January 14, 2002 6:42 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > NATs/VP Ns > > > > > > Based on the feedback we'll be making > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > a working group item and waiting on the interoperation with > > VPN gateways > > until there is > > a larger constituency of interest in the WG. > > > > > > > -----Original Message----- > > > From: Patil Basavaraj (NET/Dallas) > [mailto:Basavaraj.Patil@nokia.com] > > Sent: Friday, January 04, 2002 6:59 PM > > To: 'Mobile IP' > > Subject: [mobile-ip] Consensus call - MIPv4 interopration > > with NATs/VPNs > > > > > > In London a design team was formed to investigate the problem of > > Mobile IPv4 interoperation with NATs and VPNs. At the time there > > was a clear constituency in the working group that having a solution > > to NAT traversal was important. It was less clear to the > > chairs that there was a clear interest in the working group for a > > specification of the operation of Mobile IPv4 across VPN gateways. To > > that end we propose that the following draft: > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > (the output of the design team) be made into a working group item for > > progression on the Standards Track. Please let us know in the next > > few days if you object to this. > > > > We would also like to hear feedback from the working group on > > whether there is a perceived need for a solution to Mobile IPv4 > > interoperation with VPN gateways. > > > > WG Chairs > > -- Regards, Uri. -=-=-<>-=-=- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 14 18:50: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 SAA26143 for ; Mon, 14 Jan 2002 18:50:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00898; Mon, 14 Jan 2002 16:49:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09091; Mon, 14 Jan 2002 15:49: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 g0ENm82Q000623 for ; Mon, 14 Jan 2002 15:48:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0ENm812000622 for mobile-ip-dist; Mon, 14 Jan 2002 15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0ENm52Q000615 for ; Mon, 14 Jan 2002 15:48:05 -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 PAA04843 for ; Mon, 14 Jan 2002 15:48:12 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06447 for ; Mon, 14 Jan 2002 15:48:11 -0800 (PST) Received: by RRMAIL01 with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 18:48:10 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB94C@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Mon, 14 Jan 2002 18:48:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I got multiple 'complaints' that 2 euros is too much money! Since I did not mean to be arrogant I take it back and say.... my 2 euro-cents :-) George -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: Monday, January 14, 2002 7:09 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Hey Phil, I think the NAT traversal problem is relatively easier and the levkowetz-vaarala draft provides a pretty solid solution as a bases for the discussion. The VPN problem is harder and although some work has been done on this by a number of companies/people that participated in the NAT-MIP mailing list the solutions are not as well discussed as their NAT counterparts. Note that there seems to be a market out there for these things and although the technology is not as fundamental as basic Mobile IP, it is necessary if MIP is going to penetrate the corporate markets as well as the DSL/cable based home markets. I say the WG should pick this up... my 2 euro George -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Monday, January 14, 2002 3:15 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Sure. When we asked during London there was a large constituency in the room that agreed about the NAT traversal problem. Not so with the VPN gateway traversal and there was some pushback in the private discussion about whether VPN gateway traversal was needed at all. If you can get enough folks to post on the MIP list that they're interested in VPN gateway traversal we can consider whether to pursue a draft on it. Phil > -----Original Message----- > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > Sent: Monday, January 14, 2002 10:13 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Was the consensus based on the number of companies. If so, as far as I > remember there were only > 2 or 3 companies driving NAT requirements and at least as > many (if not more) > interested in solving > the VPN problem. I remember both George and James Kempf > raising this issue > for discussion and a > couple of other vendors noting their interest on the > [mobileip-nat-vpn] > mailing list. As I had > mentioned earlier there were requests on the IPSRA mailing > list as well. > > Maybe the chairs can clarify the basis for this conclusion > for the benefit > of the working group. > Thanks. > > -Prakash > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@megisto.com] > Sent: Monday, January 14, 2002 6:42 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Based on the feedback we'll be making > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > a working group item and waiting on the interoperation with > VPN gateways > until there is > a larger constituency of interest in the WG. > > > > -----Original Message----- > > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Friday, January 04, 2002 6:59 PM > To: 'Mobile IP' > Subject: [mobile-ip] Consensus call - MIPv4 interopration > with NATs/VPNs > > > In London a design team was formed to investigate the problem of > Mobile IPv4 interoperation with NATs and VPNs. At the time there > was a clear constituency in the working group that having a solution > to NAT traversal was important. It was less clear to the > chairs that there was a clear interest in the working group for a > specification of the operation of Mobile IPv4 across VPN gateways. To > that end we propose that the following draft: > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > (the output of the design team) be made into a working group item for > progression on the Standards Track. Please let us know in the next > few days if you object to this. > > We would also like to hear feedback from the working group on > whether there is a perceived need for a solution to Mobile IPv4 > interoperation with VPN gateways. > > WG Chairs > From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 03:27: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 DAA15224 for ; Tue, 15 Jan 2002 03:27:20 -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 BAA15067; Tue, 15 Jan 2002 01:25: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 AAA16860; Tue, 15 Jan 2002 00:25: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 g0F8OP2Q000914 for ; Tue, 15 Jan 2002 00:24:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0F8OPWq000913 for mobile-ip-dist; Tue, 15 Jan 2002 00:24:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F8OK2Q000906; Tue, 15 Jan 2002 00:24:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0F8OL312717; Tue, 15 Jan 2002 09:24:22 +0100 (MET) Date: Mon, 14 Jan 2002 20:44:18 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: jari.arkko@kolumbus.fi Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C41C1D7.4070509@kolumbus.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: > - As a general rule, I'd like the Internet to use end-to-end > mechanisms more than network assistance. This isn't just > an architectural principle, but it will also ensure that > we can deploy our things without waiting for providers to > catch up. I agree. But I would personally make a stronger statement since I'm concerned with the direction of piling more and more requirements and dependencies on AAA. Thus I think the AAA approach is the wrong one - if we collectively can make AAA/Diameter do the things needed to make Radius more usable (reliabiliy, security, some extensibility) I think we've collectively have been successful. Keep piling more stuff on the AAA system and it might very well get too heavy to be able to fly... Also, waiting for AAA solutions to be available (specified, implemeted, and deployed) before MIPv6 can be used seems to be counter to our desire to finish up MIPv6 soon. > 1. We will not use the alternative (c), because it is not > an end-to-end mechanism, because multi-hop ingress > filtering could generate delays, and because scalability > of intermediate routers with ingress filtering feature > might become a question mark if there's a lot of state to > hold. As a tradeoff, we have to carry HAOs in our packets. > > 2. We will have a two-phased approach to the MIPv6 spec and > its treatment of reflection attacks: the first phase uses > method (a) and the second phase relaxes the rules to allow > also (b). The first phase will be put to the MIPv6 RFC. > When and if experience shows that we can have AAA-based > filtering in access routers and firewalls, an extension > can be defined to allow the more relaxed use of HAOs. While I have concerns with using the AAA per above I think the phased approach (where the AAA approach continues to be discussed and further understood) makes sense to me. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 04:01:53 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15639 for ; Tue, 15 Jan 2002 04:01: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 BAA26791; Tue, 15 Jan 2002 01:00: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 BAA20904; Tue, 15 Jan 2002 01:00:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0F8xD2Q001031 for ; Tue, 15 Jan 2002 00:59:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0F8xCZB001030 for mobile-ip-dist; Tue, 15 Jan 2002 00:59: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 g0F8x62Q001015; Tue, 15 Jan 2002 00:59:06 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27678; Tue, 15 Jan 2002 00:59:12 -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 AAA22950; Tue, 15 Jan 2002 00:59:11 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0F8x9Z01846; Tue, 15 Jan 2002 10:59:09 +0200 Date: Tue, 15 Jan 2002 10:59:09 +0200 (EET) From: Pekka Savola To: cc: Jari Arkko , Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201140959.g0E9xXQ45670@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 14 Jan 2002, Francis Dupont wrote: [snip] > 2. We will have a two-phased approach to the MIPv6 spec and > > => no, a two phase approach won't work because we'll stay at > the first phase. [snip] If we'd stay at the first phase, that'd probably mean that the stateful network access control mechanism wasn't attractive and wide-spread enough? -- Which is one of the points here. If one would want to differentiate between "network access controlled (no checks in end-nodes)" and "in god we trust, others must be checked", perhaps Home Address Option sub-options could be used? (or identically defined another HAO.) > And you put the burden on the wrong people: > this is an ingress filtering problem, not a MIPv6 one, so > the solution should be in an ingress filtering improvement, > not in a new restriction for MIPv6. (a bit tongue-in-cheek) If QWERTY working group would define a new mechanism for storing effective source address in a varying location of IP header chain, under some destination option's freshly defined fourth option's third sub-option (padded to 2n+x), would digging that out and just coping with it be "ingress filtering problem" too? If AZERTY working group would make new requirements (caused by said working group's new proposal) for ingress filtering, so that it could not be done in practise, would finding new ways to do ingress filtering befall ingress filtering people too? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 04:24: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 EAA15935 for ; Tue, 15 Jan 2002 04:24:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13639; Tue, 15 Jan 2002 02:23: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 BAA23078; Tue, 15 Jan 2002 01:23: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 g0F9M42Q001169 for ; Tue, 15 Jan 2002 01:22:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0F9M4G6001168 for mobile-ip-dist; Tue, 15 Jan 2002 01:22: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 g0F9Lu2Q001153; Tue, 15 Jan 2002 01:21:56 -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 BAA22968; Tue, 15 Jan 2002 01:22:02 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00277; Tue, 15 Jan 2002 02:22:02 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0F9M0531215; Tue, 15 Jan 2002 10:22:00 +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 KAA26908; Tue, 15 Jan 2002 10:22:00 +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 g0F9LxQ50432; Tue, 15 Jan 2002 10:21:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201150921.g0F9LxQ50432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: IPv6 ingress filtering early access In-reply-to: Your message of Mon, 14 Jan 2002 10:38:31 PST. <3C4325A7.D3EE2E73@iprg.nokia.com> Date: Tue, 15 Jan 2002 10:21:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Ah, but I think the issue is who the victims are. If *I* add > protection in my network, that does *not* guarantee I won't > be hit by reflection attacks from someone's network that only > has regular ingress filtering (without the stateful and AAA > patches). you mean stateful or AAA patches, right? => Jari meant stateful and network access control patches (the state is the knowledge of active bindings, network access control patches give this knowledge). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 05:48:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17065 for ; Tue, 15 Jan 2002 05:48: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 DAA24084; Tue, 15 Jan 2002 03:47:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22869; Tue, 15 Jan 2002 02:47:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FAk42Q001434 for ; Tue, 15 Jan 2002 02:46:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FAk46J001433 for mobile-ip-dist; Tue, 15 Jan 2002 02:46:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FAjv2Q001418; Tue, 15 Jan 2002 02:45:57 -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 CAA24680; Tue, 15 Jan 2002 02:46:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23405; Tue, 15 Jan 2002 03:46:03 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FAk1513864; Tue, 15 Jan 2002 11:46:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA29207; Tue, 15 Jan 2002 11:46:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FAk1Q50869; Tue, 15 Jan 2002 11:46:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151046.g0FAk1Q50869@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Mon, 14 Jan 2002 20:44:18 +0100. Date: Tue, 15 Jan 2002 11:46:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => first I have submitted the draft, second I tried to make clear that my proposal relies only on (any kind of) network access control (i.e. anything more that just plug and play). AAA is an implementation option which has extra benefits. > - As a general rule, I'd like the Internet to use end-to-end > mechanisms more than network assistance. This isn't just > an architectural principle, but it will also ensure that > we can deploy our things without waiting for providers to > catch up. I agree. But I would personally make a stronger statement since I'm concerned with the direction of piling more and more requirements and dependencies on AAA. Thus I think the AAA approach is the wrong one - if we collectively can make AAA/Diameter do the things needed to make Radius more usable => for my purpose Radius is enough (only a new attribute is needed for the home address, a new version of RFC 3162 ?) (reliabiliy, security, some extensibility) I think we've collectively have been successful. Keep piling more stuff on the AAA system and it might very well get too heavy to be able to fly... => I agree but AAA is the only way to provide (one day) remote network access control (*not* necessary but fine). Also, waiting for AAA solutions to be available (specified, implemeted, and deployed) before MIPv6 can be used seems to be counter to our desire to finish up MIPv6 soon. => I never proposed to wait for AAA solutions (as I ask only for network access control, not everywhere but enough to make HAO spoofing unattractive). While I have concerns with using the AAA per above I think the phased approach (where the AAA approach continues to be discussed and further understood) makes sense to me. => have you still concerns with using network access control in a BCP? Regards Francis.Dupont@enst-bretagne.fr PS (for the IPv6 WG list): my draft is about HAO vs ingress filtering, I assume there is a consensus about traditional ingress filtering, i.e. RFC 2827 is applicable to IPv6 (i.e. we don't need another document and we'll get tradition IPv6 ingress filtering (access lists and unicast RPF) support in the next router software version (I apologize if this is already available)). From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 06:25:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17489 for ; Tue, 15 Jan 2002 06:25:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10885; Tue, 15 Jan 2002 04:24: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 DAA29628; Tue, 15 Jan 2002 03:23: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 g0FBMx2Q001564 for ; Tue, 15 Jan 2002 03:22:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FBMxqJ001563 for mobile-ip-dist; Tue, 15 Jan 2002 03:22: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 g0FBMr2Q001548; Tue, 15 Jan 2002 03:22:53 -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 DAA09083; Tue, 15 Jan 2002 03:22:58 -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 EAA20177; Tue, 15 Jan 2002 04:22: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 g0FBMt520060; Tue, 15 Jan 2002 12:22: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 MAA00193; Tue, 15 Jan 2002 12:22: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 g0FBMsQ51007; Tue, 15 Jan 2002 12:22:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151122.g0FBMsQ51007@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 10:59:09 +0200. Date: Tue, 15 Jan 2002 12:22: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: On Mon, 14 Jan 2002, Francis Dupont wrote: [snip] > 2. We will have a two-phased approach to the MIPv6 spec and > > => no, a two phase approach won't work because we'll stay at > the first phase. [snip] If we'd stay at the first phase, that'd probably mean that the stateful network access control mechanism wasn't attractive and wide-spread enough? -- Which is one of the points here. => no, you haven't understood. The problem is not technical, it is psychological: you can't have this kind of two phase approach for a security device, you won't be able to relax something, in fact it will be hard to get the first phase not be hardened. For instance RFC 2401 explains that in tunnel mode the outer source address should not be checked, most implementers do the check just because it seems a bit more secure... If one would want to differentiate between "network access controlled (no checks in end-nodes)" and "in god we trust, others must be checked", perhaps Home Address Option sub-options could be used? (or identically defined another HAO.) => I have no concern about "in god we trust"... This is already the case for ingress filtering and this is effective, i.e. random source address spoofing is no more heavily used in DDoS attacks. This follows the same mechanism than vaccination against an epidemic. > And you put the burden on the wrong people: > this is an ingress filtering problem, not a MIPv6 one, so > the solution should be in an ingress filtering improvement, > not in a new restriction for MIPv6. (a bit tongue-in-cheek) If QWERTY working group would define a new mechanism for storing effective source address in a varying location of IP header chain, under some destination option's freshly defined fourth option's third sub-option (padded to 2n+x), would digging that out and just coping with it be "ingress filtering problem" too? => I think so (this is why I prefer the firewall based part of ingress filtering because firewalls have to be prepared to dig into packets anyway). If AZERTY working group would make new requirements (caused by said working group's new proposal) for ingress filtering, so that it could not be done in practice, would finding new ways to do ingress filtering befall ingress filtering people too? => this depends on who gets the benefits: if there are mainly global benefits (as for home address declarations in order to limit HAOs), I believe this is a topic for ingress filtering people, if there are mainly benefits for a particular population (as for HAO filtering using remote network access control, i.e. certified/verified home addresses), I believe this is not a topic for ingress filtering people (in my example this is a topic for AAA people). We can consider where are the difficulties too but in a well engineered system both should be equivalent (this is a practical problem too, if you get the difficulties and not the benefits nothing will happen, this is my concern about correspondent node based features). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 07:52:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20654 for ; Tue, 15 Jan 2002 07:52: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 FAA17722; Tue, 15 Jan 2002 05:50: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 EAA22499; Tue, 15 Jan 2002 04: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 g0FCnW2Q001752 for ; Tue, 15 Jan 2002 04:49:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FCnW1W001750 for mobile-ip-dist; Tue, 15 Jan 2002 04: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FCnQ2Q001735 for ; Tue, 15 Jan 2002 04:49:26 -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 EAA22223 for ; Tue, 15 Jan 2002 04:49:32 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17107 for ; Tue, 15 Jan 2002 05:49:31 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0FCnRJ18251 for ; Tue, 15 Jan 2002 13:49:31 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jan 15 13:49:10 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 13:40:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C1FD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jari Arkko Cc: ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RE: How to move forward in the HAO & ingress filter discussion Date: Tue, 15 Jan 2002 13:49:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis > I have a proposal. But first, let me make some observations: > > - Most people do seem to agree that HAO reflection is an > issue that needs to be dealt with somehow. > > => we have to deal with it but we don't need a stronger solution > than today ingress filtering which is a BCP, i.e. something like > a SHOULD. => But how can that be true ?? Today's ingress filtering is clearly insufficient for HAO issues. Or perhaps you mean we need a solution that doesn't have to be mandated (SHOULD instead of MUST) ? If so, this is too early to discuss, we don't have an agreement on a solution yet. I haven't heard anyone answering my question as to why reverse tunnelling by the MN thru the HA is so much worse than triangular routing, that we need to develop something new to fix the HAO problem 'only sometimes'. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 08:27:53 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21881 for ; Tue, 15 Jan 2002 08:27:52 -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 FAA13772; Tue, 15 Jan 2002 05:26: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 FAA10292; Tue, 15 Jan 2002 05:26: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 g0FDPV2Q001918 for ; Tue, 15 Jan 2002 05:25:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FDPVbc001917 for mobile-ip-dist; Tue, 15 Jan 2002 05: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FDPR2Q001910; Tue, 15 Jan 2002 05:25:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10190; Tue, 15 Jan 2002 05:25:34 -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 GAA03412; Tue, 15 Jan 2002 06:25:33 -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 g0FDPR509919; Tue, 15 Jan 2002 14:25:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA03020; Tue, 15 Jan 2002 14:25:28 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0FDPRQ51519; Tue, 15 Jan 2002 14:25:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151325.g0FDPRQ51519@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 13:49:00 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C1FD@Esealnt861.al.sw.ericsson.se> Date: Tue, 15 Jan 2002 14:25:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > I have a proposal. But first, let me make some observations: > > - Most people do seem to agree that HAO reflection is an > issue that needs to be dealt with somehow. > > => we have to deal with it but we don't need a stronger solution > than today ingress filtering which is a BCP, i.e. something like > a SHOULD. => But how can that be true ?? => the answer is both bad and good news: ingress filtering is effective against random source address snooping, but not against DDoS itself or source address snooping using a small variation on the last bits (i.e. staying in the same prefix). Of course the last point is very worrying for IPv6 (maximal prefix length is 64 bits, i.e. 64 bits at least are free for this kind of attacks). But this is more a threat against RFC 3041 than HAO... Today's ingress filtering is clearly insufficient for HAO issues. => do you mean we have to do more about HAO than about standard source address snooping? Or perhaps you mean we need a solution that doesn't have to be mandated (SHOULD instead of MUST) ? => exactly, we don't need something stronger than a BCP (a loose SHOULD). If so, this is too early to discuss, we don't have an agreement on a solution yet. => my concern is we have no agreement on the problem too. (I don't put a smile because this is no more funny) I haven't heard anyone answering my question as to why reverse tunnelling by the MN thru the HA is so much worse than triangular routing, => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) d(optimization) = 2 * d(MN,CN) and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) so d(optimization) <= d(triangular) <= d(bidir tunnel) and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) i.e. in my poor English the cost/performance of triangular routing is at the middle of bidirectional tunneling and routing optimization. that we need to develop something new to fix the HAO problem 'only sometimes'. => my argument is that ingress filtering is an 'only sometimes' reply to the (random) source address spoofing problem. If your question is "why not drop the draft 15 and restart from the beginning with a bidirectional tunneling (only in the first phase) solution", this is another (interesting) question (I suggest to restrict it to the mobile IP WG list). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 09:26: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 JAA24406 for ; Tue, 15 Jan 2002 09:26:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04156; Tue, 15 Jan 2002 06:25:20 -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 GAA09804; Tue, 15 Jan 2002 06:25: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 g0FEO72Q002232 for ; Tue, 15 Jan 2002 06:24:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FEO7HR002231 for mobile-ip-dist; Tue, 15 Jan 2002 06:24: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 g0FEO02Q002216; Tue, 15 Jan 2002 06:24:00 -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 GAA09652; Tue, 15 Jan 2002 06:24:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26861; Tue, 15 Jan 2002 07:24:05 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0FEO4V04643; Tue, 15 Jan 2002 16:24:04 +0200 Date: Tue, 15 Jan 2002 16:24:03 +0200 (EET) From: Pekka Savola To: cc: "Hesham Soliman (ERA)" , Jari Arkko , Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201151325.g0FDPRQ51519@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 15 Jan 2002, Francis Dupont wrote: > I haven't heard anyone answering my question as to why > reverse tunnelling by the MN thru the HA is so much > worse than triangular routing, > > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. In theory, yes. But the question is, does it really make that much of a difference as long as at least one way is "unoptimized"? Practise? I don't think there's much difference in bidir tunnel/triangular routing; I doubt e.g. TCP would be able to get much better performance from triangular than from bi-dir (and there are goals like hiding your origins that triangular cannot solve). -- 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 Jan 15 09:44: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 JAA25168 for ; Tue, 15 Jan 2002 09:44: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 HAA18907; Tue, 15 Jan 2002 07:43: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 GAA14865; Tue, 15 Jan 2002 06: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 g0FEgb2Q002339 for ; Tue, 15 Jan 2002 06:42:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FEgbYg002338 for mobile-ip-dist; Tue, 15 Jan 2002 06:42: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 g0FEgX2Q002331 for ; Tue, 15 Jan 2002 06:42:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14711 for ; Tue, 15 Jan 2002 06:42:41 -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 HAA26829 for ; Tue, 15 Jan 2002 07:42:39 -0700 (MST) Received: from chardonnay (ipunplugged.com [192.168.4.5]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA15882 for ; Tue, 15 Jan 2002 15:41:07 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Tue, 15 Jan 2002 15:42:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe that VPN interaction is of interest to mobile IP, but also that the problem is not as simple and well understood yet as the NAT traversal, and would benefit from more work and discussions. In particular, I'm not convinced that the solution in the adrangi draft is the best we can come up with. There's a short discussion of different scenarios in http://www.levkowetz.com/pub/id/nat-vpn-scenarios.html, but I believe there is more to be said and thought on the subject.. :-) Best regards, Henrik > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Phil Roberts > Sent: Monday, January 14, 2002 4:15 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Sure. > > When we asked during London there was a large constituency in the room that > agreed about the NAT traversal problem. Not so with the VPN gateway > traversal > and there was some pushback in the private discussion about whether VPN > gateway traversal was needed at all. If you can get enough folks to post on > the MIP list that they're interested in VPN gateway traversal we can > consider > whether to pursue a draft on it. > > Phil > > > > -----Original Message----- > > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > > Sent: Monday, January 14, 2002 10:13 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > NATs/VP Ns > > > > > > Was the consensus based on the number of companies. If so, as far as I > > remember there were only > > 2 or 3 companies driving NAT requirements and at least as > > many (if not more) > > interested in solving > > the VPN problem. I remember both George and James Kempf > > raising this issue > > for discussion and a > > couple of other vendors noting their interest on the > > [mobileip-nat-vpn] > > mailing list. As I had > > mentioned earlier there were requests on the IPSRA mailing > > list as well. > > > > Maybe the chairs can clarify the basis for this conclusion > > for the benefit > > of the working group. > > Thanks. > > > > -Prakash > > > > -----Original Message----- > > From: Phil Roberts [mailto:PRoberts@megisto.com] > > Sent: Monday, January 14, 2002 6:42 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > NATs/VP Ns > > > > > > Based on the feedback we'll be making > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > a working group item and waiting on the interoperation with > > VPN gateways > > until there is > > a larger constituency of interest in the WG. > > > > > > > -----Original Message----- > > > From: Patil Basavaraj (NET/Dallas) > [mailto:Basavaraj.Patil@nokia.com] > > Sent: Friday, January 04, 2002 6:59 PM > > To: 'Mobile IP' > > Subject: [mobile-ip] Consensus call - MIPv4 interopration > > with NATs/VPNs > > > > > > In London a design team was formed to investigate the problem of > > Mobile IPv4 interoperation with NATs and VPNs. At the time there > > was a clear constituency in the working group that having a solution > > to NAT traversal was important. It was less clear to the > > chairs that there was a clear interest in the working group for a > > specification of the operation of Mobile IPv4 across VPN gateways. To > > that end we propose that the following draft: > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > (the output of the design team) be made into a working group item for > > progression on the Standards Track. Please let us know in the next > > few days if you object to this. > > > > We would also like to hear feedback from the working group on > > whether there is a perceived need for a solution to Mobile IPv4 > > interoperation with VPN gateways. > > > > WG Chairs > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 09:59: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 JAA25858 for ; Tue, 15 Jan 2002 09:59:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15426; Tue, 15 Jan 2002 06:51: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 GAA13935; Tue, 15 Jan 2002 06:39: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 g0FEcr2Q002291 for ; Tue, 15 Jan 2002 06:38:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FEcrYc002290 for mobile-ip-dist; Tue, 15 Jan 2002 06:38: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 g0FEco2Q002283 for ; Tue, 15 Jan 2002 06:38:50 -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 GAA08386 for ; Tue, 15 Jan 2002 06:38:57 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15373 for ; Tue, 15 Jan 2002 07:38:57 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0FEctf11214; Tue, 15 Jan 2002 08:38:55 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 08:38:55 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF65F@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Basavaraj.Patil@nokia.com'" Subject: RE: [mobile-ip] Changes to RFC2002bis (Vers 8) Date: Tue, 15 Jan 2002 08:38:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DD2.5E252470" Sender: owner-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_01C19DD2.5E252470 Content-Type: text/plain; charset="iso-8859-1" Hello Basavaraj; Could you please brief us with the rationale behind the changes of the 1st paragraph in section 2.3? As far as I know, the Mobile Node as per RFC2002-bis and RFC1256 can send Agent Solicitation message to either 255.255.255.255 or 224.0.0.2. Thanks for the explanation. Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Monday, January 14, 2002 11:24 AM To: 'Mobile IP' Subject: [mobile-ip] Changes to RFC2002bis (Vers 8) The following changes have been made to draft-ietf-mobileip-rfc2002-bis-08.txt as it goes through the RFC editors process. A detailed list of all the other minor (editorial) changes was sent by Charlie on Dec 21st, 01 to the Mobile IP WG list. If you have any concerns about the following text, please let the editor (Charles Perkins) know about it, in addition to bringing it to the attention of the WG via the list. The deadline for commenting on this text is Wednesday, Jan 16th, 2002. 1. Section 2.3 1st Paragraph The following text has been added to the end of Paragraph 1: "All mobility agents MUST process packets that they receive addressed to the Mobile-Agents multicast group, at address 224.0.0.11. A mobile node MAY send an Agent Solicitation to 224.0.0.11. All mobility agents SHOULD respond to Agent Solicitations." 2. Section 3.8.3.1. IP/UDP Fields Currently reads: "This section provides the specific rules by which mobile nodes pick" Should be: "This section provides the specific rules by which home agents pick" 3. Section 3.7.2.3 IP Destination Address If the Registration Reply is generated by the Foreign Agent in order to reject the mobile node's Registration Request, and the Registration Request contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Request. Otherwise, if the Registration Reply is received from the Home Agent, and contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Reply. Otherwise, the IP Destination Address of the Registration Reply is set to be 255.255.255.255. Regards, -Basavaraj ------_=_NextPart_001_01C19DD2.5E252470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Changes to RFC2002bis (Vers 8)

Hello Basavaraj;

Could you please brief us with the rationale behind = the changes of the 1st paragraph in section 2.3?
As far as I know, the Mobile Node as per RFC2002-bis = and RFC1256 can send Agent Solicitation message to either
255.255.255.255 or 224.0.0.2.

Thanks for the explanation.

Regards;

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



-----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.c= om]
Sent: Monday, January 14, 2002 11:24 AM
To: 'Mobile IP'
Subject: [mobile-ip] Changes to RFC2002bis (Vers = 8)


The following changes have been made to
draft-ietf-mobileip-rfc2002-bis-08.txt as it goes = through the RFC
editors process. A detailed list of all the other = minor (editorial)
changes was sent by Charlie on Dec 21st, 01 to the = Mobile IP WG list.

If you have any concerns about the following text, = please let the
editor (Charles Perkins) know about it, in addition = to bringing it to
the attention of the WG via the list. The deadline = for commenting on
this text is Wednesday, Jan 16th, 2002.

1. Section 2.3 1st Paragraph
  
   The following text has been added to = the end of Paragraph 1:

   "All mobility agents MUST process = packets that they
   receive addressed to the Mobile-Agents = multicast group, at address
   224.0.0.11.  A mobile node MAY = send an Agent Solicitation to
   224.0.0.11.  All mobility agents = SHOULD respond to Agent
   Solicitations."

2. Section 3.8.3.1. IP/UDP Fields

   Currently reads:
   "This section provides the = specific rules by which mobile nodes
   pick"
   Should be:
   "This section provides the = specific rules by which home agents
   pick"

3. Section 3.7.2.3

      IP Destination = Address

          &nb= sp;      If the Registration Reply is = generated by the Foreign
          &nb= sp;      Agent in order to reject the mobile = node's Registration
          &nb= sp;      Request, and the Registration Request = contains a Home
          &nb= sp;      Address which is not 0.0.0.0, then = the IP Destination
          &nb= sp;      Address is copied from the Home = Address field of the
          &nb= sp;      Registration Request.  = Otherwise, if the Registration
          &nb= sp;      Reply is received from the Home = Agent, and contains a
          &nb= sp;      Home Address which is not 0.0.0.0, = then the IP
Destination
          &nb= sp;      Address is copied from the Home = Address field of the
          &nb= sp;      Registration Reply.  Otherwise, = the IP Destination
          &nb= sp;      Address of the Registration Reply is = set to be
          &nb= sp;      255.255.255.255.


Regards,
-Basavaraj

------_=_NextPart_001_01C19DD2.5E252470-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 10:06: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 KAA27695 for ; Tue, 15 Jan 2002 10:06:52 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03946; Tue, 15 Jan 2002 08:05: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 HAA14437; Tue, 15 Jan 2002 07:05:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FF4R2Q002424 for ; Tue, 15 Jan 2002 07:04:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FF4RJA002423 for mobile-ip-dist; Tue, 15 Jan 2002 07:04: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FF4K2Q002408; Tue, 15 Jan 2002 07:04: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 HAA22449; Tue, 15 Jan 2002 07:04:26 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03073; Tue, 15 Jan 2002 08:04:25 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0FF4N500504; Tue, 15 Jan 2002 16:04:23 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA05230; Tue, 15 Jan 2002 16:04:23 +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 g0FF4MQ52034; Tue, 15 Jan 2002 16:04:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151504.g0FF4MQ52034@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 16:24:03 +0200. Date: Tue, 15 Jan 2002 16:04:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. In theory, yes. But the question is, does it really make that much of a difference as long as at least one way is "unoptimized"? => the same difference than when both ways are unoptimized or optimized. Difference in distance is the same, difference in byte overhead too. This is true for all points with one exception: protocol complexity because triangular routing has roughly the same complexity than bidirectional tunneling. Practice? I don't think there's much difference in bidir tunnel/triangular routing; I doubt e.g. TCP would be able to get much better performance from triangular than from bi-dir (and there are goals like hiding your origins that triangular cannot solve). => I can't see how TCP is involved. I believe your argument is different: if the traffic is very asymmetrical (more on one way than on the other), you prefer to have it on the optimized way... I am afraid the real argument against the triangular routing is this discussion itself because the main triangular routing advantage comes from the (future) fact that HAO is supported by every IPv6 nodes. With enough FUD this shall never become true and the advantage shall vanish... I'd like to get the opinion of IPv6 implementors (if they don't filter out this boring discussion) about HAO (for it, against it, will/won't implement it, will/won't enable it by default, etc). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 10:25: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 KAA28866 for ; Tue, 15 Jan 2002 10: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 IAA16838; Tue, 15 Jan 2002 08:24: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 HAA19075; Tue, 15 Jan 2002 07:24: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 g0FFN12Q002584 for ; Tue, 15 Jan 2002 07:23:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FFN0Dv002583 for mobile-ip-dist; Tue, 15 Jan 2002 07:23: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 g0FFMs2Q002568; Tue, 15 Jan 2002 07:22: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 HAA23836; Tue, 15 Jan 2002 07:23:00 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26813; Tue, 15 Jan 2002 08:22:50 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0FFMkm05102; Tue, 15 Jan 2002 17:22:46 +0200 Date: Tue, 15 Jan 2002 17:22:46 +0200 (EET) From: Pekka Savola To: cc: "Hesham Soliman (ERA)" , Jari Arkko , Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201151504.g0FF4MQ52034@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 15 Jan 2002, Francis Dupont wrote: > In theory, yes. But the question is, does it really make that much of a > difference as long as at least one way is "unoptimized"? > > => the same difference than when both ways are unoptimized or optimized. > Difference in distance is the same, difference in byte overhead too. > This is true for all points with one exception: protocol complexity > because triangular routing has roughly the same complexity than > bidirectional tunneling. What about latency (e.g. interactive session) detected by the user? (might be the worst of the two) Reliability is one argument too. > Practice? I don't think there's much difference in bidir > tunnel/triangular routing; I doubt e.g. TCP would be able to get much > better performance from triangular than from bi-dir (and there are goals > like hiding your origins that triangular cannot solve). > > => I can't see how TCP is involved. I believe your argument is different: > if the traffic is very asymmetrical (more on one way than on the other), > you prefer to have it on the optimized way... I think I'd prefer to have it either _completely optimized_ or _completely unoptimized_, not optimized to one direction and unoptimized to the other. > I am afraid the real argument against the triangular routing is this > discussion itself because the main triangular routing advantage comes > from the (future) fact that HAO is supported by every IPv6 nodes. > With enough FUD this shall never become true and the advantage shall vanish... Yes. But in all reality, a user who requires mobility (e.g. moving fast) would be a fool to rely that all CN's would implement this (or else the connection breaks) during the next 3 years or so.. Triangular routing relies on the existance of this feature everywhere. Bidirectional tunneling always works, and in practise *may* (I don't know) be roughly equal in user-detected latency, TCP thoughput, etc. Does it not seem Bidir is far superior to triangular routing? (As a matter of fact, bidir does not really even require MIPv6 -- I don't think there's any feature missing in current specifications that would be required :-). -- 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 Jan 15 11:21: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 LAA01107 for ; Tue, 15 Jan 2002 11:21:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29267; Tue, 15 Jan 2002 09:19:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05592; Tue, 15 Jan 2002 08:19: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 g0FGIZ2Q002674 for ; Tue, 15 Jan 2002 08:18:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FGIZSn002673 for mobile-ip-dist; Tue, 15 Jan 2002 08:18: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FGIW2Q002666 for ; Tue, 15 Jan 2002 08:18:32 -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 IAA02928 for ; Tue, 15 Jan 2002 08:18:39 -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 JAA28465 for ; Tue, 15 Jan 2002 09:18: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 g0FGIM514733; Tue, 15 Jan 2002 17:18: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 RAA07650; Tue, 15 Jan 2002 17:18: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 g0FGILQ52347; Tue, 15 Jan 2002 17:18:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201151618.g0FGILQ52347@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: mobile-ip@sunroof.eng.sun.com, "Hesham Soliman (ERA)" , Jari Arkko Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Tue, 15 Jan 2002 17:22:46 +0200. Date: Tue, 15 Jan 2002 17:18: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: => I've removed the IPv6 WG list (this is pure mobile IP stuff). What about latency (e.g. interactive session) detected by the user? (might be the worst of the two) => latency is a direct function of distance if routing is not broken. Reliability is one argument too. => this is the only argument against asymmetrical routing (as triangular routing). I think I'd prefer to have it either _completely optimized_ or _completely unoptimized_, not optimized to one direction and unoptimized to the other. => this is a matter of taste. I prefer that the default is not completely unoptimized but we can live with it (this is the current mobile IPv4 situation). > I am afraid the real argument against the triangular routing is this > discussion itself because the main triangular routing advantage comes > from the (future) fact that HAO is supported by every IPv6 nodes. > With enough FUD this shall never become true and the advantage shall > vanish... Yes. But in all reality, a user who requires mobility (e.g. moving fast) would be a fool to rely that all CN's would implement this (or else the connection breaks) during the next 3 years or so.. => BTW we have tried to be fools since some years (:-)... Triangular routing relies on the existance of this feature everywhere. => this is my concern so we have to decide if we try to keep the triangular routing or not. WG chairs??? (I vote to keep it and Pekka vote to kill it) Bidirectional tunneling always works, and in practise *may* (I don't know) be roughly equal in user-detected latency, TCP thoughput, etc. => this is against the definition of a distance in a metric space where the triangle inequality is always satisfied. It will be hard to convince me and perhaps some others. Does it not seem Bidir is far superior to triangular routing? => the only real advantage of Bidir is that it assumes strictly nothing from correspondent nodes (they even are not able to notice their peers are mobile). But you are the first who argues it is more efficient (:-) (for performances)... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 11:37: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 LAA01717 for ; Tue, 15 Jan 2002 11:37:22 -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 IAA03345; Tue, 15 Jan 2002 08:36:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08472; Tue, 15 Jan 2002 08:36: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 g0FGZL2Q002835 for ; Tue, 15 Jan 2002 08:35:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FGZLj1002834 for mobile-ip-dist; Tue, 15 Jan 2002 08:35: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 g0FGZH2Q002827 for ; Tue, 15 Jan 2002 08:35:17 -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 IAA12287 for ; Tue, 15 Jan 2002 08:35:24 -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 JAA22292 for ; Tue, 15 Jan 2002 09:35:23 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0FGZD206669; Tue, 15 Jan 2002 18:35:13 +0200 Date: Tue, 15 Jan 2002 18:35:12 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: , "Hesham Soliman (ERA)" , Jari Arkko Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201151618.g0FGILQ52347@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 15 Jan 2002, Francis Dupont wrote: > What about latency (e.g. interactive session) detected by the user? (might > be the worst of the two) > > => latency is a direct function of distance if routing is not broken. _detected by the user_. Assuming two options: 1) 50 ms there, 150 ms back 2) 100 ms there, 100 ms back Round-trip time is the same, but I bet to the user this does not feel the same. Same with above. > Yes. But in all reality, a user who requires mobility (e.g. moving fast) > would be a fool to rely that all CN's would implement this (or else the > connection breaks) during the next 3 years or so.. > > => BTW we have tried to be fools since some years (:-)... I'm assuming you've succeeded brilliantly. > Bidirectional tunneling always works, and in practise *may* (I don't know) > be roughly equal in user-detected latency, TCP thoughput, etc. > > => this is against the definition of a distance in a metric space where > the triangle inequality is always satisfied. It will be hard to convince > me and perhaps some others. Hesham and I wondered: "is the difference all that significant". It's probable that triangular is at least slightly better in some aspects, but is that justification enough? > Does it not seem Bidir is far superior to triangular routing? > > => the only real advantage of Bidir is that it assumes strictly nothing > from correspondent nodes (they even are not able to notice their peers > are mobile). But you are the first who argues it is more efficient (:-) > (for performances)... Right! Let me quote you: --8<-- => no, a two phase approach won't work because we'll stay at the first phase. And you put the burden on the wrong people: this is an ingress filtering problem, not a MIPv6 one, so the solution should be in an ingress filtering improvement, not in a new restriction for MIPv6. --8<-- Consider how this might apply here :-) -- 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 Jan 15 11:37: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 LAA01761 for ; Tue, 15 Jan 2002 11:37:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12411; Tue, 15 Jan 2002 09:36:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08460; Tue, 15 Jan 2002 08:36: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 g0FGZ72Q002825 for ; Tue, 15 Jan 2002 08:35:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FGZ7a9002824 for mobile-ip-dist; Tue, 15 Jan 2002 08:35: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 g0FGZ32Q002817 for ; Tue, 15 Jan 2002 08:35:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07395 for ; Tue, 15 Jan 2002 08:35:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10366 for ; Tue, 15 Jan 2002 09:35:09 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA23216; Tue, 15 Jan 2002 08:35:07 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0FGZ6H17456; Tue, 15 Jan 2002 08:35:06 -0800 X-mProtect: Tue, 15 Jan 2002 08:35:06 -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 smtpdIU4B1W; Tue, 15 Jan 2002 08:35:04 PST Message-ID: <3C445A39.81EF4F15@iprg.nokia.com> Date: Tue, 15 Jan 2002 08:35:05 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ahmad Muhanna CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Changes to RFC2002bis (Vers 8) References: <6B49EDFE974BD51197D70002A56079D82AF65F@zrc2c013.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ahmad, Hello Ahmad, > Ahmad Muhanna wrote: > > Hello Basavaraj; > > Could you please brief us with the rationale behind the changes of the 1st > paragraph in section 2.3? > As far as I know, the Mobile Node as per RFC2002-bis and RFC1256 can send > Agent Solicitation message to either > 255.255.255.255 or 224.0.0.2. This is true. The rationale for putting the additional tex into RFC 2002bis was that I was asked to do so during Last Call for RFC 2002bis. Since it does not do any harm to the specification to have it, and since people thought it made the specification clearer, I was happy to put it in. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 12:06: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 MAA05365 for ; Tue, 15 Jan 2002 12:06: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 KAA05063; Tue, 15 Jan 2002 10: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 JAA22181; Tue, 15 Jan 2002 09:05: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 g0FH4E2Q003047 for ; Tue, 15 Jan 2002 09:04:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FH4DQA003046 for mobile-ip-dist; Tue, 15 Jan 2002 09:04: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 g0FH4A2Q003039 for ; Tue, 15 Jan 2002 09:04:11 -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 JAA19875 for ; Tue, 15 Jan 2002 09:04:17 -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 KAA26251 for ; Tue, 15 Jan 2002 10:04:15 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0FH3xf02713; Tue, 15 Jan 2002 11:04:03 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 11:03:59 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF667@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Changes to RFC2002bis (Vers 8) Date: Tue, 15 Jan 2002 11:03:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DE6.9B32C840" Sender: owner-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_01C19DE6.9B32C840 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie; Thanks for the input. Regards; Ahmad Muhanna -----Original Message----- From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] Sent: Tuesday, January 15, 2002 10:35 AM To: Muhanna, Ahmad [RICH1:2Q20:EXCH] Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Changes to RFC2002bis (Vers 8) Hello Ahmad, Hello Ahmad, > Ahmad Muhanna wrote: > > Hello Basavaraj; > > Could you please brief us with the rationale behind the changes of the 1st > paragraph in section 2.3? > As far as I know, the Mobile Node as per RFC2002-bis and RFC1256 can send > Agent Solicitation message to either > 255.255.255.255 or 224.0.0.2. This is true. The rationale for putting the additional tex into RFC 2002bis was that I was asked to do so during Last Call for RFC 2002bis. Since it does not do any harm to the specification to have it, and since people thought it made the specification clearer, I was happy to put it in. Regards, Charlie P. ------_=_NextPart_001_01C19DE6.9B32C840 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Changes to RFC2002bis (Vers 8)

Hello Charlie;

Thanks for the input.

Regards;
Ahmad Muhanna



-----Original Message-----
From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
Sent: Tuesday, January 15, 2002 10:35 AM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]
Cc: mobile-ip@sunroof.eng.sun.com
Subject: Re: [mobile-ip] Changes to RFC2002bis (Vers 8)



Hello Ahmad,

Hello Ahmad,

> Ahmad Muhanna wrote:
>
> Hello Basavaraj;
>
> Could you please brief us with the rationale behind the changes of the 1st
> paragraph in section 2.3?
> As far as I know, the Mobile Node as per RFC2002-bis and RFC1256 can send
> Agent Solicitation message to either
> 255.255.255.255 or 224.0.0.2.

This is true.  The rationale for putting the additional tex into RFC 2002bis
was that I was asked to do so during Last Call for RFC 2002bis.  Since it
does not do any harm to the specification to have it, and since people
thought it made the specification clearer, I was happy to put it in.

Regards,
Charlie P.

------_=_NextPart_001_01C19DE6.9B32C840-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 15 15:00: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 PAA11522 for ; Tue, 15 Jan 2002 15:00: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 MAA15893; Tue, 15 Jan 2002 12:59:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25010; Tue, 15 Jan 2002 11:59: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 g0FJvu2Q003356 for ; Tue, 15 Jan 2002 11:57:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0FJvuKI003355 for mobile-ip-dist; Tue, 15 Jan 2002 11:57: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 g0FJvq2Q003348 for ; Tue, 15 Jan 2002 11:57:53 -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 LAA08274 for ; Tue, 15 Jan 2002 11:57:59 -0800 (PST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28753 for ; Tue, 15 Jan 2002 12:57:59 -0700 (MST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id TAA15193 for ; Tue, 15 Jan 2002 19:57:58 GMT Received: from orsmsx26.jf.intel.com ([192.168.65.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011512000215573 for ; Tue, 15 Jan 2002 12:00:02 -0800 Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jan 2002 11:57:57 -0800 Message-ID: <0DCC27458EB5D51181840002A507069EE30DAF@orsmsx117.jf.intel.com> From: "Iyer, Prakash" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Tue, 15 Jan 2002 11:57:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Henrik, I think the folks who responded were responding to the question: is this a problem to work on and solve and not specifically if they endorse the draft. That is true with respect to the NAT draft as well by the way. So in a sense the question is: would you like to see this work be taken up by the WG. Once we decide on that we can discuss proposals from various folks including yours and discuss merits etc. based on requirements, deployment scenarios etc. We will have more to say on this subject as well as you can imagine :) Regards. -Prakash -----Original Message----- From: Henrik Levkowetz [mailto:henrik@ipunplugged.com] Sent: Tuesday, January 15, 2002 6:43 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns I believe that VPN interaction is of interest to mobile IP, but also that the problem is not as simple and well understood yet as the NAT traversal, and would benefit from more work and discussions. In particular, I'm not convinced that the solution in the adrangi draft is the best we can come up with. There's a short discussion of different scenarios in http://www.levkowetz.com/pub/id/nat-vpn-scenarios.html, but I believe there is more to be said and thought on the subject.. :-) Best regards, Henrik > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Phil Roberts > Sent: Monday, January 14, 2002 4:15 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > NATs/VP Ns > > > Sure. > > When we asked during London there was a large constituency in the room that > agreed about the NAT traversal problem. Not so with the VPN gateway > traversal > and there was some pushback in the private discussion about whether VPN > gateway traversal was needed at all. If you can get enough folks to post on > the MIP list that they're interested in VPN gateway traversal we can > consider > whether to pursue a draft on it. > > Phil > > > > -----Original Message----- > > From: Iyer, Prakash [mailto:prakash.iyer@intel.com] > > Sent: Monday, January 14, 2002 10:13 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > NATs/VP Ns > > > > > > Was the consensus based on the number of companies. If so, as far as I > > remember there were only > > 2 or 3 companies driving NAT requirements and at least as > > many (if not more) > > interested in solving > > the VPN problem. I remember both George and James Kempf > > raising this issue > > for discussion and a > > couple of other vendors noting their interest on the > > [mobileip-nat-vpn] > > mailing list. As I had > > mentioned earlier there were requests on the IPSRA mailing > > list as well. > > > > Maybe the chairs can clarify the basis for this conclusion > > for the benefit > > of the working group. > > Thanks. > > > > -Prakash > > > > -----Original Message----- > > From: Phil Roberts [mailto:PRoberts@megisto.com] > > Sent: Monday, January 14, 2002 6:42 AM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with > > NATs/VP Ns > > > > > > Based on the feedback we'll be making > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > a working group item and waiting on the interoperation with > > VPN gateways > > until there is > > a larger constituency of interest in the WG. > > > > > > > -----Original Message----- > > > From: Patil Basavaraj (NET/Dallas) > [mailto:Basavaraj.Patil@nokia.com] > > Sent: Friday, January 04, 2002 6:59 PM > > To: 'Mobile IP' > > Subject: [mobile-ip] Consensus call - MIPv4 interopration > > with NATs/VPNs > > > > > > In London a design team was formed to investigate the problem of > > Mobile IPv4 interoperation with NATs and VPNs. At the time there > > was a clear constituency in the working group that having a solution > > to NAT traversal was important. It was less clear to the > > chairs that there was a clear interest in the working group for a > > specification of the operation of Mobile IPv4 across VPN gateways. To > > that end we propose that the following draft: > > draft-levkowetz-vaarala-mobileip-nat-traversal-00.txt > > (the output of the design team) be made into a working group item for > > progression on the Standards Track. Please let us know in the next > > few days if you object to this. > > > > We would also like to hear feedback from the working group on > > whether there is a perceived need for a solution to Mobile IPv4 > > interoperation with VPN gateways. > > > > WG Chairs > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 05:40: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 FAA11348 for ; Thu, 17 Jan 2002 05:40: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 CAA19182; Thu, 17 Jan 2002 02:37:07 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24203; Thu, 17 Jan 2002 02:36: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 g0HAZf2Q005397 for ; Thu, 17 Jan 2002 02:35:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HAZfFT005396 for mobile-ip-dist; Thu, 17 Jan 2002 02:35:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAZX2Q005381; Thu, 17 Jan 2002 02:35:33 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0HAZXx15355; Thu, 17 Jan 2002 11:35:33 +0100 (MET) Date: Thu, 17 Jan 2002 11:32:33 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201151046.g0FAk1Q50869@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: > Also, waiting for AAA solutions to be available (specified, implemeted, > and deployed) before MIPv6 can be used seems to be counter to our desire > to finish up MIPv6 soon. > > => I never proposed to wait for AAA solutions (as I ask only for network > access control, not everywhere but enough to make HAO spoofing unattractive). Are you proposing to wait until network access control is available? (specified, implemented, and deployed) If not, what do you propose to do in the interim until network access control for HAO is available? Seems like this requires a two-phase approach: phase 1 before it is available and phase 2 when/if it become available. What am I missing? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 05:45: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 FAA11434 for ; Thu, 17 Jan 2002 05:45:18 -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 DAA06744; Thu, 17 Jan 2002 03:44: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 CAA25403; Thu, 17 Jan 2002 02:44: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 g0HAhv2Q005471 for ; Thu, 17 Jan 2002 02:43:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HAhvCd005470 for mobile-ip-dist; Thu, 17 Jan 2002 02:43:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAhq2Q005463; Thu, 17 Jan 2002 02:43:53 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0HAhtx16041; Thu, 17 Jan 2002 11:43:55 +0100 (MET) Date: Thu, 17 Jan 2002 11:40:53 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filter discussion To: Francis.Dupont@enst-bretagne.fr Cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201151325.g0FDPRQ51519@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: >Hesham wrote: > I haven't heard anyone answering my question as to why > reverse tunnelling by the MN thru the HA is so much > worse than triangular routing, > > Francis wrote in response: > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > d(optimization) = 2 * d(MN,CN) > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > so d(optimization) <= d(triangular) <= d(bidir tunnel) > and even stronger 2 * d(triangular) = d(optimization) + d(bidir tunnel) > i.e. in my poor English the cost/performance of triangular routing > is at the middle of bidirectional tunneling and routing optimization. Yes, but does that make any significant difference for real traffic and applications given than the traffic from CN to MN goes through the HA in the triangular case? For instance assume that the CN and MN are next to each other (delay 1 ms) and the HA is 100 ms away from them (one way delay). If you route optimize TCP will see a RTT of 2 ms. If you do triangular the rtt will be 201 ms. If you do bidirectional tunneling the rtt will be 400 ms. You can look at these numbers differently depending what you want to prove. "400/201 = 2" would make your argument. But my argument is that "201/2 = 100". Thus if you care about rtt when the CN/MN are close compared to the MN/HA delay you should route optimize. The only case I can think of where tringular makes a significant performance difference is for unidirectional and latency sensitive traffic from MN to CN. I have yet to see an application which such concerns - if latency is an issue it is because you'd like the higher level entities (transport protocols or humans e.g. on a voice/video conversation) to observe short roundtrip latency. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 05:50:55 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11490 for ; Thu, 17 Jan 2002 05:50: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 CAA23872; Thu, 17 Jan 2002 02:50:25 -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 CAA26659; Thu, 17 Jan 2002 02:50: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 g0HAnI2Q005550 for ; Thu, 17 Jan 2002 02:49:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HAnI5u005549 for mobile-ip-dist; Thu, 17 Jan 2002 02:49:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HAmx2Q005531 for ; Thu, 17 Jan 2002 02:48: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 CAA27947 for ; Thu, 17 Jan 2002 02:49:06 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29989 for ; Thu, 17 Jan 2002 02:49:04 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HAn4K07748 for ; Thu, 17 Jan 2002 11:49:04 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 11:48:47 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 11:49:02 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C214@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , Francis.Dupont@enst-bretagne.fr Cc: "Hesham Soliman (ERA)" , Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: How to move forward in the HAO & ingress filt er discussion Date: Thu, 17 Jan 2002 11:48: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: > >Hesham wrote: > > I haven't heard anyone answering my question as to why > > reverse tunnelling by the MN thru the HA is so much > > worse than triangular routing, > > > > Francis wrote in response: > > => d(bidir tunnel) = 2 * d(MN,HA) + 2 * d(HA,CN) > > d(triangular) = d(MN,HA) + d(HA,CN) + d(MN,CN) > > d(optimization) = 2 * d(MN,CN) > > and we always have d(MN,CN) <= d(MN,HA) + d(HA,CN) > > so d(optimization) <= d(triangular) <= d(bidir tunnel) > > and even stronger 2 * d(triangular) = d(optimization) + > d(bidir tunnel) > > i.e. in my poor English the cost/performance of triangular routing > > is at the middle of bidirectional tunneling and routing > optimization. > > Yes, but does that make any significant difference for real > traffic and > applications given than the traffic from CN to MN goes > through the HA > in the triangular case? > > For instance assume that the CN and MN are next to each > other (delay 1 ms) > and the HA is 100 ms away from them (one way delay). > If you route optimize TCP will see a RTT of 2 ms. > If you do triangular the rtt will be 201 ms. > If you do bidirectional tunneling the rtt will be 400 ms. > You can look at these numbers differently depending what you want to > prove. "400/201 = 2" would make your argument. > But my argument is that "201/2 = 100". > Thus if you care about rtt when the CN/MN are close > compared to the MN/HA > delay you should route optimize. => Exactly. So I don't see the improvement with triangular routing over bidirectional tunnelling... for real time or TCP connections. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 08:37:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14849 for ; Thu, 17 Jan 2002 08:37:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21386; Thu, 17 Jan 2002 06:37:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23752; Thu, 17 Jan 2002 05:36: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 g0HDZt2Q005896 for ; Thu, 17 Jan 2002 05:35:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HDZt4Q005895 for mobile-ip-dist; Thu, 17 Jan 2002 05:35: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 g0HDZm2Q005880; Thu, 17 Jan 2002 05:35:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09235; Thu, 17 Jan 2002 05:35:55 -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 GAA20837; Thu, 17 Jan 2002 06:35:53 -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 g0HDZn521257; Thu, 17 Jan 2002 14:35: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 OAA23636; Thu, 17 Jan 2002 14:35: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 g0HDZmQ60713; Thu, 17 Jan 2002 14:35:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 11:32:33 +0100. Date: Thu, 17 Jan 2002 14:35:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Also, waiting for AAA solutions to be available (specified, implemeted, > and deployed) before MIPv6 can be used seems to be counter to our desire > to finish up MIPv6 soon. > > => I never proposed to wait for AAA solutions (as I ask only for network > access control, not everywhere but enough to make HAO spoofing unattractive). Are you proposing to wait until network access control is available? (specified, implemented, and deployed) => we don't need to wait because mobile IPv6 is not yet fully specified. IMHO the only thing we need is to be ready and the first step should be to get (traditional) ingress filtering and firewalls with IPv6 support (or do you suggest to stop IPv6 until they are implemented and deployed?) If not, what do you propose to do in the interim until network access control for HAO is available? => decide if we keep or kill the triangular routing. In parallel (because even if the triangular routing is killed there are still similar mechanisms based on tunnels with the same security issue) give this idea to network access control people (both RADIUS/DIAMETER and firewall) in order to know what concrete proposal we can/should do (for instance a new RADIUS attribute for IPv6 inner source address declaration). IMHO this second part is mainly not technical (i.e. out of the scope of IETF). Seems like this requires a two-phase approach: phase 1 before it is available and phase 2 when/if it become available. => you are acking what will happen after some kilometers in a deep fog: today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress filtering, IPv6 firewalls, ... What am I missing? => mobile IPv6 is not yet in last call, in fact we don't know if it will be this year. So we only need a paper solution against the future and potential minor security threat of HAO with ingress filtering. But I agree we have to know where we are going or we could lose more than our time in this kind of discussions (i.e. implementers don't like to follow random moving specs). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 08:50:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15147 for ; Thu, 17 Jan 2002 08:50: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 FAA13400; Thu, 17 Jan 2002 05:50:08 -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 FAA04724; Thu, 17 Jan 2002 05:49: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 g0HDmW2Q006073 for ; Thu, 17 Jan 2002 05:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HDmWOO006072 for mobile-ip-dist; Thu, 17 Jan 2002 05:48: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 g0HDmT2Q006065 for ; Thu, 17 Jan 2002 05:48:29 -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 FAA04604 for ; Thu, 17 Jan 2002 05:48:36 -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 FAA25451 for ; Thu, 17 Jan 2002 05:48: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 g0HDmG523417; Thu, 17 Jan 2002 14:48: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 OAA24003; Thu, 17 Jan 2002 14:48: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 g0HDmGQ60781; Thu, 17 Jan 2002 14:48:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201171348.g0HDmGQ60781@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: "'Erik Nordmark'" , Jari Arkko , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: How to move forward in the HAO & ingress filt er discussion In-reply-to: Your message of Thu, 17 Jan 2002 11:48:38 +0100. <4DA6EA82906FD511BE2F00508BCF053801C4C214@Esealnt861.al.sw.ericsson.se> Date: Thu, 17 Jan 2002 14:48: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: => Exactly. So I don't see the improvement with triangular routing over bidirectional tunnelling... for real time or TCP connections. => (keeping this discussion in the mobile ip list) This argument is a bit dangerous because it assumes the main usage of mobile nodes will be access from mobile nodes to fixed big servers. I don't dispute this argument (I believe this is what shall happen) but it can be used too in order to explain why the routing optimization will be unimplemented or disabled on most of interesting correspondent nodes, i.e. the routing optimization will never be widely deployed... Regards Francis.Dupont@enst-bretagne.fr PS: of course any counter argument should be counter arguments applying to both. Still trying to be very convincing (:-) ? From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 09:13: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 JAA15962 for ; Thu, 17 Jan 2002 09:13:50 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21561; Thu, 17 Jan 2002 06:13:12 -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 GAA08911; Thu, 17 Jan 2002 06: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 g0HEC92Q006199 for ; Thu, 17 Jan 2002 06:12:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEC8gm006198 for mobile-ip-dist; Thu, 17 Jan 2002 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEC52Q006191 for ; Thu, 17 Jan 2002 06:12:05 -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 GAA00335 for ; Thu, 17 Jan 2002 06:12:12 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10963 for ; Thu, 17 Jan 2002 06:12:11 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HECAJ24009 for ; Thu, 17 Jan 2002 15:12:10 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jan 17 15:12:03 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 15:03:02 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C215@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , "'Jari Arkko'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: How to move forward in the HAO & ingress filt er discussion Date: Thu, 17 Jan 2002 15:11:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In your previous mail you wrote: > > => Exactly. So I don't see the improvement with triangular > routing over bidirectional tunnelling... for real time > or TCP connections. > > => (keeping this discussion in the mobile ip list) > This argument is a bit dangerous because it assumes the main usage > of mobile nodes will be access from mobile nodes to fixed big > servers. => Not at all. Even if you have a peer-to-peer connection, what is that advantage of improving the MN - CN leg while keeping triangular routing on the other ? > I don't dispute this argument (I believe this is what shall happen) => I think there will be room for peer to peer applications. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 09:20: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 JAA16180 for ; Thu, 17 Jan 2002 09:20:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23791; Thu, 17 Jan 2002 06:19: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 GAA10279; Thu, 17 Jan 2002 06:18: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 g0HEHl2Q006322 for ; Thu, 17 Jan 2002 06:17:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEHlJF006321 for mobile-ip-dist; Thu, 17 Jan 2002 06:17:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEHg2Q006311 for ; Thu, 17 Jan 2002 06:17: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 GAA13988 for ; Thu, 17 Jan 2002 06:17:49 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19460 for ; Thu, 17 Jan 2002 07:17:48 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HEHlK03047 for ; Thu, 17 Jan 2002 15:17:47 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 17 15:17:43 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 15:08:42 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C216@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Cc: jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] How to move forward in the HAO & ingress filter d iscussion Date: Thu, 17 Jan 2002 15:17:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-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, waiting for AAA solutions to be available > (specified, implemeted, > > and deployed) before MIPv6 can be used seems to be > counter to our desire > > to finish up MIPv6 soon. > > > > => I never proposed to wait for AAA solutions (as I > ask only for network > > access control, not everywhere but enough to make HAO > spoofing unattractive). > > Are you proposing to wait until network access control > is available? > (specified, implemented, and deployed) > > => we don't need to wait because mobile IPv6 is not yet > fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls > with IPv6 support > (or do you suggest to stop IPv6 until they are implemented > and deployed?) => Ah, now I now what you meant before by not needing a solution. But this is really scarey, are you saying we wait until last call ( or worse, proposed standard) and then bring this up again ? Some people don't like that Francis :-) How can we be sure that the 'paper solution' you refer to will be deployed by the time MIPv6 is, if ever ... Hesham > > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In > parallel (because > even if the triangular routing is killed there are still > similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for > instance a > new RADIUS attribute for IPv6 inner source address > declaration). IMHO > this second part is mainly not technical (i.e. out of the > scope of IETF). > > Seems like this requires a two-phase approach: phase 1 > before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in > a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, > IPv6 ingress > filtering, IPv6 firewalls, ... > > What am I missing? > > => mobile IPv6 is not yet in last call, in fact we don't > know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. > But I agree we have to know where we are going or we could lose more > than our time in this kind of discussions (i.e. > implementers don't like > to follow random moving specs). > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 09:35: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 JAA16684 for ; Thu, 17 Jan 2002 09:35:12 -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 GAA00240; Thu, 17 Jan 2002 06:34: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 GAA14001; Thu, 17 Jan 2002 06:34: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 g0HEWn2Q006523 for ; Thu, 17 Jan 2002 06:32:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEWnnR006522 for mobile-ip-dist; Thu, 17 Jan 2002 06:32: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 g0HEWg2Q006507; Thu, 17 Jan 2002 06:32:42 -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 GAA01709; Thu, 17 Jan 2002 06:32:49 -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 HAA12483; Thu, 17 Jan 2002 07:32:48 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0HEWkK28133; Thu, 17 Jan 2002 16:32:46 +0200 Date: Thu, 17 Jan 2002 16:32:46 +0200 (EET) From: Pekka Savola To: cc: Erik Nordmark , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Thu, 17 Jan 2002, Francis Dupont wrote: > => we don't need to wait because mobile IPv6 is not yet fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls with IPv6 support > (or do you suggest to stop IPv6 until they are implemented and deployed?) Ingress filtering and firewalls exist already. > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You know full well that e.g. ip6fw, ipf, iptables (all free) etc. support IPv6 ingress filtering and firewalling rather nicely; they've had the support for some time now. They're still a bit raw, as is understandable, but usable. So why do you spread FUD? -- 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 Thu Jan 17 09:43: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 JAA17024 for ; Thu, 17 Jan 2002 09:43:21 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03508; Thu, 17 Jan 2002 06:42:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15800; Thu, 17 Jan 2002 06:42: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 g0HEem2Q006630 for ; Thu, 17 Jan 2002 06:40:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HEemYi006629 for mobile-ip-dist; Thu, 17 Jan 2002 06:40:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HEea2Q006614; Thu, 17 Jan 2002 06:40:37 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id g0HEeQx04513; Thu, 17 Jan 2002 15:40:27 +0100 (MET) Date: Thu, 17 Jan 2002 15:37:20 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201171335.g0HDZmQ60713@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: > => we don't need to wait because mobile IPv6 is not yet fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls with IPv6 support > (or do you suggest to stop IPv6 until they are implemented and deployed?) No, but the specification of MIPv6 should wait until the ingress filtering part is specified. If we (the IETF) really care about security we need to make sure that we don't create holes in the set of standards track RFCs we issue. That is all the IETF need to worry about. (Others need to worry about complete security of products and a third set of folks need to worry about the security of their operational network using those products.) For the IETF I think this means that we should not issue a proposed standard (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be made aware of HAO). If we want to go this path I think we need a community supported ingress filtering RFC (BCP or standards track) that handles HAO no later than when MIPv6 becomes Proposed Standard. I don't think we should use the fact that 1) there are IPv6 products with incomplete security and/or 2) existing IPv6 operational networks have incomplete security as arguments that we can have an IPv6 story where the standards have security holes. Even if we say "we'll fill that hole really quickly by later producing an HAO aware ingress filtering RFC" or something similar. > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In parallel (because > even if the triangular routing is killed there are still similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for instance a > new RADIUS attribute for IPv6 inner source address declaration). IMHO > this second part is mainly not technical (i.e. out of the scope of IETF). It seems like the IETF pieces (RFCs) that need to be completed to have complete (i.e. not security holes in the combination of specs) specification for network access control is sizeable: some fireall spec (perhaps informational), some radius and diameter extensions. This sounds like more delay for MIPv6 to me. The two-phase approach removes this delay. > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You're confusing specifications, products, and deployed practise. People can build ingress filtering and firewalls for IPv6 today without waiting for a specification from the IETF. That wouldn't be true if we issue a MIPv6 specification which, in order to avoid ingress filtering, depends on some yet to be written RFCs that specify network access control for HAO. > => mobile IPv6 is not yet in last call, in fact we don't know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. But we don't want to delay MIPv6 any more than we need to. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 11:51: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 LAA23981 for ; Thu, 17 Jan 2002 11:51:15 -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 IAA04726; Thu, 17 Jan 2002 08:50:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08847; Thu, 17 Jan 2002 08:50: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 g0HGnQ2Q006943 for ; Thu, 17 Jan 2002 08:49:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HGnQNb006942 for mobile-ip-dist; Thu, 17 Jan 2002 08:49:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HGnM2Q006935; Thu, 17 Jan 2002 08:49:22 -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 IAA17537; Thu, 17 Jan 2002 08:49:29 -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 IAA27337; Thu, 17 Jan 2002 08:49:27 -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 IAA23660; Thu, 17 Jan 2002 08:49:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HGnPa17204; Thu, 17 Jan 2002 08:49:25 -0800 X-mProtect: Thu, 17 Jan 2002 08:49:25 -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 smtpdhdSlH2; Thu, 17 Jan 2002 08:49:23 PST Message-ID: <3C470094.29B50022@iprg.nokia.com> Date: Thu, 17 Jan 2002 08:49:24 -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: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I'm pretty far behind on reading these voluminous e-mails, but I would at least like to express again my belief that we could go forward with the HAO as it is. If the downside is that then there is vulnerability to (single!) packets being reflected back to an unsuspecting home address, then: - This is not a completely horrible problem - It is amenable to solutions that can be deployed later, as IPv6 itself becomes more widely deployed - Solutions involving use of security associations between mobile and correspondent will be developed more rapidly if there is motivation for use with Proposed Standard Mobile IPv6 - We can be done almost immediately, and begin to productively tackle the issues more effectively with experience. I think there is a very real possibility that we are getting stalled in worrying over a problem that is not going to happen. A couple of other points: Francis Dupont wrote: > => we don't need to wait because mobile IPv6 is not yet fully specified. That is purely a matter of opinion. People have built it and tested it and it works. I think it would be far more proper to say that Mobile IPv6 is in fact fully specified, but we have identified more things to do. Those things should be in new specifications. I would compare your statement to be the same as saying "IP was not fully specified until we had CIDR". That is manifestly absurd, unless you are willing to also contend that IP and IPv6 both are not even yet fully specified. In my opinion, we are not moving forward because we are being required to boil the ocean before even being allowed to take a drink. Erik Nordmark wrote: > If not, what do you propose to do in the interim until network > access control for HAO is available? I'd say let's try it. The likely access controls are not going to affect the handling at the correspondent node anyway. The downside isn't very bad anyway. If I were a malicious hacker, why would I mess with that when there are so many other low-hanging fruits to spear? > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... Phase one is basically requiring reverse tunneling for virtually all mobility, killing route optimization, and probably along with it any hope of QoS for many years. It means that nodes will typically not receive packets containing the Home Address option, and thus the feature will rust. > => mobile IPv6 is not yet in last call, in fact we don't know if it will be > this year. Well, technically speaking, it was already in Last Call last year (and the year before). But I guess that is really a moot point. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 14:04: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 OAA00533 for ; Thu, 17 Jan 2002 14:04:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20530; Thu, 17 Jan 2002 12:03: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 LAA16423; Thu, 17 Jan 2002 11:03: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 g0HJ2C2Q007242 for ; Thu, 17 Jan 2002 11:02:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HJ2Cdw007241 for mobile-ip-dist; Thu, 17 Jan 2002 11:02: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 g0HJ252Q007226; Thu, 17 Jan 2002 11:02:05 -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 LAA00502; Thu, 17 Jan 2002 11:02:11 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07311; Thu, 17 Jan 2002 11:02:11 -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 g0HJ2AD01465; Thu, 17 Jan 2002 11:02:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAR81251; Thu, 17 Jan 2002 11:01:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17034; Thu, 17 Jan 2002 11:01:53 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15431.8097.648763.243323@thomasm-u1.cisco.com> Date: Thu, 17 Jan 2002 11:01:53 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <3C470094.29B50022@iprg.nokia.com> References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles E. Perkins writes: > Hello folks, > > I'm pretty far behind on reading these voluminous e-mails, but > I would at least like to express again my belief that we could > go forward with the HAO as it is. If the downside is that then > there is vulnerability to (single!) packets being reflected back > to an unsuspecting home address, then: [] That is not the only downside. The primary downsides have been discussed here ad nauseum. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 14:08: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 OAA00739 for ; Thu, 17 Jan 2002 14:08:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24251; Thu, 17 Jan 2002 12:08:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17868; Thu, 17 Jan 2002 11: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 g0HJ792Q007379 for ; Thu, 17 Jan 2002 11:07:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HJ79XO007378 for mobile-ip-dist; Thu, 17 Jan 2002 11:07: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 g0HJ752Q007371; Thu, 17 Jan 2002 11:07:06 -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 LAA02364; Thu, 17 Jan 2002 11:07:11 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00517; Thu, 17 Jan 2002 12:07:10 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0HJ74906892; Thu, 17 Jan 2002 11:07:08 -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 AAR81450; Thu, 17 Jan 2002 11:06:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA17037; Thu, 17 Jan 2002 11:06:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15431.8402.347072.961249@thomasm-u1.cisco.com> Date: Thu, 17 Jan 2002 11:06:58 -0800 (PST) To: Erik Nordmark Cc: Francis Dupont , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > For the IETF I think this means that we should not issue a proposed standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). If we want to go this path I think we need a community > supported ingress filtering RFC (BCP or standards track) that handles HAO no > later than when MIPv6 becomes Proposed Standard. I agree 100% with Erik here, and add this: security needs to be thought of in terms of layers. Ingress filtering is a useful, but incomplete layer. Ultimately hosts need a means to defend themselves too since we can't assume that anything will have complete coverage. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 14:17: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 OAA01006 for ; Thu, 17 Jan 2002 14:17:17 -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 MAA01171; Thu, 17 Jan 2002 12:16:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20258; Thu, 17 Jan 2002 11:16: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 g0HJF62Q007576 for ; Thu, 17 Jan 2002 11:15:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HJF6Lu007575 for mobile-ip-dist; Thu, 17 Jan 2002 11:15: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 g0HJF32Q007568 for ; Thu, 17 Jan 2002 11:15:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19734 for ; Thu, 17 Jan 2002 11:15:08 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17538 for ; Thu, 17 Jan 2002 12:15:07 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Jan 2002 14:09:38 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIP v6 next steps Date: Thu, 17 Jan 2002 14:09:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, we've formed a small design team to close the open issues based on WG consensus for MIPv6. It consists of Jari Arkko, Gabriel Montenegro, and Erik Nordmark. The chairs and area advisor are monitoring what's going on there. The following open issues need to be closed based on WG consensus: 1) what strength of protection to use for BUs and the protocol mechanisms to make that happen, 2) how to protect against certain forms of attacks using routing headers, 3) how to protect against certain forms of attacks using the home address option, and 4)what to do about piggybacking. In the next couple of weeks threads will be started listing the possible options, there will be time for discussion, and the chairs will make working group consensus calls. The protection of BU description will probably be a new Internet Draft which will later be incorporated into the MIPv6 specification. We expect the description of the BU draft to be out by Feb 8, and to incorporate it and discussion items based on it in time to have a WG last call complete by the Friday of the Minneapolis meeting. Phil and Raj From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 17 14:38:39 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03047 for ; Thu, 17 Jan 2002 14:38: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 LAA27392; Thu, 17 Jan 2002 11: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 LAA05433; Thu, 17 Jan 2002 11:37: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 g0HJaP2Q007671 for ; Thu, 17 Jan 2002 11:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0HJaPlH007670 for mobile-ip-dist; Thu, 17 Jan 2002 11:36:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0HJaM2Q007663 for ; Thu, 17 Jan 2002 11:36:22 -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 LAA14959 for ; Thu, 17 Jan 2002 11:36:28 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21334 for ; Thu, 17 Jan 2002 11:36:28 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06608 for ; Thu, 17 Jan 2002 11:36:27 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0HJaRA02595 for ; Thu, 17 Jan 2002 11:36:27 -0800 X-mProtect: Thu, 17 Jan 2002 11:36:27 -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 smtpd9kyxVb; Thu, 17 Jan 2002 11:36:26 PST Message-ID: <3C4727BA.3787F298@iprg.nokia.com> Date: Thu, 17 Jan 2002 11:36:26 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIP v6 next steps References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil and Raj, I want Francis Dupont included in the design team. He has probably more experience with Mobile IPv6 than most people in this WG. the design team you have selected does not make sense IMHO. you dont have anybody who has implemented MIPv6 on the design team. please correct me if I am wrong. Phil Roberts wrote: > > Hi, > > we've formed a small design team to close the open issues based on WG > consensus for MIPv6. > It consists of Jari Arkko, Gabriel Montenegro, and Erik Nordmark. The And would the mail archives and minutes from teleconferences made public? Vijay > chairs and area advisor > are monitoring what's going on there. The following open issues need to be > closed based on WG > consensus: > 1) what strength of protection to use for BUs and the protocol > mechanisms to make that happen, > 2) how to protect against certain forms of attacks using routing > headers, > 3) how to protect against certain forms of attacks using the home > address option, and > 4)what to do about piggybacking. > > In the next couple of weeks threads will be started listing the possible > options, there will be time for discussion, and the chairs will make working > group consensus calls. The protection of BU description will probably be a > new Internet Draft which will later be incorporated into the MIPv6 > specification. We expect the description of the BU draft to be out by Feb > 8, and to incorporate it and discussion items based on it in > time to have a WG last call complete by the Friday of the Minneapolis > meeting. > > Phil and Raj From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 02:40: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 CAA03087 for ; Fri, 18 Jan 2002 02:39: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 XAA00473; Thu, 17 Jan 2002 23:39: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 XAA07633; Thu, 17 Jan 2002 23:39: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 g0I7ci2Q008566 for ; Thu, 17 Jan 2002 23:38:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0I7cieS008565 for mobile-ip-dist; Thu, 17 Jan 2002 23: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 g0I7cf2Q008558 for ; Thu, 17 Jan 2002 23:38:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22059 for ; Thu, 17 Jan 2002 23:38:45 -0800 (PST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21065 for ; Fri, 18 Jan 2002 00:38:44 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0I7cg906330 for ; Fri, 18 Jan 2002 09:38:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Jan 2002 09:38:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 18 Jan 2002 09:38:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] RE: Is RR only enough ? Date: Fri, 18 Jan 2002 09:38:32 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F911757198099@esebe004.NOE.Nokia.com> Thread-Topic: [mobile-ip] RE: Is RR only enough ? Thread-Index: AcGZ4ZRQgNbptwXTEdar0gAIx6S5QwGDzR5g From: "Rajahalme Jarno (NRC/Helsinki)" To: , "Erik Nordmark" X-OriginalArrivalTime: 18 Jan 2002 07:38:33.0352 (UTC) FILETIME=[21A69880:01C19FF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0I7cf2Q008559 Sender: owner-mobile-ip@sunroof.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 Hesham wrote: > But my point is that, should > this BU security mechanism be RR only, MITM can > hijack a connection and receive the content that was > intended for the legitimate MN. The will happen, despite > the presence of e2e security (SSL, TLS, IPsec ...etc) which > äwas setup based on the relevant identity. > Now this is the major difference from today's networks. > We agree (I think) that e2e security would stop > connection hijacking (by MITM) today, but it will > not stop it if we rely on RR only for BU authentication / > authorisation. > I don't know with whom you think you agree, but I fail to see how e2e security would stop connection hijacking by MITM today. It seems that as long as the attacker is anywhere on the CN-HA path, there is no new vulnerability being introduced by RR based Mobile IP BU authorization. The benchmark case should be the "MN on it's home link" (Mobile IP would not be used), where all the traffic between MN and the CN would be visible to the same attacker. So what is the major difference? Jarno From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 04:45: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 EAA05001 for ; Fri, 18 Jan 2002 04:45:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07290; Fri, 18 Jan 2002 01:45: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 BAA29464; Fri, 18 Jan 2002 01:45: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 g0I9i42Q008791 for ; Fri, 18 Jan 2002 01:44:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0I9i4ht008790 for mobile-ip-dist; Fri, 18 Jan 2002 01:44:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0I9i02Q008783 for ; Fri, 18 Jan 2002 01:44: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 BAA04180 for ; Fri, 18 Jan 2002 01:44:06 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23466 for ; Fri, 18 Jan 2002 01:44:05 -0800 (PST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0I9i4J18462 for ; Fri, 18 Jan 2002 10:44:04 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jan 18 10:43:46 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 10:35:00 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C225@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark Subject: RE: [mobile-ip] RE: Is RR only enough ? Date: Fri, 18 Jan 2002 10:43:41 +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 g0I9i12Q008784 Sender: owner-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 my point is that, should > > this BU security mechanism be RR only, MITM can > > hijack a connection and receive the content that was > > intended for the legitimate MN. The will happen, despite > > the presence of e2e security (SSL, TLS, IPsec ...etc) which > > äwas setup based on the relevant identity. > > Now this is the major difference from today's networks. > > We agree (I think) that e2e security would stop > > connection hijacking (by MITM) today, but it will > > not stop it if we rely on RR only for BU authentication / > > authorisation. > > > > I don't know with whom you think you agree, but I fail to > see how e2e > security would stop connection hijacking by MITM today. Content-Transfer-Encoding: 8bit => Could you show a non-DoS-based scenario, in which the MITM can hijack a connection protected by ESP? > > It seems that as long as the attacker is anywhere on the CN-HA path, > there is no new vulnerability being introduced by RR based > Mobile IP BU > authorization. => Yes. The benchmark case should be the "MN on it's > home link" > (Mobile IP would not be used), where all the traffic > between MN and the > CN would be visible to the same attacker. > > So what is the major difference? => I don't understand your point. you're disagreeing that connection hijacking by MITM can be prottected by e2e security ? If so please give an example with ESP being used e2e. Note, I'm excluding DoS-based attacks. Hesham > > Jarno > From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 06:45: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 GAA06895 for ; Fri, 18 Jan 2002 06:45:21 -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 DAA16063; Fri, 18 Jan 2002 03:44: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 DAA16476; Fri, 18 Jan 2002 03:44: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 g0IBhs2Q009003 for ; Fri, 18 Jan 2002 03:43:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IBhsZO009002 for mobile-ip-dist; Fri, 18 Jan 2002 03:43: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 g0IBhp2Q008995 for ; Fri, 18 Jan 2002 03:43: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 DAA16414 for ; Fri, 18 Jan 2002 03:43:55 -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 EAA18655 for ; Fri, 18 Jan 2002 04:43:53 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id CFE04A; Fri, 18 Jan 2002 13:44:51 +0200 (EET) Message-ID: <3C480A66.1070706@nomadiclab.com> Date: Fri, 18 Jan 2002 13:43:34 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark Subject: Re: [mobile-ip] RE: Is RR only enough ? References: <009CA59D1752DD448E07F8EB2F911757198099@esebe004.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 Jarno, > It seems that as long as the attacker is anywhere on the CN-HA path, > there is no new vulnerability being introduced by RR based Mobile IP BU > authorization. The benchmark case should be the "MN on it's home link" > (Mobile IP would not be used), where all the traffic between MN and the > CN would be visible to the same attacker. > > So what is the major difference? What comes to the security from the MN's point of view, the only difference seems to be the so called "future" attacks. (see e.g. http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf) However, there is also the so called "bombing" attack (see draft-aura-bu-security-something) and another attack, which might be called "reverse bombing" or bombing on binding expiry. In the latter attack, the attacker creates an binding, orders large amounts of traffic to its CoA, and lets the binding to expire. As a result, the large amount of traffic is redirected to the home network, "bombing" it. What makes these attacks nasty is that there an attacker (which must be on path due to RR) can utilize the CN as an amplifier in a DoS attack. Furthermore, the future and bombing effects can be combined, making it possible for an attacker to visit a target network once, and then at a later date launch an DDoS attack against it. However, if we limit the lifetime of those bindings that created via an RR-only method, we can limit the extend of the "future" effect to something reasonable. It seems like we have to limit the lifetime to a few minutes or so, and require rerunning the RR protocol on each renewal. Thus, it seems like we can get _reasonable_ security level with RR-only methods. CGA gives more protection, for sure, and therefore it might be beneficial to adopt it as an optional feature. Furthermore, a policy rule saying "if two MNs claim for the same HoA, and one uses CGA while the other don't, favour the one using CGA" would cut down most concerns about an attacker always watering CGA to RR. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 11:13: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 LAA16736 for ; Fri, 18 Jan 2002 11:13:06 -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 JAA28304; Fri, 18 Jan 2002 09:12: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 IAA13902; Fri, 18 Jan 2002 08: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 g0IGBS2Q009237 for ; Fri, 18 Jan 2002 08:11:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGBRqs009236 for mobile-ip-dist; Fri, 18 Jan 2002 08:11: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGBL2Q009221; Fri, 18 Jan 2002 08:11:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18238; Fri, 18 Jan 2002 08:11:25 -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 JAA27354; Fri, 18 Jan 2002 09:11:24 -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 g0IGBL524834; Fri, 18 Jan 2002 17:11: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 RAA06682; Fri, 18 Jan 2002 17:11: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 g0IGBLQ65767; Fri, 18 Jan 2002 17:11:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201181611.g0IGBLQ65767@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 16:32:46 +0200. Date: Fri, 18 Jan 2002 17:11: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: Ingress filtering and firewalls exist already. => for IPv6? I'd like this is true but can you say more (which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists, which commercial firewalls have IPv6 support?) > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You know full well that e.g. ip6fw, ipf, iptables (all free) etc. => no, we talk about commercial firewalls even if I share my not-expressed opinion about them. So why do you spread FUD? => I don't want to spread FUD, I just wanted to show what is FUD... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 11:35: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 LAA17631 for ; Fri, 18 Jan 2002 11:35: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 IAA29895; Fri, 18 Jan 2002 08:33:11 -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 IAA20501; Fri, 18 Jan 2002 08:25: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 g0IGO12Q009344 for ; Fri, 18 Jan 2002 08:24:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGO1Ys009343 for mobile-ip-dist; Fri, 18 Jan 2002 08:24: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 g0IGNw2Q009336; Fri, 18 Jan 2002 08:23:58 -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 IAA26402; Fri, 18 Jan 2002 08:24:03 -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 JAA24661; Fri, 18 Jan 2002 09:24:01 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA04633; Fri, 18 Jan 2002 08:24:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0IGNxK13102; Fri, 18 Jan 2002 08:23:59 -0800 X-mProtect: Fri, 18 Jan 2002 08:23:59 -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 smtpdVkQa5g; Fri, 18 Jan 2002 08:23:40 PST Message-ID: <3C484BAD.9DA854FC@iprg.nokia.com> Date: Fri, 18 Jan 2002 08:22:05 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > If the downside is that then > > there is vulnerability to (single!) packets being reflected back > > to an unsuspecting home address, then: [] > > That is not the only downside. The primary downsides > have been discussed here ad nauseum. I looked at a lot of stuff, but that's the only one I saw, even though it can be dressed up in different ways. What else is there? From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 11:41: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 LAA17959 for ; Fri, 18 Jan 2002 11:41:48 -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 JAA20182; Fri, 18 Jan 2002 09:41: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 IAA23189; Fri, 18 Jan 2002 08:41: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 g0IGeA2Q009432 for ; Fri, 18 Jan 2002 08:40:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGeASQ009431 for mobile-ip-dist; Fri, 18 Jan 2002 08:40:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGe62Q009424; Fri, 18 Jan 2002 08:40:06 -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 IAA00521; Fri, 18 Jan 2002 08:40:11 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19227; Fri, 18 Jan 2002 09:40:10 -0700 (MST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118164008.EWAD27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 18:40:08 +0200 Message-ID: <002801c1a03e$cb8fcce0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" , Cc: References: <200201181611.g0IGBLQ65767@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 18:40:10 +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 > Ingress filtering and firewalls exist already. > > => for IPv6? I'd like this is true but can you say more > (which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists, > which commercial firewalls have IPv6 support?) > > => no, we talk about commercial firewalls even if I share my not-expressed > opinion about them. Francis, I really don't want to define the word "exists" as equivalent to "included in IOS". Nor do I equate it with "exists commercially". So, like Pekka Savola noted, there's a open source OSes that deal with both v6 packets as well as with v4 packets in their firewall and filtering functions. I also know some leading firewall and VPN vendors who are working on v6 versions of their products. But perhaps you meant that ingress filtering isn't generally applied for v6 yet. That might well be true. But I still don't want you take away my possibility to go out tomorrow and buy a linux box/product and configure it to do ingress filtering in my home! Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 11:43: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 LAA18040 for ; Fri, 18 Jan 2002 11:43: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 JAA21408; Fri, 18 Jan 2002 09:42: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 IAA23541; Fri, 18 Jan 2002 08:42:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IGf62Q009488 for ; Fri, 18 Jan 2002 08:41:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGf6qn009487 for mobile-ip-dist; Fri, 18 Jan 2002 08:41: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 g0IGew2Q009471; Fri, 18 Jan 2002 08:40:58 -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 IAA23133; Fri, 18 Jan 2002 08:41:03 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19805; Fri, 18 Jan 2002 09:41:01 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0IGf0Q12136; Fri, 18 Jan 2002 18:41:00 +0200 Date: Fri, 18 Jan 2002 18:40:59 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201181611.g0IGBLQ65767@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, 18 Jan 2002, Francis Dupont wrote: > Ingress filtering and firewalls exist already. > > => for IPv6? I'd like this is true but can you say more > (which IOS version has IPv6 unicast RPF and/or IPv6 advanced access lists, > which commercial firewalls have IPv6 support?) If one vendor does not please you, you can try another (not that others would have better support for these, necessarily) or bug them and/or wait :-) RPF is not required for ingress filtering, but sure makes it much easier. > > Seems like this requires a two-phase approach: phase 1 before it is > > available and phase 2 when/if it become available. > > > > => you are acking what will happen after some kilometers in a deep fog: > > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > > filtering, IPv6 firewalls, ... > > You know full well that e.g. ip6fw, ipf, iptables (all free) etc. > > => no, we talk about commercial firewalls even if I share my not-expressed > opinion about them. Why again we should care about commerical firewalls? Apparently their interests lie elsewhere; IPv6 is not significant enough for them and no one wants to pay for the extra. Therefore those that care use free products. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 11:55:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18598 for ; Fri, 18 Jan 2002 11:55:47 -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 JAA00900; Fri, 18 Jan 2002 09:55:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25943; Fri, 18 Jan 2002 08: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 g0IGs02Q009601 for ; Fri, 18 Jan 2002 08:54:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IGs0tG009600 for mobile-ip-dist; Fri, 18 Jan 2002 08:54: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 g0IGru2Q009593; Fri, 18 Jan 2002 08:53:56 -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 IAA04512; Fri, 18 Jan 2002 08:54:01 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21300; Fri, 18 Jan 2002 08:53:59 -0800 (PST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118165354.EYZR27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 18:53:54 +0200 Message-ID: <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Charlie Perkins" , Cc: References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> <3C484BAD.9DA854FC@iprg.nokia.com> Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 18:53:56 +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 Charlie wrote: > > > If the downside is that then > > > there is vulnerability to (single!) packets being reflected back > > > to an unsuspecting home address, then: [] > > > > That is not the only downside. The primary downsides > > have been discussed here ad nauseum. > > I looked at a lot of stuff, but that's the only one I saw, > even though it can be dressed up in different ways. > What else is there? I think you are right Charlie, that is the only downside. (There's a bunch of other downsides related to fixing with AAA the hole HAO leaves in ingress filtering, but that's another issue.) The primary danger of unconstrained HAO is having even a small number of attackers spoof HAOs and use a large number of CNs as reflectors to attack a specific target even if your network has ingress filtering. Basically, it voids ingress filtering. 2-way i-trace would still detect the source of these attacks, at least in some cases. However, my concern is that i-trace isn't ready, isn't deployed and frankly I don't really believe it being deployed anytime soon. A hypothetical "Care of Address Option" for MIPv6 would have the same detection power. The trouble with both of these as opposed to ingress filtering is that they act after the attack is done or over, while ingress filtering prevents attacks. In situations where you have no ingress filtering there's really no difference whether we use HAOs or not. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 12:23: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 MAA19598 for ; Fri, 18 Jan 2002 12:23: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 JAA21423; Fri, 18 Jan 2002 09:18: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 JAA09778; Fri, 18 Jan 2002 09: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 g0IHBk2Q009727 for ; Fri, 18 Jan 2002 09:11:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHBjwC009726 for mobile-ip-dist; Fri, 18 Jan 2002 09:11: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 g0IHBd2Q009711; Fri, 18 Jan 2002 09:11:39 -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 JAA29447; Fri, 18 Jan 2002 09:11:44 -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 KAA10161; Fri, 18 Jan 2002 10:11:43 -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 g0IHBd502402; Fri, 18 Jan 2002 18:11:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA08915; Fri, 18 Jan 2002 18:11:40 +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 g0IHBdQ66006; Fri, 18 Jan 2002 18:11:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 15:37:20 +0100. Date: Fri, 18 Jan 2002 18:11:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: No, but the specification of MIPv6 should wait until the ingress filtering part is specified. => I don't see why? Or do you argue that the ingress filtering part is impossible or very long to specify (obviously not)? The purpose to move this thread to the IPv6 WG mailing-list is just to fix it in parallel. If we (the IETF) really care about security we need to make sure that we don't create holes in the set of standards track RFCs we issue. => I agree but in this case the target is explicitely "not introduce significant new vulnerabilities that are not present in IPv4 today". The new vulnerability has not be proved to be significant and the proposed reply is designed to get back to the IPv4 situation (where the reply to the threat, I have to say it again, is a BCP). That is all the IETF need to worry about. => I disagree, the IETF need to worry about holes in the set of standards track RFCs we have already issued (the RFCs) and missed (holes). (this should not happen but we know it's happened) For the IETF I think this means that we should not issue a proposed standard (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be made aware of HAO). => I believe you'll have the same opinion about BU security too (i.e. byebye RR :-). If we want to go this path I think we need a community supported => supported = saying this is the solution or supported = have implemented it or supported = have deployed it First is fine, second is possible (MIPv6 people will put pressure on firewall people, IMHO firewall people need to be more aware of IPv6 in general). The last one is out of the scope of the IETF. ingress filtering RFC (BCP or standards track) that handles HAO no later than when MIPv6 becomes Proposed Standard. I don't think we should use the fact that 1) there are IPv6 products with incomplete security and/or 2) existing IPv6 operational networks have incomplete security as arguments that we can have an IPv6 story where the standards have security holes. Even if we say "we'll fill that hole really => I never use the "we'll fill" argument. My idea is "we can fill/we know how to fill" in order to not slow down MIPv6 specifications. To move the thread to the IPv6 WG is for the same purpose. quickly by later producing an HAO aware ingress filtering RFC" or something similar. It seems like the IETF pieces (RFCs) that need to be completed to have complete (i.e. not security holes in the combination of specs) specification for network access control is sizeable: some fireall spec (perhaps informational), some radius and diameter extensions. => we need only some radius extensions (diameter extensions already exist (as an author of one of the diameter for MIPv6 drafts, I may claim this), firewall specs are not really in the scope of the IETF). Of course if diameter for MIPv6 becomes a real AAA WG activity (this is in the charter of AAA, the AAA/mobility RFC is very well written (it makes no difference between IPv4 and IPv6), but AAA people believe MIPv6 will be ready in many months/years). This sounds like more delay for MIPv6 to me. => not if it is done in parallel. The two-phase approach removes this delay. => by dropping in practice the second phase, no thanks! > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are asking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You're confusing specifications, products, and deployed practice. => no, I just reject all arguments based on what will happen in the future at the exception that we want to get IPv6 smart ingress filtering deployed not after than mobile IPv6. The IETF has no control over deployment, its control is only over document publication, so the only thing we can ask is to provide smart ingress filtering documents before MIPv6 (we can do a bit more because we can implement them too). People can build ingress filtering and firewalls for IPv6 today without waiting for a specification from the IETF. That wouldn't be true if we issue a MIPv6 specification which, in order to avoid ingress filtering, depends on some yet to be written RFCs that specify network access control for HAO. =. can I translate your argument in the network access control for HAO documents should be available (or enough stable) before the MIPv6 one in the same state? This is unrealistic for DIAMETER (because of the AAA state), easy for RADIUS and out of the scope of the IETF for firewalls (I am not a firewall expert, I only know that many commercial firewalls have a network access control module... in fact the whole idea is from a team with some firewall persons so I know the whole thing was put in a commercial firewall more than two years ago but the @#$... people don't believe there is a market, grr...). But we don't want to delay MIPv6 any more than we need to. => my purpose was never to delay MIPv6 but we obviously disagree about what kind of stuff can be removed safely (i.e. with the possibility to put them back after) from MIPv6 in order to speed it up. Regards Francis.Dupont@enst-bretagne.fr PS: we are losing time: keep or kill the triangular routing? From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 12:38:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20206 for ; Fri, 18 Jan 2002 12:38:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00986; Fri, 18 Jan 2002 09:38: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 JAA17778; Fri, 18 Jan 2002 09:37: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 g0IHaW2Q009916 for ; Fri, 18 Jan 2002 09:36:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHaWrm009915 for mobile-ip-dist; Fri, 18 Jan 2002 09:36: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 g0IHaP2Q009900; Fri, 18 Jan 2002 09:36:25 -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 JAA17363; Fri, 18 Jan 2002 09:36:26 -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 KAA03014; Fri, 18 Jan 2002 10:36:24 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0IHaCr12556; Fri, 18 Jan 2002 19:36:12 +0200 Date: Fri, 18 Jan 2002 19:36:12 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: Charlie Perkins , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <005d01c1a040$b7d930e0$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: On Fri, 18 Jan 2002, Jari Arkko wrote: > > I looked at a lot of stuff, but that's the only one I saw, > > even though it can be dressed up in different ways. > > What else is there? > > I think you are right Charlie, that is the only downside. > (There's a bunch of other downsides related to fixing > with AAA the hole HAO leaves in ingress filtering, but > that's another issue.) > > The primary danger of unconstrained HAO is having even a small > number of attackers spoof HAOs and use a large > number of CNs as reflectors to attack a specific > target even if your network has ingress filtering. > Basically, it voids ingress filtering. [snip] There is a downside: destination site's filtering ("spoofing protection" from the direction of the Internet) is nullified! (This attack is especially nasty in "send an UDP exploit" scenarios -- not necessarily DoS.) This can be more or less partially repaired, by e.g. allow incoming HAO with local Home Address only from local MN's, or local MN's that are known to be outside, or even local MN's that match a specific binding and are outside. However, for security, that requires packet filters wanting to protect from this must have the ability to go into extension headers and match against HAO.. this is not yet implemented anywhere that I know of; requirinig this for security of HAO might be too much. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 12:42:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20364 for ; Fri, 18 Jan 2002 12:42:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06296; Fri, 18 Jan 2002 10:42:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19586; Fri, 18 Jan 2002 09:42: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 g0IHfG2Q009970 for ; Fri, 18 Jan 2002 09:41:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHfG7L009969 for mobile-ip-dist; Fri, 18 Jan 2002 09:41:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHfD2Q009962; Fri, 18 Jan 2002 09:41:13 -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 JAA08728; Fri, 18 Jan 2002 09:41:18 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16633; Fri, 18 Jan 2002 10:41:17 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0IHf9A09749; Fri, 18 Jan 2002 09:41:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAS02923; Fri, 18 Jan 2002 09:40:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17427; Fri, 18 Jan 2002 09:41:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.24117.377768.561852@thomasm-u1.cisco.com> Date: Fri, 18 Jan 2002 09:41:09 -0800 (PST) To: Pekka Savola Cc: Jari Arkko , Charlie Perkins , , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: References: <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Savola writes: > On Fri, 18 Jan 2002, Jari Arkko wrote: > > > I looked at a lot of stuff, but that's the only one I saw, > > > even though it can be dressed up in different ways. > > > What else is there? > > > > I think you are right Charlie, that is the only downside. > > (There's a bunch of other downsides related to fixing > > with AAA the hole HAO leaves in ingress filtering, but > > that's another issue.) > > > > The primary danger of unconstrained HAO is having even a small > > number of attackers spoof HAOs and use a large > > number of CNs as reflectors to attack a specific > > target even if your network has ingress filtering. > > Basically, it voids ingress filtering. > [snip] > > There is a downside: destination site's filtering ("spoofing protection" > from the direction of the Internet) is nullified! Thank you. That was exactly what my point was. It's not just the reflector attack; the HAO nullifies all of the ingress filtering present on the net right now. That is distinctly worse than the status quo. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 12:51: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 MAA20729 for ; Fri, 18 Jan 2002 12:51:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06925; Fri, 18 Jan 2002 09:50: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 JAA22577; Fri, 18 Jan 2002 09:49: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 g0IHlr2Q010187 for ; Fri, 18 Jan 2002 09:47:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHlqKs010186 for mobile-ip-dist; Fri, 18 Jan 2002 09:47:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHln2Q010179 for ; Fri, 18 Jan 2002 09:47: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 JAA07551 for ; Fri, 18 Jan 2002 09:47:55 -0800 (PST) Received: from localhost.localdomain (gw.netseal.com [195.94.100.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18773 for ; Fri, 18 Jan 2002 09:47:53 -0800 (PST) Received: from localhost (sami.vaarala@localhost) by localhost.localdomain (8.9.3/8.9.3) with ESMTP id KAA04812 for ; Wed, 16 Jan 2002 10:37:00 +0200 X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Wed, 16 Jan 2002 10:37:00 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns In-Reply-To: <0DCC27458EB5D51181840002A507069EE30DAF@orsmsx117.jf.intel.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: Prakash, > Henrik, > > I think the folks who responded were responding to the question: is this a > problem to work on and solve and not specifically if they endorse the > draft. That is true with respect to the NAT draft as well by the way. So > in a sense the question is: would you like to see this work be taken up > by the WG. Yes, I agree. With regards to the NAT traversal draft, I don't personally care what it looks like, as long as it works, is simple, and solves the problem in a way that can be agreed upon, so that I can avoid implementing a dozen different NAT traversals for interoperability purposes. So if you have an issue with NAT traversal, scream! About the VPN/Mobile IP issue, I think it is definitely an important one. What I'm not sure about is that it is a *MIP WG* issue (i.e. does it require MIP changes). Maybe it cannot be solved in parts, but maybe it can. In the latter case there doesn't seem to be a proper place for it -- maybe an informational RFC? > Regards. > -Prakash Best regards, -Sami From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 12:51:18 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20744 for ; Fri, 18 Jan 2002 12:51:17 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06609; Fri, 18 Jan 2002 09:49:41 -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 JAA22755; Fri, 18 Jan 2002 09:49: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 g0IHmE2Q010215 for ; Fri, 18 Jan 2002 09:48:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHmE8X010214 for mobile-ip-dist; Fri, 18 Jan 2002 09:48: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 g0IHm92Q010204; Fri, 18 Jan 2002 09:48:09 -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 JAA01775; Fri, 18 Jan 2002 09:48:15 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19853; Fri, 18 Jan 2002 10:48:14 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0IHm4j14595; Fri, 18 Jan 2002 09:48:05 -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 AAS03117; Fri, 18 Jan 2002 09:47:29 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA17430; Fri, 18 Jan 2002 09:48:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.24529.242954.233574@thomasm-u1.cisco.com> Date: Fri, 18 Jan 2002 09:48:01 -0800 (PST) To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> References: <200201181711.g0IHBdQ66006@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > If we (the IETF) really care about security we need to make sure > that we don't create holes in the set of standards track RFCs we > issue. > > => I agree but in this case the target is explicitely "not introduce > significant new vulnerabilities that are not present in IPv4 today". > The new vulnerability has not be proved to be significant and the > proposed reply is designed to get back to the IPv4 situation (where > the reply to the threat, I have to say it again, is a BCP). Positing AAA as the necessary band-aid is a non-starter. Positing the kind of fix I proposed as a "crazy idea" runs into problems with middle of the network RPF checking and will, in practice, sink any use of route optimization. HAO's cannot defeat ingress filtering. That is distinctly worse than the current net. I think we seriously need to consider whether we should sever route optimization from this draft. Sigh. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 13:06: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 NAA21373 for ; Fri, 18 Jan 2002 13:06: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 LAA25571; Fri, 18 Jan 2002 11:06: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 KAA13290; Fri, 18 Jan 2002 10:05: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 g0II4Y2Q010474 for ; Fri, 18 Jan 2002 10:04:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0II4YSB010473 for mobile-ip-dist; Fri, 18 Jan 2002 10:04: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 g0II4S2Q010458; Fri, 18 Jan 2002 10:04:28 -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 KAA12828; Fri, 18 Jan 2002 10:04:34 -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 LAA24256; Fri, 18 Jan 2002 11:04:32 -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 g0II4V512738; Fri, 18 Jan 2002 19:04:31 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA10325; Fri, 18 Jan 2002 19:04:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0II4VQ66490; Fri, 18 Jan 2002 19:04:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201181804.g0II4VQ66490@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Thu, 17 Jan 2002 08:49:24 PST. <3C470094.29B50022@iprg.nokia.com> Date: Fri, 18 Jan 2002 19:04:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I'm pretty far behind on reading these voluminous e-mails, but I would at least like to express again my belief that we could go forward with the HAO as it is. If the downside is that then there is vulnerability to (single!) packets being reflected back to an unsuspecting home address, then: - This is not a completely horrible problem => I agree but it seems there is the real point... - Solutions involving use of security associations between mobile and correspondent will be developed more rapidly if there is motivation for use with Proposed Standard Mobile IPv6 => a two phase approach works never in the security domain or the triangular routing needs HAO support everywhere to make sense. - We can be done almost immediately, and begin to productively tackle the issues more effectively with experience. => I still believe the idea to send IPv6 questions to the IPv6 WG is the correct one. In fact the decision of keeping or killing the triangular routing is in the hands of IPv6 implementors (they are supposed to read the IPv6 WG list from time to time). I think there is a very real possibility that we are getting stalled in worrying over a problem that is not going to happen. => to get stalled is the worst way to get a decision. A couple of other points: Francis Dupont wrote: > => we don't need to wait because mobile IPv6 is not yet fully specified. That is purely a matter of opinion. => or of what is the meaning of fully specified. It seems I am the author of this statement so I meant "not yet ready for publication". In my opinion, we are not moving forward because we are being required to boil the ocean before even being allowed to take a drink. => this one of the drawbacks of security issues... I am not commenting other remarks because we agree. Well, technically speaking, it was already in Last Call last year (and the year before). But I guess that is really a moot point. => is a new last call after important changes due to IESG concerns required? It seems we'll get a new WG last call, and perhaps some last calls about other (than the spec) MIPv6 documents. Regards Francis.Dupont@enst-bretagne.fr PS: you are in favor of keeping the triangular routing, aren't you? From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 13:40: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 NAA22764 for ; Fri, 18 Jan 2002 13:40:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19878; Fri, 18 Jan 2002 11:40:05 -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 KAA10058; Fri, 18 Jan 2002 10:39: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 g0IIck2Q010805 for ; Fri, 18 Jan 2002 10:38:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IIckkr010804 for mobile-ip-dist; Fri, 18 Jan 2002 10:38: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 g0IIcf2Q010797; Fri, 18 Jan 2002 10:38:41 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14724; Fri, 18 Jan 2002 10:38:48 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14004; Fri, 18 Jan 2002 10:38:46 -0800 (PST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118183845.FTIJ27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 20:38:45 +0200 Message-ID: <00cb01c1a04f$5dac0660$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pekka Savola" Cc: "Charlie Perkins" , , References: Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 20:38:47 +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 > There is a downside: destination site's filtering ("spoofing protection" > from the direction of the Internet) is nullified! Yeah. Forgot that, sorry! Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 14:41:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24581 for ; Fri, 18 Jan 2002 14:41: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 MAA04176; Fri, 18 Jan 2002 12:41: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 LAA28872; Fri, 18 Jan 2002 11:41: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 g0IJdr2Q011152 for ; Fri, 18 Jan 2002 11:39:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IJdrEo011151 for mobile-ip-dist; Fri, 18 Jan 2002 11:39:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IJdo2Q011144 for ; Fri, 18 Jan 2002 11:39:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28580 for ; Fri, 18 Jan 2002 11:39:55 -0800 (PST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09447 for ; Fri, 18 Jan 2002 12:39:53 -0700 (MST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id TAA25830 for ; Fri, 18 Jan 2002 19:39:52 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011811420030113 for ; Fri, 18 Jan 2002 11:42:00 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 11:39:52 -0800 Message-ID: From: "Adrangi, Farid" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Date: Fri, 18 Jan 2002 11:39:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Sami: My two cents ... I don't have any problem with NAT traversal draft that you and Henrik submitted at this point. But, I am not sure about its applicability on most likely deployed network scenarios. In the first IETF meeting, you guys summarized all possible NAT and NAT/VPN scenarios (http://www.levkowetz.com/pub/id/nat-mip-scenarios.html and http://www.levkowetz.com/pub/id/nat-vpn-scenarios.html ). In my opinion, the NAT scenarios are not too appealing as the home network will most likely be protected by a firewall or a VPN gateway. However, the scenarios "c" and "d" in the NAT/VPN scenarios look more real to me (i.e, you will most likely encounter these types of network deployments) -- BTW, a NAT gateway could also be in the path of a MN and the VPN-GW in these scenarios. Best regards, Farid -----Original Message----- From: Sami Vaarala [mailto:sami.vaarala@netseal.com] Sent: Wednesday, January 16, 2002 12:37 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Consensus call - MIPv4 interopration with NATs/VP Ns Prakash, > Henrik, > > I think the folks who responded were responding to the question: is this a > problem to work on and solve and not specifically if they endorse the > draft. That is true with respect to the NAT draft as well by the way. So > in a sense the question is: would you like to see this work be taken up > by the WG. Yes, I agree. With regards to the NAT traversal draft, I don't personally care what it looks like, as long as it works, is simple, and solves the problem in a way that can be agreed upon, so that I can avoid implementing a dozen different NAT traversals for interoperability purposes. So if you have an issue with NAT traversal, scream! About the VPN/Mobile IP issue, I think it is definitely an important one. What I'm not sure about is that it is a *MIP WG* issue (i.e. does it require MIP changes). Maybe it cannot be solved in parts, but maybe it can. In the latter case there doesn't seem to be a proper place for it -- maybe an informational RFC? > Regards. > -Prakash Best regards, -Sami From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 14:46:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24747 for ; Fri, 18 Jan 2002 14:46:50 -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 MAA08173; Fri, 18 Jan 2002 12:46: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 JAA21385; Fri, 18 Jan 2002 09:46:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0IHjZ2Q010080 for ; Fri, 18 Jan 2002 09:45:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IHjZHN010079 for mobile-ip-dist; Fri, 18 Jan 2002 09:45: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 g0IHjV2Q010069; Fri, 18 Jan 2002 09:45:31 -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 JAA06881; Fri, 18 Jan 2002 09:45:37 -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 JAA17749; Fri, 18 Jan 2002 09:45:36 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA10204; Fri, 18 Jan 2002 09:45:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0IHjVT32213; Fri, 18 Jan 2002 09:45:31 -0800 X-mProtect: Fri, 18 Jan 2002 09:45:31 -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 smtpdNod5Pi; Fri, 18 Jan 2002 09:45:29 PST Message-ID: <3C485F3A.2D5795C6@iprg.nokia.com> Date: Fri, 18 Jan 2002 09:45:30 -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: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> <3C484BAD.9DA854FC@iprg.nokia.com> <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jari, Thank you very much for this clarification. Jari Arkko wrote: >> I looked at a lot of stuff, but that's the only one I saw, >> even though it can be dressed up in different ways. >> What else is there? > > I think you are right Charlie, that is the only downside. > (There's a bunch of other downsides related to fixing > with AAA the hole HAO leaves in ingress filtering, but > that's another issue.) AAA for IPv6 is, indeed, quite another problem domain, and one for which we've hardly started considering the issues. > The primary danger of unconstrained HAO is having even a small > number of attackers spoof HAOs and use a large > number of CNs as reflectors to attack a specific > target even if your network has ingress filtering. > Basically, it voids ingress filtering. Here, I disagree, although I clearly understand why you would say that. The reason I disagree, is that I can specify an augmented ingress filtering router that will work with HAOs (and, actually, have already begun to done so). I do understand that such a thing is harder to build. Furthermore, I am quite reluctant to get embroiled in a design discussion about building ingress filtering routers (notwithstanding (*) below), when what I really want to do is to move the Mobile IPv6 specification forward. > 2-way i-trace would still detect the source of these attacks, at least > in some cases. However, my concern is that i-trace isn't ready, > isn't deployed and frankly I don't really believe it being deployed > anytime soon. A hypothetical "Care of Address Option" for MIPv6 > would have the same detection power. The trouble with both of > these as opposed to ingress filtering is that they act after the attack > is done or over, while ingress filtering prevents attacks. But the larger problem is that we are being fantastically careful about avoiding a possible future problem that is: 1) solvable in a backwards compatible way 2) not so horrible, 3) delaying by years the specification, and consequently 4) causing other design dislocations in, e.g., 3G. --------------------------------- In an effort to be constructive, here are some further ideas about how to limit the damage from the packet reflection which can be caused by malicious use of unrestricted HAOs. 1) The correspondent node can strictly limit the number of care-of addresses available to any one home address (to, say, one or two). It _could_ even do so for the number of care-of addresses assignable to home addresses on a particular subnet, if we wanted to go to the trouble of putting the prefix length back into the Binding Update. 2) The ingress filtering router can strictly limit the number of HAOs transmitted from any particular subnet prefix per unit time (*). These are the first things that come to mind, and I believe they are quite simple to implement. (1) certainly is. Plus, I believe that, for the purposes of handling HAOs, we should begin to distinguish between home addresses that have security associations established with the correspondent node, and home addresses that do not. It is the latter variety that need to have the strict numerical limitations. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 15:27:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25878 for ; Fri, 18 Jan 2002 15:27:41 -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 LAA24668; Fri, 18 Jan 2002 11: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 KAA12323; Fri, 18 Jan 2002 10: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 g0IIjj2Q010902 for ; Fri, 18 Jan 2002 10:45:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0IIjjvJ010901 for mobile-ip-dist; Fri, 18 Jan 2002 10:45: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 g0IIjf2Q010894; Fri, 18 Jan 2002 10:45: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 KAA01958; Fri, 18 Jan 2002 10:45:47 -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 LAA11880; Fri, 18 Jan 2002 11:45:46 -0700 (MST) Received: from jariws1 ([62.248.147.247]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020118184545.FUWH27150.fep02-app.kolumbus.fi@jariws1>; Fri, 18 Jan 2002 20:45:45 +0200 Message-ID: <00cc01c1a050$58618b20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Charles E. Perkins" Cc: , References: <200201171335.g0HDZmQ60713@givry.rennes.enst-bretagne.fr> <3C470094.29B50022@iprg.nokia.com> <15431.8097.648763.243323@thomasm-u1.cisco.com> <3C484BAD.9DA854FC@iprg.nokia.com> <005d01c1a040$b7d930e0$8a1b6e0a@arenanet.fi> <3C485F3A.2D5795C6@iprg.nokia.com> Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion Date: Fri, 18 Jan 2002 20:45:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Here, I disagree, although I clearly understand why you would say > that. Fair enough. Reading on... > The reason I disagree, is that I can specify an augmented > ingress filtering router that will work with HAOs (and, actually, > have already begun to done so). I do understand that such a thing > is harder to build. Furthermore, I am quite reluctant to get > embroiled in a design discussion about building ingress filtering > routers (notwithstanding (*) below), when what I really want to > do is to move the Mobile IPv6 specification forward. Yes. Your approach is a good one, but I think the concern people have is that they are doubtful whether a sufficiently good solution exists. I simply don't believe in the AAA approach to fix this problem, for instance (even if I'm a big fan of AAA for other purposes and even partially behind the Diameter base spec). So, if you were able to give some clue to the plan how what you intend to achieve, perhaps we could go with this approach then. However, for the moment as has appeared such a hard problem to me that I really need to see a some convincing parts of the solution at least before I'd believe this really can be done. > In an effort to be constructive, here are some further ideas about > how to limit the damage from the packet reflection which can be > caused by malicious use of unrestricted HAOs. Excellent! > 1) The correspondent node can strictly limit the number of > care-of addresses available to any one home address (to, > say, one or two). It _could_ even do so for the number > of care-of addresses assignable to home addresses on a > particular subnet, if we wanted to go to the trouble of > putting the prefix length back into the Binding Update. Unfortunately I don't think this will work. One property of the HAO reflection vulnerability is that the number of nodes offering "reflection service" is roughly the size of the IPv6 Internet. So, any rate limitation / address limitation etc will not help if the attacker chooses another CN the next time. > 2) The ingress filtering router can strictly limit the number > of HAOs transmitted from any particular subnet prefix > per unit time (*). This is better than the previous one. But I'm still not too happy with it. How do we ensure that what seems like a small bandwidth at the Nokia Research Group router isn't going to feel like a catastrophy at my home link? And what if everyone in the Nokia Research Group wanted to use HAOs at the same time, would their traffic capacity be cut down too much? What would the value be? What will it require from the router, is state involved or can you do it in stateless way? Also, if the HAO reflection would be used to hide DDoS attack clients in a number of places, rate limitation at single router might not help. > Plus, I believe that, for the purposes of handling HAOs, > we should begin to distinguish between home addresses that > have security associations established with the correspondent > node, and home addresses that do not. It is the latter > variety that need to have the strict numerical limitations. I'll treat this as the third offered solution. Like I think Pekka mentioned some time ago, there's ways of coming up with SAs that don't necessarily live up to this standard, even if such SAs would be useful for e.g. preventing passive wiretapping. But given that Opportunistic IPsec is not deployed much yet, maybe we could put that consideration aside. Perhaps we should then consider a rule that forbids HAOs if there's no SA involved? That would be a possibility. The downside is that you'd still have to provide for bidir tunneling for cleartext communications. Then I could also ask that if you bothered to do 2xRSA+1xD-H and keep at least a few hundred bytes of state at both ends, why couldn't you use RO at that time too? In conclusion I like these ideas better than the AAA approach. However, I still think we'd need something even better to start considering this alternative for real. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 18 16:34: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 QAA28046 for ; Fri, 18 Jan 2002 16:34:00 -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 OAA18067; Fri, 18 Jan 2002 14:33: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 NAA21043; Fri, 18 Jan 2002 13:33: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 g0ILVc2Q011476 for ; Fri, 18 Jan 2002 13:31:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0ILVcrA011475 for mobile-ip-dist; Fri, 18 Jan 2002 13:31: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 g0ILVZ2Q011468 for ; Fri, 18 Jan 2002 13:31: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 NAA00008 for ; Fri, 18 Jan 2002 13:31:26 -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 OAA01175 for ; Fri, 18 Jan 2002 14:31:25 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA27044 for ; Fri, 18 Jan 2002 14:31:25 -0700 (MST)] Received: [from il02exb01.comm.mot.com (il02exb01.comm.mot.com [145.1.204.17]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA27853 for ; Fri, 18 Jan 2002 14:31:24 -0700 (MST)] Received: by il02exb01.comm.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 18 Jan 2002 15:31:24 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F310930EF1D@il02exm26.comm.mot.com> From: Lewis Adam-CAL022 To: Mobile-IP working group Subject: [mobile-ip] HA redundancy in MIPv4 Date: Fri, 18 Jan 2002 15:31:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: What work is being done in this area? I know that Cisco has a solution which runs a HA redundancy protocol on top of HSRP, and 3Com seems to have a HA chassis solution that supports redundant HAs. Both these seem to be proprietery in nature. A draft not too long ago draft-chambless-mobileip-harp-00.txt talked about doing it, but I haven't seen any follow up activity to it. This seems to me like a critical problem to solve, does anybody have any further information on this relating to a standards activity? Maybe something similar to what Cisco does, but using VRRP instead? Thanks, adam From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 19 12:45:05 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20743 for ; Sat, 19 Jan 2002 12: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 JAA12810; Sat, 19 Jan 2002 09:44: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 JAA25145; Sat, 19 Jan 2002 09:44: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 g0JHhK2Q012147 for ; Sat, 19 Jan 2002 09:43:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JHhKDV012146 for mobile-ip-dist; Sat, 19 Jan 2002 09:43:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JHhH2Q012139 for ; Sat, 19 Jan 2002 09:43:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23574 for ; Sat, 19 Jan 2002 09:43:23 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05997 for ; Sat, 19 Jan 2002 10:43:22 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0JHh8511990; Sat, 19 Jan 2002 18:43: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 SAA04079; Sat, 19 Jan 2002 18:43: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 g0JHh8Q72758; Sat, 19 Jan 2002 18:43:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201191743.g0JHh8Q72758@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 18:40:59 +0200. Date: Sat, 19 Jan 2002 18:43:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: If one vendor does not please you, you can try another (not that others would have better support for these, necessarily) or bug them and/or wait :-) => this argument works only when this is at least one commercial proposal. RPF is not required for ingress filtering, but sure makes it much easier. => ingress filtering can be divided in router-based, aka unicast RPF, and firewall-based, aka intelligent access lists. If my proposal applies to the second one, I've never considered the first as superfluous: we need both and we have no commercial product of any of them. This is a dangerous and unbearable situation (and has nothing to do in this thread). > => no, we talk about commercial firewalls even if I share my not-expressed > opinion about them. Why again we should care about commerical firewalls? => because by definition the market cares about them. Apparently their interests lie elsewhere; IPv6 is not significant enough for them and no one wants to pay for the extra. => this is what we should change. Therefore those that care use free products. => you know this is simply not true in the real world... (what we'd like to be as nothing to do there) Regards Francis.Dupont@enst-bretagne.fr PS: I've answered to your message because I should reuse it if one day someone argues "this is only implemented in free products"... From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 19 12:51:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20832 for ; Sat, 19 Jan 2002 12:51: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 JAA13493; Sat, 19 Jan 2002 09:50:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28480; Sat, 19 Jan 2002 09:50: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 g0JHo22Q012263 for ; Sat, 19 Jan 2002 09:50:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JHo2XO012262 for mobile-ip-dist; Sat, 19 Jan 2002 09:50: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 g0JHnw2Q012255 for ; Sat, 19 Jan 2002 09:49:59 -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 JAA29428 for ; Sat, 19 Jan 2002 09:50:04 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21973 for ; Sat, 19 Jan 2002 10:50:03 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0JHo1n22558; Sat, 19 Jan 2002 19:50:01 +0200 Date: Sat, 19 Jan 2002 19:50:00 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201191743.g0JHh8Q72758@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Sat, 19 Jan 2002, Francis Dupont wrote: > RPF is not required for ingress filtering, but sure makes it much easier. > > => ingress filtering can be divided in router-based, aka unicast RPF, > and firewall-based, aka intelligent access lists. If my proposal applies > to the second one, I've never considered the first as superfluous: > we need both and we have no commercial product of any of them. > This is a dangerous and unbearable situation (and has nothing to > do in this thread). Wrong. Ingress filtering done with non-RPF mechanisms does not need to intelligent. -- 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 Sat Jan 19 13:07: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 NAA20953 for ; Sat, 19 Jan 2002 13:07: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 KAA15303; Sat, 19 Jan 2002 10:07:26 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06721; Sat, 19 Jan 2002 10:07: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 g0JI6N2Q012331 for ; Sat, 19 Jan 2002 10:06:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JI6MDI012330 for mobile-ip-dist; Sat, 19 Jan 2002 10:06:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JI6G2Q012315; Sat, 19 Jan 2002 10:06:16 -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 KAA26432; Sat, 19 Jan 2002 10:06:22 -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 KAA05721; Sat, 19 Jan 2002 10:06:17 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0JI65513122; Sat, 19 Jan 2002 19:06:05 +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 TAA04501; Sat, 19 Jan 2002 19:06:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0JI65Q72882; Sat, 19 Jan 2002 19:06:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201191806.g0JI65Q72882@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Jari Arkko , Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 19:36:12 +0200. Date: Sat, 19 Jan 2002 19:06:05 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: There is a downside: destination site's filtering ("spoofing protection" from the direction of the Internet) is nullified! (This attack is especially nasty in "send an UDP exploit" scenarios -- not necessarily DoS.) => this is 4.1 section of my draft: - the vulnerability can exist *only* if there are some home agents inside the site (this is a strong constraint) - the defense is basically the same: the filtering devices have to know the bindings (the home registrations are enough) by the way you'd like (several work, the only implementation I know uses BU/BA snooping with success). This can be more or less partially repaired, by e.g. allow incoming HAO with local Home Address only from local MN's, or local MN's that are known to be outside, or even local MN's that match a specific binding and are outside. => no, this can be fully repaired. And in most cases very easily: no home agent = no binding = just apply the anti-spoofing to everything that can be a source address. However, for security, that requires packet filters wanting to protect from this must have the ability to go into extension headers and match against HAO.. => if your packet filter doesn't already do that, change it ASAP. this is not yet implemented anywhere that I know of; => this was implemented 30 months ago somewhere I know of. (I can ask for a testimony if you really want it) requiring this for security of HAO might be too much. => if I apply your argument to the routing header it should be forbidden... I strongly disagree: stupid defects in some stupid firewalls should not be admissible arguments against a protocol feature. Regards Francis.Dupont@enst-bretagne.fr PS: the position of the HAO in packets was required by some firewall people, so I believe there are at least two firewall expert teams which already managed how to deal with HAOs... From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 19 13:17: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 NAA21077 for ; Sat, 19 Jan 2002 13:17:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23719; Sat, 19 Jan 2002 11:17:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11632; Sat, 19 Jan 2002 10:16:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0JIGG2Q012452 for ; Sat, 19 Jan 2002 10:16:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JIGGHK012451 for mobile-ip-dist; Sat, 19 Jan 2002 10:16: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 g0JIG82Q012436; Sat, 19 Jan 2002 10:16:08 -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 KAA28244; Sat, 19 Jan 2002 10:16:14 -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 LAA26914; Sat, 19 Jan 2002 11:16:08 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0JIFm513482; Sat, 19 Jan 2002 19:15:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA04738; Sat, 19 Jan 2002 19:15: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 g0JIFmQ72917; Sat, 19 Jan 2002 19:15:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201191815.g0JIFmQ72917@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Pekka Savola , Jari Arkko , Charlie Perkins , mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 09:41:09 PST. <15432.24117.377768.561852@thomasm-u1.cisco.com> Date: Sat, 19 Jan 2002 19:15:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Thank you. That was exactly what my point was. It's not just the reflector attack; the HAO nullifies all of the ingress filtering present on the net right now. That is distinctly worse than the status quo. => if "ingress filtering" is your message is anti-spoofing, I've answered in a previous mail, so I consider this is the traditional ingress filtering. I believe you made a confusion between causes and effects. Ingress filtering itself as no value, ingress filtering is a reply to the source address spoofing threat which itself is only an option to the DDoS threat. So the HAO problem is *only* the reflector attack in this context (i.e. without anti-spoofing considerations). Regards Francis.Dupont@enst-bretagne.fr PS: we do no progress. After Monday I'll answer only comments to my draft and threads proposed by the mobile-ip WG chairs. From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 19 14:53:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22295 for ; Sat, 19 Jan 2002 14:53:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11417; Sat, 19 Jan 2002 12:53:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09983; Sat, 19 Jan 2002 11:53: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 g0JJq22Q012661 for ; Sat, 19 Jan 2002 11:52:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0JJq22E012660 for mobile-ip-dist; Sat, 19 Jan 2002 11:52: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 g0JJpt2Q012645; Sat, 19 Jan 2002 11:51:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09902; Sat, 19 Jan 2002 11:52:00 -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 MAA05239; Sat, 19 Jan 2002 12:51:59 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0JJpvT23418; Sat, 19 Jan 2002 21:51:57 +0200 Date: Sat, 19 Jan 2002 21:51:57 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , Charlie Perkins , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201191806.g0JI65Q72882@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Sat, 19 Jan 2002, Francis Dupont wrote: > There is a downside: destination site's filtering ("spoofing protection" > from the direction of the Internet) is nullified! > > (This attack is especially nasty in "send an UDP exploit" scenarios -- not > necessarily DoS.) > > => this is 4.1 section of my draft: I know. You're making assumptions here: - every packet filter in the internet can 1) recognize HAO 2) parse it, and 3) match against the address in it This does not hold *at all*. I doubt very much even a half of IPv6 packet filters, router access-lists etc. would do this in a few years' time (look how long it has taken to e.g. get anycast implemented, and to what success..). The easiest method, which *might* be deployable soonish would be a check whether HAO exists or not (1) above), and drop all packets with it. However, this would kill all the use for HAO too; not good enough. Iff 3) above holds, every site which does not have mobile nodes of its own can be protected. (If it has MN's, state/AAA or more lax security for the addresses is required.) In my opinion, this is an unrealistic requirement. > - the vulnerability can exist *only* if there are some home agents > inside the site (this is a strong constraint) > - the defense is basically the same: the filtering devices have to > know the bindings (the home registrations are enough) by the way > you'd like (several work, the only implementation I know uses > BU/BA snooping with success). > > This can be more or less partially repaired, by e.g. allow incoming HAO > with local Home Address only from local MN's, or local MN's that are known > to be outside, or even local MN's that match a specific binding and are > outside. > > => no, this can be fully repaired. And in most cases very easily: > no home agent = no binding = just apply the anti-spoofing to everything > that can be a source address. See above. > However, for security, that requires packet filters wanting to protect > from this must have the ability to go into extension headers and match > against HAO.. > > => if your packet filter doesn't already do that, change it ASAP. I don't know of any alternative. > this is not yet implemented anywhere that I know of; > > => this was implemented 30 months ago somewhere I know of. > (I can ask for a testimony if you really want it) I'm interested, sure. But really, I'm not all that interested if it was implemented just somewhere and not integrated with any firewalling products. > requiring this for security of HAO might be too much. > > => if I apply your argument to the routing header it should be forbidden... > I strongly disagree: stupid defects in some stupid firewalls should not > be admissible arguments against a protocol feature. Perhaps, perhaps not. But I was not advocating Routing Headers be filtered in firewalls; I was not advocating HAO be either (because both are difficult problems which I think will not be deployed in the real world very widely). Instead, I was advocating stronger checks in the end-nodes, thus eliminating the need for firewall security checks except for those 1% who really want to go and build the AAA system to get the extra control and security. For routing headers, it appears this issue will be clarified. For HAO, this is still open as it would require bigger modifications. > PS: the position of the HAO in packets was required by some firewall people, > so I believe there are at least two firewall expert teams which already > managed how to deal with HAOs... Wrong assumption. This means some firewall people have analyzed what it seems to be required to manage HAO at all: whether it can be checked under every circumstance (e.g. IPSEC secured data) and where it is usually located (check for the existance of the header, not necessarily the content). This speaks nothing for implementing parsing for it, or anything. -- 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 Sun Jan 20 08:56:32 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10475 for ; Sun, 20 Jan 2002 08:56:31 -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 FAA26277; Sun, 20 Jan 2002 05:56:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17512; Sun, 20 Jan 2002 05:55: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 g0KDsu2Q013358 for ; Sun, 20 Jan 2002 05:54:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KDsuQJ013357 for mobile-ip-dist; Sun, 20 Jan 2002 05:54: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 g0KDsn2Q013342; Sun, 20 Jan 2002 05:54: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 FAA02956; Sun, 20 Jan 2002 05:54:55 -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 GAA18565; Sun, 20 Jan 2002 06:54:50 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0KDsm527188; Sun, 20 Jan 2002 14:54:48 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA22376; Sun, 20 Jan 2002 14:54:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0KDslQ74834; Sun, 20 Jan 2002 14:54:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201201354.g0KDslQ74834@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Fri, 18 Jan 2002 09:45:30 PST. <3C485F3A.2D5795C6@iprg.nokia.com> Date: Sun, 20 Jan 2002 14:54:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: AAA for IPv6 is, indeed, quite another problem domain, and one for which we've hardly started considering the issues. => Jari meant network access control, not full AAA with AAA infrastructure. Furthermore, I am quite reluctant to get embroiled in a design discussion about building ingress filtering routers (notwithstanding (*) below), when what I really want to do is to move the Mobile IPv6 specification forward. => I agree, the ingress filtering stuff should be dealt with in parallel. In an effort to be constructive, here are some further ideas about how to limit the damage from the packet reflection which can be caused by malicious use of unrestricted HAOs. 1) The correspondent node can strictly limit the number of care-of addresses available to any one home address (to, say, one or two). It _could_ even do so for the number of care-of addresses assignable to home addresses on a particular subnet, if we wanted to go to the trouble of putting the prefix length back into the Binding Update. => I don't believe in defense at CNs with triangular routing, I am afraid this will catch only buggy attacks. 2) The ingress filtering router can strictly limit the number of HAOs transmitted from any particular subnet prefix per unit time (*). => this can be useful in order to detect abnormal situations (i.e. attacks) but not to fix them (it is too hard to distinguish between legitimate and fake HAOs so the system can be itself the target of a DoS attack). The best passive protection is BU/BA snooping (all interesting parameters are in the exchange and BAs are easy to check) but if it is effective when possible (no too much ciphered fields, snooping devices in the path), I personnaly prefer more active schemes (mainly because they give far better proofs in the legal meaning... but I believe firewall people prefer snooping which is more common in their context). BTW I've interpreted your statement as the number of *different* HAOs transmitted... These are the first things that come to mind, and I believe they are quite simple to implement. (1) certainly is. Plus, I believe that, for the purposes of handling HAOs, we should begin to distinguish between home addresses that have security associations established with the correspondent node, and home addresses that do not. It is the latter variety that need to have the strict numerical limitations. => with current specs a MN must have a home registration with is always acknowledged so BU/BA snooping is the next step of your idea. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 20 09:50: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 JAA11092 for ; Sun, 20 Jan 2002 09:50: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 HAA05733; Sun, 20 Jan 2002 07:50: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 GAA05382; Sun, 20 Jan 2002 06:50: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 g0KEmf2Q013571 for ; Sun, 20 Jan 2002 06:48:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KEmfED013570 for mobile-ip-dist; Sun, 20 Jan 2002 06:48: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 g0KEmc2Q013563 for ; Sun, 20 Jan 2002 06:48:38 -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 GAA21911 for ; Sun, 20 Jan 2002 06:48:44 -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 HAA24078 for ; Sun, 20 Jan 2002 07:48:43 -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 g0KEme530358; Sun, 20 Jan 2002 15:48: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 PAA23392; Sun, 20 Jan 2002 15:48:41 +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 g0KEmeQ75485; Sun, 20 Jan 2002 15:48:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201201448.g0KEmeQ75485@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Sat, 19 Jan 2002 19:50:00 +0200. Date: Sun, 20 Jan 2002 15:48:40 +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: Wrong. Ingress filtering done with non-RPF mechanisms does not need to intelligent. => this depends on what is wanted: if filtering at the address level (i.e. not only at the prefix level) is required (and there are good reasons to do it when it is possible) then the access-list system has to be intelligent (i.e. static rules are not enough). By default we can consider that firewalls are intelligent so there is no problem to ask them a bit more when we don't rely on the extras. Please note this si more than traditional local ingress filtering, is a reply to more than random source address spoofing and usually is implemented with the help of the network access control system. A final remark: source address spoofing in the same prefix can become a real problem with IPv6 (just rename it interface ID spoofing...). Regards Francis.Dupont@enst-bretagne.fr PS: this point is exactly like network access control and AAA, the first can be needed, not the second but it will be very fine to get the second. From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 20 10:23: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 KAA11682 for ; Sun, 20 Jan 2002 10:23:09 -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 HAA03061; Sun, 20 Jan 2002 07:22:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25713; Sun, 20 Jan 2002 07:22:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KFLH2Q013752 for ; Sun, 20 Jan 2002 07:21:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KFLH9a013751 for mobile-ip-dist; Sun, 20 Jan 2002 07:21:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KFLA2Q013733; Sun, 20 Jan 2002 07:21: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 HAA27059; Sun, 20 Jan 2002 07:21:14 -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 IAA11033; Sun, 20 Jan 2002 08:21:13 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0KFLB532350; Sun, 20 Jan 2002 16:21: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 QAA23826; Sun, 20 Jan 2002 16:21: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 g0KFLBQ75609; Sun, 20 Jan 2002 16:21:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201201521.g0KFLBQ75609@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko , Charlie Perkins , ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Sat, 19 Jan 2002 21:51:57 +0200. Date: Sun, 20 Jan 2002 16:21: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: You're making assumptions here: - every packet filter in the internet can => every firewall 1) recognize HAO 2) parse it, and 3) match against the address in it This does not hold *at all*. => this holds for every decent firewalls: they do URL filtering and you are trying to say they don't know how to dig into a packet? I doubt very much even a half of IPv6 packet filters, router access-lists etc. would do this in a few years' time => I assume we'll get at least the same level of technology which is used today near everywhere for IPv4. The easiest method, which *might* be deployable soonish would be a check whether HAO exists or not (1) above), and drop all packets with it. However, this would kill all the use for HAO too; not good enough. => I agree that today situation for HAO is "ignore all" and the next step is "drop all". I expect a third step (I am optimistic (:-) and this is a problem of balance between mobility industry and firewall industry). Iff 3) above holds, every site which does not have mobile nodes of its own can be protected. => yes, to know there is no binding at all is a perfect knowledge of current bindings (:-). (If it has MN's, state/AAA or more lax security for the addresses is required.) => please use "network access control" in place of AAA because some FUD is based on the confusion between network access control and AAA infrastructure. In my opinion, this is an unrealistic requirement. => what is unrealistic is to believe firewalls are not commonly used... > anti-spoofing stuff... See above. => anti-spoofing is different because the simple case is "no HA" which should be far more common than "no MN". The way to use firewalls is more usual too and gives more freedom. > => if your packet filter doesn't already do that, change it ASAP. I don't know of any alternative. => I know at least one but it is not yet commercially available (I can privately give some pointers). I believe there are others (ready but not available). Instead, I was advocating stronger checks in the end-nodes, thus eliminating the need for firewall security checks except for those 1% who really want to go and build the AAA system to get the extra control and => a network access control please, no the AAA system security. => this doesn't work: if we kill the triangular routing following your suggestion there will be no exception at all. > so I believe there are at least two firewall expert teams which already > managed how to deal with HAOs... Wrong assumption. => please let Charly Perkins (or these persons) answer. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 20 10:24:51 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11721 for ; Sun, 20 Jan 2002 10:24: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 HAA03325; Sun, 20 Jan 2002 07:24:15 -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 HAA26254; Sun, 20 Jan 2002 07:24: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 g0KFNR2Q013830 for ; Sun, 20 Jan 2002 07:23:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KFNRYk013829 for mobile-ip-dist; Sun, 20 Jan 2002 07:23: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 g0KFNO2Q013820 for ; Sun, 20 Jan 2002 07:23:24 -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 HAA26020 for ; Sun, 20 Jan 2002 07:23:28 -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 IAA19206 for ; Sun, 20 Jan 2002 08:23:27 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0KFNQu05241; Sun, 20 Jan 2002 17:23:26 +0200 Date: Sun, 20 Jan 2002 17:23:25 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <200201201448.g0KEmeQ75485@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Sun, 20 Jan 2002, Francis Dupont wrote: > Wrong. Ingress filtering done with non-RPF mechanisms does not need to > intelligent. > > => this depends on what is wanted: if filtering at the address level > (i.e. not only at the prefix level) is required (and there are good > reasons to do it when it is possible) then the access-list system > has to be intelligent (i.e. static rules are not enough). > By default we can consider that firewalls are intelligent so > there is no problem to ask them a bit more when we don't rely on > the extras. Some might want this, some not; I don't require intelligence and complexity from a firewall/packet filter. The point is, there are three kinds of mechanisms: 1) ingress filtering done with RPF-like -mechanisms 2) ingress filtering done with access lists 3) "intelligent ingress filtering" Additionally, any of these can be done either in a firewall or a router. (3) in a router might be a little tricky though.) You're neglecting 2) and assuming everyone who doesn't use 1) will want to have the extra pains of 3); this is not the case. -- 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 Sun Jan 20 10:42: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 KAA11930 for ; Sun, 20 Jan 2002 10:42:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05052; Sun, 20 Jan 2002 07:42:08 -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 HAA29551; Sun, 20 Jan 2002 07:42:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KFfE2Q013954 for ; Sun, 20 Jan 2002 07:41:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KFfE0g013953 for mobile-ip-dist; Sun, 20 Jan 2002 07:41:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0KFfA2Q013946 for ; Sun, 20 Jan 2002 07:41:10 -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 HAA26280 for ; Sun, 20 Jan 2002 07:41:15 -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 HAA02821 for ; Sun, 20 Jan 2002 07:41:14 -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 g0KFfC500947; Sun, 20 Jan 2002 16:41: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 QAA24197; Sun, 20 Jan 2002 16:41:13 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0KFfCQ75821; Sun, 20 Jan 2002 16:41:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201201541.g0KFfCQ75821@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark , jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Sun, 20 Jan 2002 17:23:25 +0200. Date: Sun, 20 Jan 2002 16:41: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: > => this depends on what is wanted: if filtering at the address level > (i.e. not only at the prefix level) is required (and there are good > reasons to do it when it is possible) then the access-list system > has to be intelligent (i.e. static rules are not enough). > By default we can consider that firewalls are intelligent so > there is no problem to ask them a bit more when we don't rely on > the extras. Some might want this, some not; I don't require intelligence and complexity from a firewall/packet filter. => intelligence and complexity is the price of security (or you lose a lot of features). The point is, there are three kinds of mechanisms: 1) ingress filtering done with RPF-like -mechanisms 2) ingress filtering done with access lists 3) "intelligent ingress filtering" Additionally, any of these can be done either in a firewall or a router. (3) in a router might be a little tricky though.) => (3) is usually out of the scope of a router (example: (3) is not standard IOS, i.e. IOS without the "firewall feature set"). You're neglecting 2) and assuming everyone who doesn't use 1) will want to have the extra pains of 3); this is not the case. => no, I assume that most people using or not (2) have a firewall which can provide (3) with "most" is in fact "enough to make HAO spoofing unattractive". If you object can you provide numbers about people using (2) (not so high, it seems that many people rely on their ISP to do ingress filtering :-) and about people using firewalls (both for IPv4 for course). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 20 18:35: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 SAA17464 for ; Sun, 20 Jan 2002 18:35: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 QAA28464; Sun, 20 Jan 2002 16:35: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 PAA10326; Sun, 20 Jan 2002 15: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 g0KNY02Q014344 for ; Sun, 20 Jan 2002 15:34:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0KNY0tH014343 for mobile-ip-dist; Sun, 20 Jan 2002 15:34: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 g0KNXv2Q014336 for ; Sun, 20 Jan 2002 15:33:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27232 for ; Sun, 20 Jan 2002 15:34:02 -0800 (PST) Received: from acmex.gatech.edu (acmex.gatech.edu [130.207.165.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02962 for ; Sun, 20 Jan 2002 15:34:01 -0800 (PST) Received: by acmex.gatech.edu (Postfix, from userid 21503) id 3EF821DFAF; Sun, 20 Jan 2002 18:34:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by acmex.gatech.edu (Postfix) with ESMTP id 383AF1F175 for ; Sun, 20 Jan 2002 18:34:00 -0500 (EST) Date: Sun, 20 Jan 2002 18:34:00 -0500 (EST) From: Young-Jun Lee To: IETF Mobile IP WG Subject: [mobile-ip] Multicast routing issue in MIP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think multicasting in mip is also an impportant issue. RFC2002 mentions multicasting simply thru only one page. But I could not find any discussion about that issue in this working group. Is this because there are lots of other important issues that wg should focus on? Or should this issue be handled by other wg? I'd appreciate it if anybody would explain about this situation. Regards, Young-Jun Lee Georgia Institute of Technology From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 20 19:56:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18022 for ; Sun, 20 Jan 2002 19:56: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 RAA14827; Sun, 20 Jan 2002 17:55:01 -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 QAA12959; Sun, 20 Jan 2002 16:54: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 g0L0rW2Q014480 for ; Sun, 20 Jan 2002 16:53:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0L0rWeG014479 for mobile-ip-dist; Sun, 20 Jan 2002 16:53: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 g0L0rT2Q014472 for ; Sun, 20 Jan 2002 16:53:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06448 for ; Sun, 20 Jan 2002 16:53:35 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25134 for ; Sun, 20 Jan 2002 17:53:34 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Sun, 20 Jan 2002 16:53:34 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 20 Jan 2002 16:53:33 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 20 Jan 2002 16:53:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 20 Jan 2002 16:53:33 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Sun, 20 Jan 2002 16:51:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Multicast routing issue in MIP Date: Sun, 20 Jan 2002 16:51:21 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB7F02@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [mobile-ip] Multicast routing issue in MIP Thread-Index: AcGiCvp/K8Bj3+hESg+Mes+wP6JrlgACiP6g From: "Dave Thaler" To: X-OriginalArrivalTime: 21 Jan 2002 00:51:24.0239 (UTC) FILETIME=[C00105F0:01C1A215] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0L0rT2Q014473 Sender: owner-mobile-ip@sunroof.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 After announcing it at the MIP WG, I gave a presentation in the MAGMA WG at the IETF in SLC on this topic. It looks like the proceedings aren't online yet. If you want a copy of my slides before they appear on the ietf site, let me know. In short: there are issues. The multicast language currently in the MIPv6 spec should be ignored. There are a couple of possible solutions, ranging from inefficient (e.g., always tunneling via Home Agent) to complex (requiring a slight change to correspondent node behavior). -Dave > -----Original Message----- > From: Young-Jun Lee [mailto:gte393q@prism.gatech.edu] > Sent: Sunday, January 20, 2002 3:34 PM > To: IETF Mobile IP WG > Subject: [mobile-ip] Multicast routing issue in MIP > > I think multicasting in mip is also an impportant issue. > RFC2002 mentions multicasting simply thru only one page. > But I could not find any discussion about that issue in this > working group. > Is this because there are lots of other important issues that wg should > focus on? > Or should this issue be handled by other wg? > I'd appreciate it if anybody would explain about this situation. > > Regards, > > Young-Jun Lee > Georgia Institute of Technology From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 04:31:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03263 for ; Mon, 21 Jan 2002 04:31:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19310; Mon, 21 Jan 2002 02:31: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 BAA18904; Mon, 21 Jan 2002 01:31: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 g0L9U72Q015111 for ; Mon, 21 Jan 2002 01:30:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0L9U76E015110 for mobile-ip-dist; Mon, 21 Jan 2002 01:30: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 g0L9U42Q015103 for ; Mon, 21 Jan 2002 01:30: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 BAA18707 for ; Mon, 21 Jan 2002 01:30:09 -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 BAA01714 for ; Mon, 21 Jan 2002 01:30:08 -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 g0L9U6504776 for ; Mon, 21 Jan 2002 10:30:06 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA03411 for ; Mon, 21 Jan 2002 10:30:06 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0L9U2Q83399 for ; Mon, 21 Jan 2002 10:30:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201210930.g0L9U2Q83399@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Multicast routing issue in MIP In-reply-to: Your message of Sun, 20 Jan 2002 16:51:21 PST. <2E33960095B58E40A4D3345AB9F65EC102DB7F02@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 21 Jan 2002 10:30:02 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: In short: there are issues. The multicast language currently in the MIPv6 spec should be ignored. There are a couple of possible solutions, ranging from inefficient (e.g., always tunneling via Home Agent) to complex (requiring a slight change to correspondent node behavior). => I disagree about the inefficiency of "always tunneling via Home Agent". In some cases this is obviously the best solution, for instance when all receivers are in the home domain (if a not-global scoped address is used, this can be the only solution). I prefer "potentially inefficient". Regards Francis.Dupont@enst-bretagne.fr PS: there are some considerations related to triangular routing too... From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 04:47:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03401 for ; Mon, 21 Jan 2002 04:47:24 -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 CAA26583; Mon, 21 Jan 2002 02:46:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21661; Mon, 21 Jan 2002 01:46:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0L9jT2Q015243 for ; Mon, 21 Jan 2002 01:45:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0L9jTS5015242 for mobile-ip-dist; Mon, 21 Jan 2002 01:45:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0L9jK2Q015227; Mon, 21 Jan 2002 01:45:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0L9jIF06348; Mon, 21 Jan 2002 10:45:19 +0100 (MET) Date: Mon, 21 Jan 2002 10:42:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201181711.g0IHBdQ66006@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: > No, but the specification of MIPv6 should wait until the ingress > filtering > part is specified. > > => I don't see why? Or do you argue that the ingress filtering part > is impossible or very long to specify (obviously not)? The purpose > to move this thread to the IPv6 WG mailing-list is just to fix it > in parallel. It's just that I haven't seen credible solution to distributed ingress filtering of packets with HAO that doesn't resort to have a global AAA infrastructure to solve the hard problem. I personally think we need solutions that don't required additional infrastcuture. > That is all the IETF need to worry about. > > => I disagree, the IETF need to worry about holes in the set of > standards track RFCs we have already issued (the RFCs) and missed (holes). > (this should not happen but we know it's happened) Sure, in addition to make sure that new stuff doesn't have holes we either need to fix or deprecate existing stuff with security holes. I don't think I said anything to the contrary. > For the IETF I think this means that we should not issue a proposed > standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). > > => I believe you'll have the same opinion about BU security too (i.e. > byebye RR :-). I don't understand the point and I don't understand the joke. Could you be more explicit? > If we want to go this path I think we need a community supported > > => supported = saying this is the solution or > supported = have implemented it or > supported = have deployed it > First is fine, second is possible (MIPv6 people will put pressure on > firewall people, IMHO firewall people need to be more aware of IPv6 > in general). The last one is out of the scope of the IETF. If youn read the whole sentence before interjecting the comments (it's below) you'll see it was about an RFC. BCP and Proposed standards are not required to be implemented and/or deployed in order to be publishes as such. > ingress filtering RFC (BCP or standards track) that handles HAO no > later than when MIPv6 becomes Proposed Standard. > > =. can I translate your argument in the network access control for HAO > documents should be available (or enough stable) before the MIPv6 one > in the same state? Yes, this is what I said several times now. No PS for MIPv6 with a security hole in my personal opinion. Means that a PS or BCP smart ingress filtering (set of) RFC need to exist at that time as MIPv6 becomes PS. > This is unrealistic for DIAMETER (because of the > AAA state), easy for RADIUS and out of the scope of the IETF for > firewalls (I am not a firewall expert, I only know that many commercial > firewalls have a network access control module... in fact the whole > idea is from a team with some firewall persons so I know the whole > thing was put in a commercial firewall more than two years ago but > the @#$... people don't believe there is a market, grr...). Above you said it wouldn't delay MIPv6 to do this (because of it being done in parallel) but now you seem to say it would delay it because of various reaons. So you seem to agree with me about the delay? > PS: we are losing time: keep or kill the triangular routing? I say: Remove the unauthenticated and unauthorized use of HAO which has the effect that tringular routing isn't an option. The only options are bidirectional tunneling through the HA and route optimization. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 05:09: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 FAA03697 for ; Mon, 21 Jan 2002 05:09: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 CAA10761; Mon, 21 Jan 2002 02:09:22 -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 CAA22993; Mon, 21 Jan 2002 02:09: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 g0LA8K2Q015337 for ; Mon, 21 Jan 2002 02:08:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LA8KqT015336 for mobile-ip-dist; Mon, 21 Jan 2002 02:08:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LA8G2Q015329 for ; Mon, 21 Jan 2002 02:08:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22831 for ; Mon, 21 Jan 2002 02:08:22 -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 DAA04812 for ; Mon, 21 Jan 2002 03:08:19 -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 FAA03604; Mon, 21 Jan 2002 05:08:15 -0500 (EST) Message-Id: <200201211008.FAA03604@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-00.txt Date: Mon, 21 Jan 2002 05:08:15 -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-00.txt Pages : 23 Date : 18-Jan-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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-nat-traversal-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020118134340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-nat-traversal-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-nat-traversal-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020118134340.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 06:36: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 GAA05830 for ; Mon, 21 Jan 2002 06:36: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 EAA21027; Mon, 21 Jan 2002 04:36:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14517; Mon, 21 Jan 2002 03: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 g0LBYW2Q015457 for ; Mon, 21 Jan 2002 03:34:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LBYVNk015456 for mobile-ip-dist; Mon, 21 Jan 2002 03:34:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LBYP2Q015441; Mon, 21 Jan 2002 03:34:25 -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 DAA25217; Mon, 21 Jan 2002 03:34:29 -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 DAA13052; Mon, 21 Jan 2002 03:34:28 -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 g0LBYO521765; Mon, 21 Jan 2002 12:34:24 +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 MAA06946; Mon, 21 Jan 2002 12:34:24 +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 g0LBYOQ84481; Mon, 21 Jan 2002 12:34:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201211134.g0LBYOQ84481@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Mon, 21 Jan 2002 10:42:08 +0100. Date: Mon, 21 Jan 2002 12:34:24 +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's just that I haven't seen credible solution to distributed ingress filtering of packets with HAO that doesn't resort to have a global AAA infrastructure to solve the hard problem. => so you'll be very happy when you'll read my draft which relies only on *enough* of any kind of network access control (even passive one, aka BU/BA snooping which can have the favour of firewall folk). I personally think we need solutions that don't required additional infrastcuture. => we agree. > That is all the IETF need to worry about. > > => I disagree, the IETF need to worry about holes in the set of > standards track RFCs we have already issued (the RFCs) and missed (holes). > (this should not happen but we know it's happened) Sure, in addition to make sure that new stuff doesn't have holes we either need to fix or deprecate existing stuff with security holes. I don't think I said anything to the contrary. => your statement could suggest the IETF doesn't need to worry about holes in already published standard track RFCs (we agree this is *not* the case). > For the IETF I think this means that we should not issue a proposed > standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). > > => I believe you'll have the same opinion about BU security too (i.e. > byebye RR :-). I don't understand the point and I don't understand the joke. Could you be more explicit? => RR is known to be a bit weak from a security point of view so as a MITM vulnerability can be considered as a hole, your opinion should be in disfavour of RR, isn't it? (smile again) > If we want to go this path I think we need a community supported > > => supported = saying this is the solution or > supported = have implemented it or > supported = have deployed it > First is fine, second is possible (MIPv6 people will put pressure on > firewall people, IMHO firewall people need to be more aware of IPv6 > in general). The last one is out of the scope of the IETF. If youn read the whole sentence before interjecting the comments (it's below) you'll see it was about an RFC. BCP and Proposed standards are not required to be implemented and/or deployed in order to be publishes as such. => I apologize: I was afraid of overinterpretations of the term supported. > =< can I translate your argument in the network access control for HAO > documents should be available (or enough stable) before the MIPv6 one > in the same state? Yes, this is what I said several times now. No PS for MIPv6 with a security hole in my personal opinion. Means that a PS or BCP smart ingress filtering (set of) RFC needs to exist at that time as MIPv6 becomes PS. => thanks, now there is no possible ambiguities about your opinion. BTW I fully agree with you about this point. > This is unrealistic for DIAMETER (because of the > AAA state), easy for RADIUS and out of the scope of the IETF for > firewalls (I am not a firewall expert, I only know that many commercial > firewalls have a network access control module... in fact the whole > idea is from a team with some firewall persons so I know the whole > thing was put in a commercial firewall more than two years ago but > the @#$... people don't believe there is a market, grr...). Above you said it wouldn't delay MIPv6 to do this (because of it being done in parallel) but now you seem to say it would delay it because of various reasons. => where are the reasons (in document publication, cf above) of delays? This can only be about the connection between network access controls and firewalls: - there is no IETF protocol about this - it seems the current consensus is this is not in the IETF scope - this exists, in general in the purpose to be applied to remote and/or mobile users, for instance http://www.evidian.com/accessmaster/netwall/features.htm#Broad In many AAA and PANA drafts (including mine :-), there are references about when the terminal is authentified the firewall is opened for it (i.e. authorization is "to access to the Internet"). I can't find details about how this is done, can some firewall folk help us? (if you know some, can you forward this to them) So you seem to agree with me about the delay? => one thing we agree is we don't want delay. > PS: we are losing time: keep or kill the triangular routing? I say: Remove the unauthenticated and unauthorized use of HAO which has the effect that tringular routing isn't an option. The only options are bidirectional tunneling through the HA and route optimization. => so we disagree only about the necessity to remove the unauthenticated and unauthorized use of HAO (my argument is there is no such necessity about source address themselves). Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 08:33: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 IAA09137 for ; Mon, 21 Jan 2002 08:33:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09050; Mon, 21 Jan 2002 06:32:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11529; Mon, 21 Jan 2002 05:32: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 g0LDVN2Q015736 for ; Mon, 21 Jan 2002 05:31:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LDVNGW015735 for mobile-ip-dist; Mon, 21 Jan 2002 05: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LDVE2Q015720; Mon, 21 Jan 2002 05:31:15 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LDVEF25009; Mon, 21 Jan 2002 14:31:14 +0100 (MET) Date: Mon, 21 Jan 2002 14:28:02 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201211134.g0LBYOQ84481@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => so you'll be very happy when you'll read my draft which relies only > on *enough* of any kind of network access control (even passive one, > aka BU/BA snooping which can have the favour of firewall folk). I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume that the architecture only needs to support ingress at one place. I think we need to allow ingress filtering to take place at multiple "levels" such at each college dorm room router, between the college and the ISP, between leaf ISPs and transits, etc. I don't see any difference between saying - we can trust the access network to do ingress filtering - we can trust the host to not use bogus source addresses Fundamentally it is an issue about trust boundaries. If an ISP doesn't do ingress filtering themselves the ISPs that provide service to it might want to filter. The architecture should not prevent such flexibility. > > => I believe you'll have the same opinion about BU security too (i.e. > > byebye RR :-). > > I don't understand the point and I don't understand the joke. > Could you be more explicit? > > => RR is known to be a bit weak from a security point of view so > as a MITM vulnerability can be considered as a hole, your opinion should > be in disfavour of RR, isn't it? (smile again) I'm answering the serious underlying question/assumption: You seem to have not read the abstract in the BU3WAY document. I never claimed it was the best approach. In fact, if CGA was free (no IPR concerns and no performance concerns for the PK operations) doing CGA (in combination with RR to deal with certain DoS attacks) would be the obvious answer IMHO. > => where are the reasons (in document publication, cf above) of delays? > This can only be about the connection between network access controls > and firewalls: > - there is no IETF protocol about this > - it seems the current consensus is this is not in the IETF scope > - this exists, in general in the purpose to be applied to remote > and/or mobile users, for instance > http://www.evidian.com/accessmaster/netwall/features.htm#Broad > In many AAA and PANA drafts (including mine :-), there are references > about when the terminal is authentified the firewall is opened for it > (i.e. authorization is "to access to the Internet"). I can't find > details about how this is done, can some firewall folk help us? > (if you know some, can you forward this to them) If we feel that we (the IETF) can't produce documents that say how firewalls should behave then it would seem foolish for us to produce standards that assume certain behavior in firewalls. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 13:39: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 NAA19612 for ; Mon, 21 Jan 2002 13:39: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 KAA04081; Mon, 21 Jan 2002 10:38:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14120; Mon, 21 Jan 2002 10:38: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 g0LIbT2Q016276 for ; Mon, 21 Jan 2002 10:37:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LIbTRH016275 for mobile-ip-dist; Mon, 21 Jan 2002 10:37:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LIbN2Q016260; Mon, 21 Jan 2002 10:37:23 -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 KAA09855; Mon, 21 Jan 2002 10:37:29 -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 LAA28533; Mon, 21 Jan 2002 11:37:27 -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 g0LIbM506566; Mon, 21 Jan 2002 19:37: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 TAA19403; Mon, 21 Jan 2002 19:37:23 +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 g0LIbMQ87908; Mon, 21 Jan 2002 19:37:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-reply-to: Your message of Mon, 21 Jan 2002 14:28:02 +0100. Date: Mon, 21 Jan 2002 19:37: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: > => so you'll be very happy when you'll read my draft which relies only > on *enough* of any kind of network access control (even passive one, > aka BU/BA snooping which can have the favour of firewall folk). I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to assume that the architecture only needs to support ingress at one place. => this is a constraint: active network access control is usually done at one place. I don't see any difference between saying - we can trust the access network to do ingress filtering - we can trust the host to not use bogus source addresses => it seems you have a very bad feeling of your ISP (:-). Fundamentally it is an issue about trust boundaries. => I fully agree: this is a trust/responsability issue so I am not surprised when this can be described with AAA terms (for instance this is about "the authorization to use this home address"). The architecture should not prevent such flexibility. => what does prevent flexibility is the only current technical concrete form of trust/responsability is network access control systems. I'm answering the serious underlying question/assumption: You seem to have not read the abstract in the BU3WAY document. => IMHO BU3WAY is an attempt to get the faster/cheaper security scheme for BUs (the opposite of IKE+AH). I never claimed it was the best approach. => so I've put again a smile. In fact, if CGA was free (no IPR concerns and no performance concerns for the PK operations) doing CGA (in combination with RR to deal with certain DoS attacks) would be the obvious answer IMHO. => if CGA was free we have a lot of better solutions to many problems (including the HAO vs ingress filtering one) but it has both IPR and performance concerns... If we feel that we (the IETF) can't produce documents that say how firewalls should behave => this is about details of communication between network access controls and firewalls, not about firewall behavior. BTW my draft is essentially a firewall behavior specification. then it would seem foolish for us to produce standards that assume certain behavior in firewalls. => firewall people were not enough (? :-) foolish to wait for us to specify how network access controls and firewalls should communicate. More seriously I've looked at what is available: - it seems a lot of firewalls support this kind of feature for remote/mobile access (all the commercial firewalls still in the market) - IPF (well known open source firewall) has the auth/preauth actions which do exactly what is needed (unfortunately the IPv6 support of IPF is questionable and has not (*yet*) HAO support.) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 14:25: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 OAA20941 for ; Mon, 21 Jan 2002 14:25: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 LAA13252; Mon, 21 Jan 2002 11:25:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19121; Mon, 21 Jan 2002 11:24: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 g0LJNx2Q016441 for ; Mon, 21 Jan 2002 11:23:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LJNxDJ016440 for mobile-ip-dist; Mon, 21 Jan 2002 11:23:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LJNt2Q016433 for ; Mon, 21 Jan 2002 11:23:56 -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 LAA04265 for ; Mon, 21 Jan 2002 11:24:00 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16236 for ; Mon, 21 Jan 2002 12:24:00 -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 g0LJNxA08117 for ; Mon, 21 Jan 2002 11:23:59 -0800 (PST) Received: from cisco.com (alpesh-u5.cisco.com [128.107.162.126]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABK81668; Mon, 21 Jan 2002 11:22:12 -0800 (PST) Message-ID: <3C4C6A72.C11B6288@cisco.com> Date: Mon, 21 Jan 2002 11:22:26 -0800 From: Alpesh Patel X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion References: <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharath, Just to let you know, the code where I thought would be a problem was an oversight. That is the reason, I just asked if it was tested. I think Roy added this code, but would wait for him to respond -a Sharath Veldanda wrote: > Alpesh, > > Do you have the DDTS number handy ?? > > -S > > >Date: Mon, 21 Jan 2002 11:01:07 -0800 > >From: Alpesh Patel > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: mobileip-coders@cisco.com, mobileip-dt@cisco.com > >Subject: Questions about ipmobile_AddAddrTypeExt() in ipm_standby.c > >Content-Transfer-Encoding: 7bit > > > >Team, > > > >Wondering if the ddts that added the code related to the function > >ipmobile_AddAddrTypeExt() was tested /regression tested. > > > >If it was tested, the owner needs to work with a DT to add it into > >regression suite. > > > >-a > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 14:47: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 OAA21712 for ; Mon, 21 Jan 2002 14:47: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 MAA20466; Mon, 21 Jan 2002 12:36: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 LAA20551; Mon, 21 Jan 2002 11:36: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 g0LJZD2Q016504 for ; Mon, 21 Jan 2002 11:35:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LJZDUA016503 for mobile-ip-dist; Mon, 21 Jan 2002 11:35: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 g0LJZA2Q016496 for ; Mon, 21 Jan 2002 11:35: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 LAA09690 for ; Mon, 21 Jan 2002 11:35:14 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26162 for ; Mon, 21 Jan 2002 12:35:14 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0LJZCo20056 for ; Mon, 21 Jan 2002 11:35: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 AAS34722; Mon, 21 Jan 2002 11:34:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA18423; Mon, 21 Jan 2002 11:35:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15436.28017.39358.549788@thomasm-u1.cisco.com> Date: Mon, 21 Jan 2002 11:35:13 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <3C4C6A72.C11B6288@cisco.com> References: <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> <3C4C6A72.C11B6288@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alpesh Patel writes: [] Yet another oops. Can we *please* change this to not be reply-to: mobile-ip? Who is the list owner??? Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 15:27: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 PAA22991 for ; Mon, 21 Jan 2002 15:27: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 MAA24456; Mon, 21 Jan 2002 12:26:38 -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 MAA26819; Mon, 21 Jan 2002 12:26:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LKPO2Q016658 for ; Mon, 21 Jan 2002 12:25:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LKPOcx016657 for mobile-ip-dist; Mon, 21 Jan 2002 12:25:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LKPF2Q016642; Mon, 21 Jan 2002 12:25:16 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LKP8F27454; Mon, 21 Jan 2002 21:25:09 +0100 (MET) Date: Mon, 21 Jan 2002 21:21:52 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: Francis Dupont Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201211837.g0LIbMQ87908@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I did read draft-dupont-ipv6-ingress-filtering-00.txt and it seems to > assume > that the architecture only needs to support ingress at one place. > > => this is a constraint: active network access control is usually done > at one place. I wasn't talking about network access control - I was talking about ingress filtering. While e.g. an ISP/subscriber relationship might have some network access control that isn't the only place ingress filtering might need to be done. > I don't see any difference between saying > - we can trust the access network to do ingress filtering > - we can trust the host to not use bogus source addresses > > => it seems you have a very bad feeling of your ISP (:-) Yes I do, but I don't trust the whole edge around the whole Internet. There probably exists at least one ISP on the planet that will allow any source address in the packets sent by their subscribers. Thus it needs to be possible to ingress filtering at other places than just the ISP/subscriber boundary. > => what does prevent flexibility is the only current technical > concrete form of trust/responsability is network access control systems. Sorry, wrog subject. We were talking about ingress filtering and not network access control I think :-) Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 15:39: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 PAA23399 for ; Mon, 21 Jan 2002 15:39:04 -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 NAA12637; Mon, 21 Jan 2002 13:38: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 MAA28743; Mon, 21 Jan 2002 12:38: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 g0LKbc2Q016729 for ; Mon, 21 Jan 2002 12:37:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LKbcZB016728 for mobile-ip-dist; Mon, 21 Jan 2002 12:37: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 g0LKbZ2Q016721 for ; Mon, 21 Jan 2002 12:37:35 -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 MAA01516 for ; Mon, 21 Jan 2002 12:37:40 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27969 for ; Mon, 21 Jan 2002 12:37:39 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0LKbb818297 for ; Mon, 21 Jan 2002 22:37:37 +0200 Date: Mon, 21 Jan 2002 22:37:37 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion In-Reply-To: <15436.28017.39358.549788@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 21 Jan 2002, Michael Thomas wrote: > Yet another oops. Can we *please* change this to > not be reply-to: mobile-ip? Who is the list owner??? I fail to see how it would have changed the situation here? It seems more likely someone had a bad email shortcut. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 17:08: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 RAA26593 for ; Mon, 21 Jan 2002 17:08:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12901; Mon, 21 Jan 2002 14:07:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10947; Mon, 21 Jan 2002 14:07: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 g0LM6Q2Q016986 for ; Mon, 21 Jan 2002 14:06:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LM6QrD016985 for mobile-ip-dist; Mon, 21 Jan 2002 14: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LM6N2Q016978 for ; Mon, 21 Jan 2002 14:06:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10713 for ; Mon, 21 Jan 2002 14:06:29 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07563 for ; Mon, 21 Jan 2002 15:06:28 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA08969 for ; Mon, 21 Jan 2002 15:06:28 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA04656 for ; Mon, 21 Jan 2002 15:06:27 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Mon, 21 Jan 2002 16:06:26 -0600 Received: from test9.crm.mot.com.crm.mot.com (t_il01_b_slip6.corp.mot.com [199.2.172.36]) by thorgal.crm.mot.com (Postfix) with ESMTP id DEE0B2EC83; Mon, 21 Jan 2002 23:02:40 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Pekka Nikander , hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> From: Alexandru Petrescu Date: 21 Jan 2002 23:03:58 +0100 In-Reply-To: <3C385158.8010201@nomadiclab.com> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 30 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Pekka, I'm catching up with old mail. I certainly agree that the attack you presented is valid; however, I have one remark with respect to v4, see below. Pekka Nikander writes: > Discussion: > > This attack is not present in IPv4 since in this scenario the > attacker steals all traffic _beforehand_, and does not need to > be on the vulnerable path later when the communication session > is actually initiated. Thus, there is a potential class of > attackers that may be able to launch this attack but that could > not attack under the current IPv4 architecture. In the attack you describe, attacker is present either close to CN, to HA, or on the path between them. One thing that you don't seem to mention is that attacker must be able not only to listen to traffic but also to block traffic. I mean, more than just generating fake RR replies to CN, attacker must block CN's RR tests to reach the HA and HA's RR replies to reach CN; otherwise CN would end up with two RR replies (one valid and one faked) and could realize something is wrong. At an extreme, this equals attacker being able to physically tamper with underlying media or sit on a router in the path CN-HA. Now, in the v4 world, if the attacker can sit on an intermediate router or tamper with underlying media between two communicating parties, it can do about the same amount of damage. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 21 17:39:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27185 for ; Mon, 21 Jan 2002 17:39:45 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23874; Mon, 21 Jan 2002 15:39: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 OAA26374; Mon, 21 Jan 2002 14:39:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LMcA2Q017278 for ; Mon, 21 Jan 2002 14:38:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0LMc9u0017277 for mobile-ip-dist; Mon, 21 Jan 2002 14:38:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0LMc12Q017262; Mon, 21 Jan 2002 14:38:01 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0LMc0F02642; Mon, 21 Jan 2002 23:38:02 +0100 (MET) Date: Mon, 21 Jan 2002 23:34:38 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] How to move forward in the HAO & ingress filter discussion To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C470094.29B50022@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, > Phase one is basically requiring reverse tunneling for virtually all > mobility, killing route optimization, and probably along with it any > hope of QoS for many years. It means that nodes will typically not > receive packets containing the Home Address option, and thus the feature > will rust. I don't understand the meaning you assign to "basically" above. Phase 1 would allow either bidirectional tunneling or route optimization (in both directions). The thing it wouldn't allow is the triangle when packets from the MN go directly to the CN, but the other path is through the HA. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 22 02:19: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 CAA13065 for ; Tue, 22 Jan 2002 02:19:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26713; Tue, 22 Jan 2002 00:19:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04887; Mon, 21 Jan 2002 23:19:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M7IC2Q017866 for ; Mon, 21 Jan 2002 23:18:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0M7ICxQ017865 for mobile-ip-dist; Mon, 21 Jan 2002 23:18:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0M7I92Q017858 for ; Mon, 21 Jan 2002 23:18:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07190 for ; Mon, 21 Jan 2002 23:18:14 -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 AAA15534 for ; Tue, 22 Jan 2002 00:18:14 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 491ADA; Tue, 22 Jan 2002 09:19:12 +0200 (EET) Message-ID: <3C4D1222.9010308@nomadiclab.com> Date: Tue, 22 Jan 2002 09:17:54 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> 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, I wrote: >>This attack is not present in IPv4 since in this scenario the >>attacker steals all traffic _beforehand_, and does not need to >>be on the vulnerable path later when the communication session >>is actually initiated. Thus, there is a potential class of >>attackers that may be able to launch this attack but that could >>not attack under the current IPv4 architecture. Alexandru Petrescu wrote: > In the attack you describe, attacker is present either close to CN, to > HA, or on the path between them. One thing that you don't seem to > mention is that attacker must be able not only to listen to traffic > but also to block traffic. I mean, more than just generating fake RR > replies to CN, attacker must block CN's RR tests to reach the HA and > HA's RR replies to reach CN; otherwise CN would end up with two RR > replies (one valid and one faked) and could realize something is > wrong. At an extreme, this equals attacker being able to physically > tamper with underlying media or sit on a router in the path CN-HA. Not quite. Remember that HA is not necessarily active in the RR check. That is, at least in those RR schemes that I have considered, HA simply forwards the RR check packets to the MN, similar to any other packets going to the MN. Now, since we are considering a future attack here, the HA doesn't know where the MN is, and simply drops the RR packets. Making the HA more active would make the future attack more difficult, as you mention. But it doesnt' block those variants of the future attack where no real HA is needed, e.g. future reverse bombing. > Now, in the v4 world, if the attacker can sit on an intermediate > router or tamper with underlying media between two communicating > parties, it can do about the same amount of damage. In most senses yes. However, if it sits there *now* and then must move on, the situation is different. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 23 08:02: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 IAA06873 for ; Wed, 23 Jan 2002 08:02: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 FAA22586; Wed, 23 Jan 2002 05:01:59 -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 FAA12346; Wed, 23 Jan 2002 05:01: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 g0ND0m2Q019164 for ; Wed, 23 Jan 2002 05:00:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0ND0l0n019163 for mobile-ip-dist; Wed, 23 Jan 2002 05:00: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 g0ND0i2Q019156 for ; Wed, 23 Jan 2002 05:00: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 FAA29864 for ; Wed, 23 Jan 2002 05:00:50 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28051 for ; Wed, 23 Jan 2002 05:00:50 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id GAA09280 for ; Wed, 23 Jan 2002 06:00:49 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA24527 for ; Wed, 23 Jan 2002 06:00:49 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Wed, 23 Jan 2002 07:00:48 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 890D32EC83; Wed, 23 Jan 2002 13:56:59 +0100 (CET) X-Gnus-Agent-Meta-Information: mail nil To: mobile-ip@sunroof.eng.sun.com Cc: hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> From: Alexandru Petrescu Date: 23 Jan 2002 00:36:03 +0100 In-Reply-To: <3C4D1222.9010308@nomadiclab.com> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Lines: 25 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 Pekka and thank you for the reply. Please note that I think I understand the "future attack" you described and I mostly agree it's important, thanks for describing it. Only one side remark, again with respect to v4, see below. Pekka Nikander writes: > > Now, in the v4 world, if the attacker can sit on an intermediate > > router or tamper with underlying media between two communicating > > parties, it can do about the same amount of damage. > > > In most senses yes. However, if it sits there *now* and then must > move on, the situation is different. An attacker on an intermediate router on CN-HA path could add a static host route to MN through an alternate path. Just add it, save configuration and leave. Next time packets from CN destined to MN will go on the alternate path, without attacker being there, right? I think it is hardly and exaggeration to say that the probability of future attacks (as you described) is nonzero in today's v4 networks. Just my two cents, Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 23 08:27: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 IAA07654 for ; Wed, 23 Jan 2002 08:27: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 GAA28148; Wed, 23 Jan 2002 06:27: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 FAA28086; Wed, 23 Jan 2002 05:27: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 g0NDQG2Q019443 for ; Wed, 23 Jan 2002 05:26:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NDQFUI019442 for mobile-ip-dist; Wed, 23 Jan 2002 05:26: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 g0NDQC2Q019435 for ; Wed, 23 Jan 2002 05:26: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 FAA06178; Wed, 23 Jan 2002 05:26:18 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18123; Wed, 23 Jan 2002 06:26:01 -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 g0NDPxw26411; Wed, 23 Jan 2002 14:25:59 +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 g0NDPwr6015336; Wed, 23 Jan 2002 15:25:58 +0200 (EET) Message-ID: <3C4EB9E7.377A562D@lmf.ericsson.se> Date: Wed, 23 Jan 2002 15:25:59 +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, petrescu@crm.mot.com CC: hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> 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 >An attacker on an intermediate router on CN-HA path could add a static >host route to MN through an alternate path. Just add it, save >configuration and leave. Next time packets from CN destined to MN >will go on the alternate path, without attacker being there, right? Adding a static host route would require compromised router, is this what you were thinking? I think a more likely threat model is someone plugging in their laptop at an Ethernet somewhere, but not necessarily being able to get in to the routers. (Of course it is possible to get to the routers as well, just less likely.) Or perhaps you were thinking of ICMP redirect? I think in v4 the redirect function only allowed other on-link addresses as the new destination, hence this would apparently not work. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 23 09:05: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 JAA08782 for ; Wed, 23 Jan 2002 09:05:19 -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 HAA16939; Wed, 23 Jan 2002 07:04: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 GAA13987; Wed, 23 Jan 2002 06:04: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 g0NE3l2Q019525 for ; Wed, 23 Jan 2002 06:03:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NE3kBV019524 for mobile-ip-dist; Wed, 23 Jan 2002 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NE3h2Q019517 for ; Wed, 23 Jan 2002 06:03: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 GAA13793 for ; Wed, 23 Jan 2002 06:03:50 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03652 for ; Wed, 23 Jan 2002 07:03:48 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA22020 for ; Wed, 23 Jan 2002 07:03:48 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA09589 for ; Wed, 23 Jan 2002 07:03:47 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Wed, 23 Jan 2002 08:03:24 -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 35E312EC84; Wed, 23 Jan 2002 14:59:21 +0100 (CET) To: Jari Arkko Cc: mobile-ip@sunroof.eng.sun.com, hesham.soliman@era.ericsson.se, "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> From: Alexandru Petrescu Date: 23 Jan 2002 15:03:05 +0100 In-Reply-To: <3C4EB9E7.377A562D@lmf.ericsson.se> Message-Id: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alex Petrescu: > >An attacker on an intermediate router on CN-HA path could add a static > >host route to MN through an alternate path. Just add it, save > >configuration and leave. Next time packets from CN destined to MN > >will go on the alternate path, without attacker being there, right? > Jari Arkko writes: > Adding a static host route would require compromised router, > is this what you were thinking? Yes, I was thinking about compromised routers (or cutting cables). This is needed for the future attack to succeed against RR as described by Pekka. And if attacker can compromise routers or cut cables then he can launch a future attack in today's Internet too, by changing routing tables or putting his own router in between. Thus RR is no worse than v4. > I think a more likely threat model is someone plugging in > their laptop at an Ethernet somewhere, but not necessarily > being able to get in to the routers. (Of course it is possible > to get to the routers as well, just less likely.) This is indeed a more likely scenario. But without access to router, attacker can do less harm and is also in danger of being detected by its neighbours. Windows, Solaris and HP-UX already do that, I think. Besides, I do not think that the future attack against RR as described by Pekka is feasible only by plugging a laptop and using ND. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 23 09:26: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 JAA09966 for ; Wed, 23 Jan 2002 09:26:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29127; Wed, 23 Jan 2002 07:26: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 GAA18949; Wed, 23 Jan 2002 06:26: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 g0NEPZ2Q019794 for ; Wed, 23 Jan 2002 06:25:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NEPZPA019793 for mobile-ip-dist; Wed, 23 Jan 2002 06:25: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 g0NEPV2Q019786 for ; Wed, 23 Jan 2002 06:25:31 -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 GAA08731 for ; Wed, 23 Jan 2002 06:25:34 -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 GAA28838 for ; Wed, 23 Jan 2002 06:25:32 -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 JAA09722; Wed, 23 Jan 2002 09:24:29 -0500 (EST) Message-Id: <200201231424.JAA09722@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: magma@innovationslab.net, mobile-ip@sunroof.eng.sun.com, pim@catarina.usc.edu From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-jelger-mssmsv6-00.txt Date: Wed, 23 Jan 2002 09:24:21 -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 : Supporting Mobile SSM Sources for IPv6 (MSSMSv6) Author(s) : C. Jelger, T. Noel Filename : draft-jelger-mssmsv6-00.txt Pages : 11 Date : 22-Jan-02 Mobile IPv6 describes how a Mobile Node can change its point of attachment to the Internet. While MIPv6 focuses on unicast communications, it also proposes two basic mechanisms, known as bidirectionnal tunneling and remote subscription, to handle multicast communications with mobile members. In the mean time, the deployment of Source-Specific Multicast (SSM) is of great consideration, using the PIM-SM and MLDv2 protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jelger-mssmsv6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jelger-mssmsv6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jelger-mssmsv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020122153345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jelger-mssmsv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jelger-mssmsv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020122153345.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 23 15:40: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 PAA24587 for ; Wed, 23 Jan 2002 15:40: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 NAA15288; Wed, 23 Jan 2002 13:39:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08060; Wed, 23 Jan 2002 12:39: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 g0NKcM2Q020562 for ; Wed, 23 Jan 2002 12:38:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0NKcM3m020561 for mobile-ip-dist; Wed, 23 Jan 2002 12:38: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0NKcI2Q020554 for ; Wed, 23 Jan 2002 12:38:19 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0NKcHF09532 for ; Wed, 23 Jan 2002 21:38:18 +0100 (MET) Date: Wed, 23 Jan 2002 21:34:55 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Routing headers: design team recommendation To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The MIPv6 security design team is trying to resolve the issues around routing headers as used by MIPv6. This note specifies the design teams' motivation and current position. In order to move forward in an efficient manner it would be beneficial if responses could make it clear whether it is - a clarification (by putting CLARIFICATION: in the subject field), - an issue with a particular point (by putting ISSUE: in the subject field), - disagreement with the conclusion (by putting CONCLUSION: in the subject field) INTRODUCTION ============ There is background information on the security issues around MIPv6's use of the routing header in draft-savola-ipv6-rh-ha-security-01.txt. This note explores how to move forward on the routing header issue. Today in IPv4, firewalls block IPv4 source routes by default. The original motivation for this was that the TCP/IPv4 implementations reverse the source route received in a SYN and use it for the connection. This means that if source routes are allowed and hosts do any form of access control based on the source IP address (such as UNIX r* commands) they could be trivially spoofed. In an IPv6 world the situation is different. IPv6 nodes MUST NOT reverse an unauthenticated (with IPsec) routing header. Thus routing headers can't be used to spoof IP address based access control. (Of course, this doesn't mean that IP address based access control is good security - it is still a bad and grossly insufficient form of security - but folks might end up doing it when porting applications from IPv4 to IPv6). When there is an IPv6 firewall in place and it wants to prevent inside node A from communication externally (for a subset or all protocols/port numbers) while allowing inside node B to communicate externally (for those protocols/ports) it needs to ensure that a routing header can't be used to reach node A via node B (where B might be a host or a router). ALTERNATIVES ============ There seem to be three fundamentally different ways to approach this: 1. Make the inside nodes (hosts and routers) be "safe" enough in their handling of routing headers that the firewall can avoid specific checks on the presence of the routing header as well as the IP addresses contained in the RH. 2. Make the firewall understand the routing headers and filter based on their content. 3. Try to simplify things by not using Routing Headers for MIPv6 Make RH "safe enough" --------------------- The implications of approach #1 seem to be draconian for other use of the routing header. Not only can hosts not process routing headers and send the packet out (the same or a different interface), but internal routers cannot process routing headers either. If a router processes the routing headers then the above A/B scenario can be used to bypass the firewall policy for host A by source routing packets via the router B to A. Thus the implications of #1 are likely to be that all hosts and routers must not process any routing headers and forward the packet. The only routing header processing that would be allowed would be for a MN to process a RH where the packet doesn't leave the MN. Thus in effect routing headers would not be very useful for the initially intended purpose; they would only be useful for the MIPv6 usage. Make the firewall RH aware -------------------------- When looking at #2 we need to understand what type of filtering a firewall would need to have to prevent the A/B bypass while still allowing MIPv6 to function. There are several things needed for MIPv6 to function. We need to be able to allow: A. CNs inside the firewall need to be able to use RH to send to MNs outside the firewall. B. "visiting" MNs i.e. MNs who have a Home Address outside the firewall and a CoA inside the firewall. C. "local" MNs i.e. MNs where both the HoA and CoA are inside the firewall. [Note that in general allowing A, B, and/or C might be subject to site's firewall policy in general. Hence the use of "need to be able to allow" above.] A above doesn't cause any problems since allowing outbound RH through the firewall doesn't cause problems with the simple rules that A can't communicate externally. However, if the firewall rules are more complex as in A only being able to communicate with a specified external IP address then there are issues if that external node is a MN and A would use a routing header when sending to the MN. The case B looks like an external entity sending a packet with a destination being inside the firewall with the subsequent hop (in the RH) being outside of the firewall. Possible rules for a firewall to apply in approach #2 for packets inbound to the site would be: 1. If the destination address is not inside the firewall then the firewall would presumably drop it 2. If there is no RH or an RH with zero elements then follow non-MIPv6 firewall policy 3. If the RH has more then one element then treat it as a non-MIPv6 routing header (whatever policy that is subject to) 4. If one element RH with the address in the RH being external to the site allow it (assuming "visiting" MNs are allowed) 5. If one element RH with the address in the RH being internal verify that the address in the RH is allowed to communicate externally with the protocol/port number. If so allow the packet with the RH. The above firewall rules are somewhat complex and they can't, by the very nature of the routing header, prevent source routing. For instance, rule #4 means that packets can be source routed through the site and back out again, and rule #5 allows some internal source routing. Thus this approach assumes that there isn't a perception that IPv6 firewalls need to block actual source routing while allowing the MIPv6 use of routing headers. There is also a concern that the existing IPv4 firewall behavior of blocking source routing might be carried forth into IPv6 firewalls. Should this happen there is a failure case where route optimization is established through a Binding Update but the data packets, with the RH, are dropped. If the CN somehow decides to discard the binding cache entry and send through the HA, it is likely that this would anew result in a Binding Update. Thus if this approach is taken it would seem prudent to make MIPv6 robust against packets with RH being discarded. Define a MIPv6 specific thing instead of using RH ------------------------------------------------- An open question is to what extent approach #3 would make things significantly simpler. The non-RH packet format could be to e.g. define a new destination option, define a new extension header, define a new routing header type, or use IPv6_NO_SRC as specified in draft-deering-ipv6-encap-addr-deletion-00.txt. The following discussion doesn't assume any particular of the above encodings - it just assumes that it is a different encoding than the current routing header so that the firewall can have different policies for source routing and MIPv6. For all the encodings it is assumed that the rules are that 1) only a single address is contained in the encoding (just like a single element routing header), and 2) the receiving node never forwards the packet after processing it. The encoding that is most consistent with the Home Address Option would be to define a destination option carrying the Home Address for the destination. This could be name the alternate (or "outer"? "upper layer"?) destination address option. If this approach is taken it might make sense to rename the Home Address Option to have a similar name e.g. the Alternate Source Address Option. RECOMMENDATION ============== The design team is leaning towards #3 at the moment. One reason for this is that this would remove any suspicion that firewall administrators have for the use of the Routing Header and which might consequently lead to disabling MIPv6 because of these fears. Also, the firewall rules necessary to process the Routing Header are complex and accidental disabling of MIPv6 might also occur. The use of the Routing Header for other purposes would also not be affected. There are also drawbacks in alternative #3. One such issue is that existing MIPv6 implementations have to be changed. We feel that this drawback is offset by the expected wider usability of MIPv6 as a result. This change will also imply a substantial document modification for the MIPv6 I-D. This does not appear to be a structural change, however, and in general we feel that direct procedure is easier to describe than attempting to describe some additional rules to constrain the use of the Routing Header. Finally, alternative #3 might lead us to depend on the external work such as the new tunnel encapsulation work at IPNG. The design team feels that we should stay away from these non-MIPv6 solutions due schedule issues as well as in the interests of making a self-contained RFC. --- From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 03:43: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 DAA17650 for ; Thu, 24 Jan 2002 03:43:19 -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 AAA09374; Thu, 24 Jan 2002 00:43: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 AAA00723; Thu, 24 Jan 2002 00:42: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 g0O8dZ2Q021191 for ; Thu, 24 Jan 2002 00:39:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0O8dZST021190 for mobile-ip-dist; Thu, 24 Jan 2002 00:39: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 g0O8dV2Q021183 for ; Thu, 24 Jan 2002 00:39: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 AAA00193 for ; Thu, 24 Jan 2002 00:39:36 -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 BAA27472 for ; Thu, 24 Jan 2002 01:39:35 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 20AEAA; Thu, 24 Jan 2002 10:40:32 +0200 (EET) Message-ID: <3C4FC833.7020108@nomadiclab.com> Date: Thu, 24 Jan 2002 10:39:15 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> 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: > Besides, I do not think that the future attack against RR as described > by Pekka is feasible only by plugging a laptop and using ND. It is, at least under some circumstances. Depends on how your home network authenticates your laptop. If it doesn't, you can do the future attack against a particular host by just visiting its home network, or even by tapping in to some cable between the home network and the CN. What is much worse, however, is that you can use the future attack technique for bombing too. You physically go to your target network (or tap to a link in between), plug in your laptop, pretend to be your own HA, establish a binding at the CN, go away, and later let the binding to expire. If you have active communications going on when the binding expires (e.g. a large file transfer), the packets start bombing to your target, and you can even keep the TCP transfer to go on for some time by carefully sending false ACKs. The conclusion so far seems to be that if you use RR-only, you have to limit the lifetime of bindings to something fairly short, e.g. a few minutes. Plus, in addition to checking RR of CoA, you have to perform RR for the HoA, too, either every few minutes or whenever you renew your binding. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 05:36: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 FAA19101 for ; Thu, 24 Jan 2002 05:36:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24056; Thu, 24 Jan 2002 03:35: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 CAA06795; Thu, 24 Jan 2002 02:35: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 g0OAYf2Q021446 for ; Thu, 24 Jan 2002 02:34:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OAYfbj021445 for mobile-ip-dist; Thu, 24 Jan 2002 02:34:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OAYc2Q021438 for ; Thu, 24 Jan 2002 02:34:38 -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 CAA02975 for ; Thu, 24 Jan 2002 02:34:44 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28041 for ; Thu, 24 Jan 2002 03:34:38 -0700 (MST) Received: from PATINET (patinet.u-strasbg.fr [130.79.90.172]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id LAA11877 for ; Thu, 24 Jan 2002 11:34:37 +0100 Message-ID: <01be01c1a4c2$c07f6670$ac5a4f82@ustrasbg.fr> From: "Christophe Jelger" To: References: <2E33960095B58E40A4D3345AB9F65EC102DB7F02@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [mobile-ip] Multicast routing issue in MIP Date: Thu, 24 Jan 2002 11:34:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I checked your slides a few days ago and also proposed a different solution in an Internet draft (draft-jelger-mssmsv6-00.txt) that has just been published yesterday. I hope you'll find some time to read it and to give me some feedback on that, especially as you have quite an experience when dealing with multicast in general. Christophe ----- Original Message ----- From: "Dave Thaler" To: Sent: Monday, January 21, 2002 1:51 AM Subject: RE: [mobile-ip] Multicast routing issue in MIP > After announcing it at the MIP WG, I gave a presentation in the MAGMA WG > at the IETF in SLC on this topic. It looks like the proceedings aren't > online yet. If you want a copy of my slides before they appear on the > ietf site, > let me know. > > In short: there are issues. The multicast language currently in the > MIPv6 spec should be ignored. There are a couple of possible solutions, > ranging from inefficient (e.g., always tunneling via Home Agent) to > complex (requiring a slight change to correspondent node behavior). > > -Dave > > > -----Original Message----- > > From: Young-Jun Lee [mailto:gte393q@prism.gatech.edu] > > Sent: Sunday, January 20, 2002 3:34 PM > > To: IETF Mobile IP WG > > Subject: [mobile-ip] Multicast routing issue in MIP > > > > I think multicasting in mip is also an impportant issue. > > RFC2002 mentions multicasting simply thru only one page. > > But I could not find any discussion about that issue in this > > working group. > > Is this because there are lots of other important issues that wg > should > > focus on? > > Or should this issue be handled by other wg? > > I'd appreciate it if anybody would explain about this situation. > > > > Regards, > > > > Young-Jun Lee > > Georgia Institute of Technology > From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 08:13: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 IAA20753 for ; Thu, 24 Jan 2002 08:13:26 -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 GAA28003; Thu, 24 Jan 2002 06:13: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 FAA29331; Thu, 24 Jan 2002 05:13: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 g0ODCK2Q021711 for ; Thu, 24 Jan 2002 05:12:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0ODCKtL021710 for mobile-ip-dist; Thu, 24 Jan 2002 05:12:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0ODCG2Q021703 for ; Thu, 24 Jan 2002 05:12:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22045 for ; Thu, 24 Jan 2002 05:12:22 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06849 for ; Thu, 24 Jan 2002 06:12:21 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0ODCKIB024041 for ; Thu, 24 Jan 2002 14:12:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jan 24 14:12:10 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 14:12:10 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A940@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alexandru Petrescu'" , "Jari Arkko (LMF)" Cc: "'mobile-ip@sunroof.eng.sun.com'" , "Hesham Soliman (ERA)" , "'Erik Nordmark'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Thu, 24 Jan 2002 14:11:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alex, > This is indeed a more likely scenario. But without access > to router, > attacker can do less harm and is also in danger of being detected by > its neighbours. Windows, Solaris and HP-UX already do > that, I think. > > Besides, I do not think that the future attack against RR > as described > by Pekka is feasible only by plugging a laptop and using ND. > => The attack is certainly feasible without compromising a router. In the 'Is RR only enough' thread, Erik also explained that it was feasible today. The difference was that you could (if you look at ARP caches) see it today. Whereas you wouldn't be able to see it with an attack on RR. Not a significant difference IMO. The other (significant IMO) difference was that e2e security can stop this attack today, whereas it would not stop it when using RR only. How significant this is ? I can't judge that right now, there are too many factors to consider. But it is certainly something we should be aware of. For more details please have a look at that thread. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 10:38: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 KAA23903 for ; Thu, 24 Jan 2002 10:38: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 HAA27187; Thu, 24 Jan 2002 07:37:59 -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 HAA05906; Thu, 24 Jan 2002 07:35: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 g0OFYk2Q021927 for ; Thu, 24 Jan 2002 07:34:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OFYkgv021926 for mobile-ip-dist; Thu, 24 Jan 2002 07:34: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 g0OFYh2Q021919 for ; Thu, 24 Jan 2002 07:34:43 -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 HAA05692 for ; Thu, 24 Jan 2002 07:34:48 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16127 for ; Thu, 24 Jan 2002 07:34:48 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA10422 for ; Thu, 24 Jan 2002 08:34:45 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA23954 for ; Thu, 24 Jan 2002 08:34:43 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Thu, 24 Jan 2002 08:34:42 -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 13BDF2EC84; Thu, 24 Jan 2002 16:30:48 +0100 (CET) To: "Hesham Soliman (ERA)" Cc: "Jari Arkko (LMF)" , "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 References: <4DA6EA82906FD511BE2F00508BCF053802C6A940@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 24 Jan 2002 16:34:35 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A940@Esealnt861.al.sw.ericsson.se> 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: Hesham, thank you for pointing me to that thread, I must recognize I haven't read it. I won't reply further if things look already sorted out. Only one remark to one of your conclusions, inserted below. "Hesham Soliman (ERA)" writes: > => The attack is certainly feasible without compromising > a router. In the 'Is RR only enough' thread, Erik > also explained that it was feasible today. The difference > was that you could (if you look at ARP caches) see it > today. Whereas you wouldn't be able to see it with an > attack on RR. Not a significant difference IMO. "The attack is certainly feasible without compromising a router"? As I said earlier, attacker must not only generate fake RR messaging to CN but it must also block true RR messages from CN to reach true HA. In the case of RR like BAKE, if HA receives a true Binding Request from CN and forwards it to MN and MN does BKE to CN, CN will end up with two BKE's, one that it can authenticate and one that it can not. At that moment CN can realize something is wrong somewhere and shorten the lifetime of the binding or make it 0 and log this event. This exactly what happens in ARP or possibly ND. Host listens and if incoherences in addresses are heard then make them visible. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 10:53: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 KAA24395 for ; Thu, 24 Jan 2002 10:53: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 HAA04576; Thu, 24 Jan 2002 07:53:25 -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 HAA27604; Thu, 24 Jan 2002 07:53: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 g0OFqN2Q022179 for ; Thu, 24 Jan 2002 07:52:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OFqNdH022178 for mobile-ip-dist; Thu, 24 Jan 2002 07:52:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OFqJ2Q022171 for ; Thu, 24 Jan 2002 07:52:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10685 for ; Thu, 24 Jan 2002 07:52:25 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22095 for ; Thu, 24 Jan 2002 08:52:24 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA29208 for ; Thu, 24 Jan 2002 08:52:24 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA10740 for ; Thu, 24 Jan 2002 08:41:25 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Thu, 24 Jan 2002 08:52:22 -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 ABC552EC83; Thu, 24 Jan 2002 16:48:28 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: "Hesham Soliman (ERA)" , "Jari Arkko (LMF)" , "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 References: <4DA6EA82906FD511BE2F00508BCF053802C6A940@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 24 Jan 2002 16:52:16 +0100 In-Reply-To: Message-Id: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alexandru Petrescu writes: > At that moment CN can realize something is wrong somewhere and shorten > the lifetime of the binding or make it 0 and log this event. Sorry for following up on my own message, but CN can also re-RR n times the MN if it gets two BKE's when it asked for one. Some RR schemes can be extended to make it very hard for attacker to use the future attack without compromising routers. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 11:22: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 LAA25765 for ; Thu, 24 Jan 2002 11:22:31 -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 IAA18787; Thu, 24 Jan 2002 08:21:59 -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 IAA19154; Thu, 24 Jan 2002 08:21: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 g0OGKw2Q022432 for ; Thu, 24 Jan 2002 08:20:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OGKvlX022431 for mobile-ip-dist; Thu, 24 Jan 2002 08:20: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 g0OGKs2Q022424 for ; Thu, 24 Jan 2002 08:20:54 -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 IAA20511 for ; Thu, 24 Jan 2002 08:21:00 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15594 for ; Thu, 24 Jan 2002 08:20:59 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id JAA12537 for ; Thu, 24 Jan 2002 09:10:38 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA14944 for ; Thu, 24 Jan 2002 09:20:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Thu, 24 Jan 2002 10:20:50 -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 885B42EC85; Thu, 24 Jan 2002 17:16:53 +0100 (CET) To: Pekka Nikander Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> <3C4FC833.7020108@nomadiclab.com> From: Alexandru Petrescu Date: 24 Jan 2002 17:20:40 +0100 In-Reply-To: <3C4FC833.7020108@nomadiclab.com> Message-Id: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Pekka, Pekka Nikander writes: > You physically go to your target network (or tap to a link in > between), plug in your laptop, pretend to be your own HA, establish > a binding at the CN, go away, and later let the binding to expire. > If you have active communications going on when the binding expires > (e.g. a large file transfer), the packets start bombing to your > target, and you can even keep the TCP transfer to go on for some > time by carefully sending false ACKs. This looks indeed like a feasible attack. However this is hardly feasible if CN is required to drop bindings when receiving two differing BKE's (sorry I use BAKE terminology only because it's easier for me to put names on messages). One more thing, what is the fear of the above attack? That the target network gets bombed or that it's difficult to identify who provoked it? In the first case, you can always bomb something, no feasible defense at protocol level. Add new messages to secure something and then the new entities can be bombed. In the second case, err, I don't know, probably this kind of impersonation is a fact of life today, with faked source addresses in ICMP echo requests. I guess people find the true identities by verbal coordination, looking at log messages, etc. Please do not get me wrong, I'm not saying there's no need of protection in Mobile IPv6, just trying to identify what is genuinely new security flaw introduced by it. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 12:00: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 MAA27319 for ; Thu, 24 Jan 2002 12:00:18 -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 IAA07845; Thu, 24 Jan 2002 08:59:59 -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 IAA00439; Thu, 24 Jan 2002 08:59: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 g0OGwt2Q022716 for ; Thu, 24 Jan 2002 08:58:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OGwtX4022715 for mobile-ip-dist; Thu, 24 Jan 2002 08:58:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OGwq2Q022708 for ; Thu, 24 Jan 2002 08:58:52 -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 IAA17602 for ; Thu, 24 Jan 2002 08:58:58 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24037 for ; Thu, 24 Jan 2002 08:58:56 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0OGwsIB006024 for ; Thu, 24 Jan 2002 17:58:54 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 24 17:58:37 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 17:58:53 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A949@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Alexandru Petrescu'" , "Hesham Soliman (ERA)" Cc: "Jari Arkko (LMF)" , "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Thu, 24 Jan 2002 17:58:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => The attack is certainly feasible without compromising > > a router. In the 'Is RR only enough' thread, Erik > > also explained that it was feasible today. The difference > > was that you could (if you look at ARP caches) see it > > today. Whereas you wouldn't be able to see it with an > > attack on RR. Not a significant difference IMO. > > "The attack is certainly feasible without compromising a > router"? => Yes. But please note, this is applicable to the cases where the HA does not participate in RR. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 12:06:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27645 for ; Thu, 24 Jan 2002 12:06:35 -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 KAA28081; Thu, 24 Jan 2002 10:06: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 JAA02772; Thu, 24 Jan 2002 09:06: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 g0OH5G2Q022814 for ; Thu, 24 Jan 2002 09:05:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OH5Gpq022813 for mobile-ip-dist; Thu, 24 Jan 2002 09:05:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OH5D2Q022806 for ; Thu, 24 Jan 2002 09:05:13 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20265 for ; Thu, 24 Jan 2002 09:05:19 -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 JAA27054 for ; Thu, 24 Jan 2002 09:05:18 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA00962 for ; Thu, 24 Jan 2002 10:05:17 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA16726 for ; Thu, 24 Jan 2002 10:05:17 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Thu, 24 Jan 2002 10:05:08 -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 CF9592EC83; Thu, 24 Jan 2002 18:01:15 +0100 (CET) To: "Hesham Soliman (ERA)" Cc: "Jari Arkko (LMF)" , "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 References: <4DA6EA82906FD511BE2F00508BCF053802C6A949@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 24 Jan 2002 18:05:03 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A949@Esealnt861.al.sw.ericsson.se> Message-Id: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "Hesham Soliman (ERA)" writes: > > > => The attack is certainly feasible without compromising > > > a router. In the 'Is RR only enough' thread, Erik > > > also explained that it was feasible today. The difference > > > was that you could (if you look at ARP caches) see it > > > today. Whereas you wouldn't be able to see it with an > > > attack on RR. Not a significant difference IMO. > > > > "The attack is certainly feasible without compromising a > > router"? > > => Yes. But please note, this is applicable to the cases > where the HA does not participate in RR. Aha, now I can understand. So all this discussion was about how Mobile IPv6 is "future attacked" while protected by CGA's? Sorry for the misunderstanding. Alex From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 24 13:57:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02231 for ; Thu, 24 Jan 2002 13:57: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 LAA22721; Thu, 24 Jan 2002 11:57:44 -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 KAA14388; Thu, 24 Jan 2002 10:57: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 g0OIub2Q023267 for ; Thu, 24 Jan 2002 10:56:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0OIubsF023266 for mobile-ip-dist; Thu, 24 Jan 2002 10:56:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0OIuW2Q023259 for ; Thu, 24 Jan 2002 10:56:33 -0800 (PST) Received: from lillen (gbl-rem-42 [129.157.174.42]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0OIuXF17493; Thu, 24 Jan 2002 19:56:33 +0100 (MET) Date: Thu, 24 Jan 2002 18:00:04 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 To: Alexandru Petrescu Cc: "Hesham Soliman (ERA)" , "Jari Arkko (LMF)" , "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > "The attack is certainly feasible without compromising a router"? As > I said earlier, attacker must not only generate fake RR messaging to > CN but it must also block true RR messages from CN to reach true HA. The "block" aspects may or may not be needed. For instance, in BU3WAY it is not needed; a MN receiving a BUC that has not sent a BUR will silently ignore the BUC. I think this is necessary to avoid DoS issues where an attacker sends spoofed BUC messages, potentially with a spoofed source address, in order to use create state on the MN. But I haven't thought about this in detail - but the point is that it might not be as trivial as it looks at first sight. But I'm not convinced the difference matters. Somebody that is on-path, whether connected to a multi-access link using ARP/ND or physically in a router or switch, is capable of sending and receiving packets as well as blocking packets from being forwarded. A possible case when this would not be the case is when the attacker has a passive leak/bleed (of the copper or optical wire) for receive and uses a completely different interface to transmit packets. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 04:44: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 EAA27857 for ; Fri, 25 Jan 2002 04:44:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA21485; Fri, 25 Jan 2002 01:43:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14977; Fri, 25 Jan 2002 01: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 g0P9gr2Q024225 for ; Fri, 25 Jan 2002 01:42:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0P9grYC024224 for mobile-ip-dist; Fri, 25 Jan 2002 01:42: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 g0P9go2Q024217 for ; Fri, 25 Jan 2002 01:42:50 -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 BAA14802 for ; Fri, 25 Jan 2002 01:42:55 -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 CAA12539 for ; Fri, 25 Jan 2002 02:42:54 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id DFB7FA; Fri, 25 Jan 2002 11:43:51 +0200 (EET) Message-ID: <3C51287B.1070404@nomadiclab.com> Date: Fri, 25 Jan 2002 11:42:19 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> <3C4FC833.7020108@nomadiclab.com> 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 Alexandru, >>You physically go to your target network (or tap to a link in >>between), plug in your laptop, pretend to be your own HA, establish >>a binding at the CN, go away, and later let the binding to expire. >>If you have active communications going on when the binding expires >>(e.g. a large file transfer), the packets start bombing to your >>target, and you can even keep the TCP transfer to go on for some >>time by carefully sending false ACKs. >> > > This looks indeed like a feasible attack. However this is hardly > feasible if CN is required to drop bindings when receiving two > differing BKE's (sorry I use BAKE terminology only because it's easier > for me to put names on messages). How come? You are acting here alone. There is no real HA, no real MN. You just prented to be the HA and MN. Where does the CN receive the second BKE (or whatever)? > One more thing, what is the fear of the above attack? That the target > network gets bombed or that it's difficult to identify who provoked > it? In the first case, you can always bomb something, no feasible > defense at protocol level. Add new messages to secure something and > then the new entities can be bombed. In the second case, err, I don't > know, probably this kind of impersonation is a fact of life today, > with faked source addresses in ICMP echo requests. I guess people > find the true identities by verbal coordination, looking at log > messages, etc. The fear is that with this attack, you can turn any node (since all nodes must presumably support basic CN operations) into a high-amplifier DoS attack device _without_ breaking into the CN. Sure you can bomb any network, but with this attack you can potentially turn a few hundred innocent hosts around in the internet into bombers, and remain yourself undetected. Unless the attack network saves all traffic at the time you visit their network, there is no trace whatsoever anywhere about who you were, where and when you visited your target network, etc. By the time the attack is launched, the CN's have just dropped the bindings, so they don't remember your last address (the CoA in the last binding). The target network gets no hints that such an attack will appear between the time you visit their network and the time the actual attack is launched. When the attack is launched, the target network does learn the IP addresses of the bombing CNs, but those hosts are legitimite hosts; they haven't been broken into, and they are acting 100% according to the specs. Thus, in your terms, the fear is that is virtually impossilbe to identify the culprit, and that all participating CN hosts are acting 100% correctly; they haven't been broken into. In fact, _NO_ hosts needs to be broken into with this attack, you just must be able to visit your target network (or some link near your target network). Besides, you don't need to _block_ or change any packets, it is enough that you can receive (eavesdrop) and send (inject) packets. Besides, this is just one example of the possible future attacks that are introduced. Fortunately, by limiting the lifetimes of RR-only bindings to short enough (few minutes), it seems that we can mitigate the threats to an acceptable level. On the other hand, if we want to support long term bindings (hours or so), CGA seems to be necessary. Thus, the turnside of RR is that you have to perform the RR check against both the CoA and HoA every few minutes, and the benefit is low computational cost. Respectively, the benefit of CGA is that you need to perform HoA RR just once an hour or so, and CoA check only if you refresh or change your binding, but the computational (and possibly IPR) cost is higher. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 05:14: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 FAA28161 for ; Fri, 25 Jan 2002 05:14:54 -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 DAA01557; Fri, 25 Jan 2002 03:14: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 CAA18951; Fri, 25 Jan 2002 02:14: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 g0PADX2Q024278 for ; Fri, 25 Jan 2002 02:13:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PADX0k024277 for mobile-ip-dist; Fri, 25 Jan 2002 02:13:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PADU2Q024270 for ; Fri, 25 Jan 2002 02:13:30 -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 CAA20485 for ; Fri, 25 Jan 2002 02:13:36 -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 DAA01070 for ; Fri, 25 Jan 2002 03:13:35 -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 g0PADX516394 for ; Fri, 25 Jan 2002 11:13:33 +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 LAA21620 for ; Fri, 25 Jan 2002 11:13:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0PADXg13148 for ; Fri, 25 Jan 2002 11:13:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201251013.g0PADXg13148@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Routing headers (CLARIFICATION) In-reply-to: Your message of Wed, 23 Jan 2002 21:34:55 +0100. Date: Fri, 25 Jan 2002 11:13:33 +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: IMHO and if there is a consensus about the solution #3 (my opinion is this is the best solution if this is implemented carefully) I believe we should not propose a new non-final extension header. So if other points show a strong interest for IPv6_NO_SRC stuff, we should use it. If not, a new routing header type is the simplest so the best solution. Of course in the last case a type value should be proposed ASAP. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 05:23: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 FAA28255 for ; Fri, 25 Jan 2002 05:23:56 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06082; Fri, 25 Jan 2002 03:23: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 CAA19997; Fri, 25 Jan 2002 02:23: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 g0PAMs2Q024399 for ; Fri, 25 Jan 2002 02:22:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PAMsU8024398 for mobile-ip-dist; Fri, 25 Jan 2002 02:22:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PAMo2Q024391 for ; Fri, 25 Jan 2002 02:22:51 -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 CAA07826 for ; Fri, 25 Jan 2002 02:22:56 -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 DAA24167 for ; Fri, 25 Jan 2002 03:22: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 g0PAMs517720 for ; Fri, 25 Jan 2002 11:22: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 LAA21875 for ; Fri, 25 Jan 2002 11:22: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 g0PAMsg13190 for ; Fri, 25 Jan 2002 11:22:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201251022.g0PAMsg13190@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: Routing headers (ISSUE) In-reply-to: Your message of Wed, 23 Jan 2002 21:34:55 +0100. Date: Fri, 25 Jan 2002 11:22: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: Currently some IPv6 implementations don't safely deal with RH, for instance they blindly forward by default packets with RH in the host mode. The IPv6 WG should warn ASAP implementers that RFC 1122 section 3.3.5 security considerations apply without possible harm to Mobile IPv6 (fine consequence of approch #3). I don't know how this recommendation should be broadcasted. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 06:37: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 GAA28950 for ; Fri, 25 Jan 2002 06:37:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10508; Fri, 25 Jan 2002 04:37:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04497; Fri, 25 Jan 2002 03: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 g0PBZk2Q024639 for ; Fri, 25 Jan 2002 03:35:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PBZkHh024638 for mobile-ip-dist; Fri, 25 Jan 2002 03:35: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 g0PBZh2Q024631 for ; Fri, 25 Jan 2002 03:35:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28276 for ; Fri, 25 Jan 2002 03:35:48 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10121 for ; Fri, 25 Jan 2002 04:35:46 -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 g0PBZf117455; Fri, 25 Jan 2002 12:35:41 +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 g0PBZer6007724; Fri, 25 Jan 2002 13:35:40 +0200 (EET) Message-ID: <3C51430C.4CE642DB@lmf.ericsson.se> Date: Fri, 25 Jan 2002 13:35:40 +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] Re: Routing headers (ISSUE) References: <200201251022.g0PAMsg13190@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 >Currently some IPv6 implementations don't safely deal with RH, >for instance they blindly forward by default packets with RH >in the host mode. The IPv6 WG should warn ASAP implementers >that RFC 1122 section 3.3.5 security considerations apply >without possible harm to Mobile IPv6 (fine consequence of approch #3). >I don't know how this recommendation should be broadcasted. Right. Perhaps we can make a some sort of announcement somewhere, but little further down the road this recommendation must find itself to the IPv6 host requirements document. By the way, there already is some safety text in this direction at the cellular host requirements draft (draft-manyfolks-ipv6-cellular-host-02.txt). Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 06:45:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29050 for ; Fri, 25 Jan 2002 06:45:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14741; Fri, 25 Jan 2002 04:44: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 DAA14058; Fri, 25 Jan 2002 03:44:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PBiC2Q024691 for ; Fri, 25 Jan 2002 03:44:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PBiCvL024690 for mobile-ip-dist; Fri, 25 Jan 2002 03:44: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 g0PBi92Q024683 for ; Fri, 25 Jan 2002 03:44:09 -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 DAA08062 for ; Fri, 25 Jan 2002 03:44:14 -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 EAA22378 for ; Fri, 25 Jan 2002 04:44:13 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA17550 for ; Fri, 25 Jan 2002 04:44:11 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA19765 for ; Fri, 25 Jan 2002 04:33:12 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Fri, 25 Jan 2002 04:44:09 -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 7C24F2EC84; Fri, 25 Jan 2002 12:40:15 +0100 (CET) To: Pekka Nikander Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> <3C4FC833.7020108@nomadiclab.com> <3C51287B.1070404@nomadiclab.com> From: Alexandru Petrescu Date: 25 Jan 2002 11:44:02 +0100 In-Reply-To: <3C51287B.1070404@nomadiclab.com> Message-Id: Lines: 63 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: Pekka Nikander writes: > Hi Alexandru, > > >>You physically go to your target network (or tap to a link in > >>between), plug in your laptop, pretend to be your own HA, establish > >>a binding at the CN, go away, and later let the binding to expire. > >>If you have active communications going on when the binding expires > >>(e.g. a large file transfer), the packets start bombing to your > >>target, and you can even keep the TCP transfer to go on for some > >>time by carefully sending false ACKs. > >> > > This looks indeed like a feasible attack. However this is hardly > > feasible if CN is required to drop bindings when receiving two > > differing BKE's (sorry I use BAKE terminology only because it's easier > > for me to put names on messages). > > > How come? You are acting here alone. There is no real HA, no > real MN. You just prented to be the HA and MN. Where does > the CN receive the second BKE (or whatever)? Now I see your point, thanks. Ony one remark: if by "no real MN" you mean that the host to which CN sends BKR does not understand Mobile IPv6 because it is a simple host then this host would still reply an ICMP Parameter Problem to CN and CN will still get two responses to its BKR. If, on the other hand, by "no real MN" you mean that the MN is actually switched off, then... How much real can this be? If you want to deny CN's services initiated towards MN you must (1) be in the path and (2) ensure MN is off. Isn't it enough to just ensure (2)? > The fear is that with this attack, you can turn any node (since > all nodes must presumably support basic CN operations) into a > high-amplifier DoS attack device _without_ breaking into the CN. > Sure you can bomb any network, but with this attack you can > potentially turn a few hundred innocent hosts around in the > internet into bombers, and remain yourself undetected. Same with faked source addresses in ICMP Echo Requests. > Unless the attack network saves all traffic at the time you > visit their network, there is no trace whatsoever anywhere > about who you were, where and when you visited your target > network, etc. There are networks that do just that. No need to save entire packets, full headers with timestamps are enough. > On the other hand, if we want to support long term bindings (hours > or so), CGA seems to be necessary. Thus, the turnside of RR is that > you have to perform the RR check against both the CoA and HoA every > few minutes, and the benefit is low computational cost. > Respectively, the benefit of CGA is that you need to perform HoA RR > just once an hour or so, and CoA check only if you refresh or change > your binding, but the computational (and possibly IPR) cost is > higher. I entirely agree with the above. Striking the right balance doesn't seem easy. Fast handovers with RR and with CGA's... Alex From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 06:54: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 GAA29566 for ; Fri, 25 Jan 2002 06:54:26 -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 EAA18833; Fri, 25 Jan 2002 04:54: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 DAA16430; Fri, 25 Jan 2002 03:54:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PBrG2Q024923 for ; Fri, 25 Jan 2002 03:53:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PBrGxs024922 for mobile-ip-dist; Fri, 25 Jan 2002 03:53: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 g0PBrD2Q024915 for ; Fri, 25 Jan 2002 03:53:13 -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 DAA12436 for ; Fri, 25 Jan 2002 03:53:18 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04372 for ; Fri, 25 Jan 2002 03:53:17 -0800 (PST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 2B1E8A; Fri, 25 Jan 2002 13:54:14 +0200 (EET) Message-ID: <3C51470A.3010305@nomadiclab.com> Date: Fri, 25 Jan 2002 13:52:42 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> <3C4FC833.7020108@nomadiclab.com> <3C51287B.1070404@nomadiclab.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, Only a small comment: I wrote: >>The fear is that with this attack, you can turn any node (since >>all nodes must presumably support basic CN operations) into a >>high-amplifier DoS attack device _without_ breaking into the CN. >>Sure you can bomb any network, but with this attack you can >>potentially turn a few hundred innocent hosts around in the >>internet into bombers, and remain yourself undetected. You answered: > Same with faked source addresses in ICMP Echo Requests. Not quite. With ICMP Echo Requests, 2-way i-trace still reveals your location. Secondly, ICMP Echo Requests (or other "normal" reflection attacks) don't provide you with the amplification factor. That is, in this scenario the target network is bombed with full sized TCP packets, and the attacker keeps them flowing by sending very small TCP ACK packets with carefully calculated sequence numbers. Thus, we can say that the amplification factor is high. 2-way i-trace is much less useful in finding out the real location of the sender of the faked ACKs, since there are so few of them. --Pekka From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 07:58: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 HAA00924 for ; Fri, 25 Jan 2002 07:58:19 -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 FAA14358; Fri, 25 Jan 2002 05:58:05 -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 EAA27800; Fri, 25 Jan 2002 04:58: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 g0PCv42Q024990 for ; Fri, 25 Jan 2002 04:57:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PCv4sY024989 for mobile-ip-dist; Fri, 25 Jan 2002 04:57: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 g0PCv12Q024982 for ; Fri, 25 Jan 2002 04:57:01 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27600 for ; Fri, 25 Jan 2002 04:57:07 -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 FAA04237 for ; Fri, 25 Jan 2002 05:57:07 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id FAA13145 for ; Fri, 25 Jan 2002 05:46:47 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA15700 for ; Fri, 25 Jan 2002 05:57:06 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Fri, 25 Jan 2002 06:57:05 -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 3D9C12EC83; Fri, 25 Jan 2002 13:53:11 +0100 (CET) To: Pekka Nikander Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C385158.8010201@nomadiclab.com> <3C4D1222.9010308@nomadiclab.com> <3C4EB9E7.377A562D@lmf.ericsson.se> <3C4FC833.7020108@nomadiclab.com> <3C51287B.1070404@nomadiclab.com> <3C51470A.3010305@nomadiclab.com> From: Alexandru Petrescu Date: 25 Jan 2002 13:57:03 +0100 In-Reply-To: <3C51470A.3010305@nomadiclab.com> 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: Pekka Nikander writes: > Not quite. With ICMP Echo Requests, 2-way i-trace still > reveals your location. Secondly, ICMP Echo Requests > (or other "normal" reflection attacks) don't provide > you with the amplification factor. That is, in this > scenario the target network is bombed with full sized > TCP packets, and the attacker keeps them flowing by > sending very small TCP ACK packets with carefully > calculated sequence numbers. Thus, we can say that the > amplification factor is high. 2-way i-trace is much > less useful in finding out the real location of the > sender of the faked ACKs, since there are so few of them. So extend itrace to handle these MIP cases. Extend ingress filtering to disallow malicious laptops to send RR messages for incorrect CoA/HoA. And, TCP ACK security problem then TCP security solution (cookies?). So many alternative ways for routing according to keys. Or probably those have already been explored. Alex From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 12:37:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08484 for ; Fri, 25 Jan 2002 12:37:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09786; Fri, 25 Jan 2002 09:37: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 JAA14471; Fri, 25 Jan 2002 09:36: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 g0PHZL2Q025452 for ; Fri, 25 Jan 2002 09:35:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PHZKCE025451 for mobile-ip-dist; Fri, 25 Jan 2002 09:35: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 g0PHZH2Q025444 for ; Fri, 25 Jan 2002 09:35:17 -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 JAA25593 for ; Fri, 25 Jan 2002 09:35:23 -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 KAA23868 for ; Fri, 25 Jan 2002 10:35:23 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA20593 for ; Fri, 25 Jan 2002 09:35:22 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0PHZMD02008 for ; Fri, 25 Jan 2002 09:35:22 -0800 X-mProtect: Fri, 25 Jan 2002 09:35:22 -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 smtpdPOUppq; Fri, 25 Jan 2002 09:35:21 PST Message-ID: <3C519759.C70EC3D3@iprg.nokia.com> Date: Fri, 25 Jan 2002 09:35: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] Routing headers: design team recommendation (CONCLUSION) 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, I agree with the Design Team's recommendation. And I would prefer changing it to a destination option. (True Destination Address??) > RECOMMENDATION > ============== > The design team is leaning towards #3 at the moment. One > reason for this is that this would remove any suspicion that firewall > administrators have for the use of the Routing Header and > which might consequently lead to disabling MIPv6 because of these > fears. Also, the firewall rules necessary to process the Routing > Header are complex and accidental disabling of MIPv6 might also > occur. The use of the Routing Header for other purposes would > also not be affected. There are also drawbacks in alternative #3. > One such issue is that existing MIPv6 implementations have to > be changed. We feel that this drawback is offset by the expected > wider usability of MIPv6 as a result. This change will also imply > a substantial document modification for the MIPv6 I-D. This > does not appear to be a structural change, however, and in > general we feel that direct procedure is easier to describe than > attempting to describe some additional rules to constrain the use > of the Routing Header. Finally, alternative #3 might lead us to > depend on the external work such as the new tunnel encapsulation > work at IPNG. The design team feels that we should stay away > from these non-MIPv6 solutions due schedule issues as well > as in the interests of making a self-contained RFC. Agree completely on the last point. and going by the last point, a destination option seems to be the best thing to do (IMO). regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 17: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 RAA15911 for ; Fri, 25 Jan 2002 17: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 OAA03543; Fri, 25 Jan 2002 14:10:12 -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 OAA13727; Fri, 25 Jan 2002 14:10: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 g0PM962Q025716 for ; Fri, 25 Jan 2002 14:09:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PM96LX025715 for mobile-ip-dist; Fri, 25 Jan 2002 14:09: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 g0PM932Q025708 for ; Fri, 25 Jan 2002 14:09:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03831 for ; Fri, 25 Jan 2002 14:09:09 -0800 (PST) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16610 for ; Fri, 25 Jan 2002 15:09:08 -0700 (MST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id g0PM95f31808; Fri, 25 Jan 2002 17:09:06 -0500 From: "Andrew T. Campbell" To: "Mobile-Ip \(E-mail\)" Cc: "Andrew Campbell \(E-mail\)" Subject: [mobile-ip] FW: DIREN'02 Date: Fri, 25 Jan 2002 17:06:28 -0500 Message-ID: <00d501c1a5ec$8a46b880$ca413b80@SWEETPEA> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Aurel A. Lazar [mailto:aurel@ee.columbia.edu] > Sent: Friday, January 25, 2002 5:20 PM > To: mnl@comet.columbia.edu > Cc: Aurel A. Lazar (E-mail) > Subject: DIREN'02 > > > Call for Participation > > The First IEEE Workshop on Disaster Recovery Networks > invites your participation in this international > forum on innovative network technologies, architectures, and > services that can be effectively deployed during disaster > recovery. DIREN is sponsored (pending) by the IEEE Communications > Society and will be co-located and organized in conjunction with > INFOCOM. > > Please submit by March 15, 2002, a short statement about the > topics that you would like to discuss or would like to hear being > discussed to aurel@ee.columbia.edu or nick@ee.columbia.edu. > > The program of the workshop will be posted at > http://comet.columbia.edu/diren no later than April 15, 2002. > > Organizing and Program Committee > Victor S. Frost, University of Kansas > Aurel A. Lazar, Columbia University > Mary Maeda, DARPA > Nicholas F. Maxemchuk, Columbia University > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 17:31: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 RAA16669 for ; Fri, 25 Jan 2002 17:31:12 -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 OAA11450; Fri, 25 Jan 2002 14:30:36 -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 OAA16511; Fri, 25 Jan 2002 14:30: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 g0PMSl2Q025826 for ; Fri, 25 Jan 2002 14:28:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0PMSkKM025825 for mobile-ip-dist; Fri, 25 Jan 2002 14:28: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 g0PMSh2Q025818 for ; Fri, 25 Jan 2002 14:28:43 -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 OAA25505 for ; Fri, 25 Jan 2002 14:28:51 -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 PAA20839 for ; Fri, 25 Jan 2002 15:28:50 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0PMUSQ01261 for ; Fri, 25 Jan 2002 16:30:28 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 25 Jan 2002 16:28:49 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Jan 2002 16:28:05 -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] Routing headers: design team recommendation Date: Fri, 25 Jan 2002 16:28:05 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD5B4@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] Routing headers: design team recommendation Thread-Index: AcGkTjfgED+oL7JMRwWrT0sI0ty+LQBoSFIw To: X-OriginalArrivalTime: 25 Jan 2002 22:28:05.0709 (UTC) FILETIME=[8EF237D0:01C1A5EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0PMSi2Q025819 Sender: owner-mobile-ip@sunroof.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 agree and am in favor of the DTs recommendation for replacing the RH with a new DO. -Basavaraj > RECOMMENDATION > ============== > > The design team is leaning towards #3 at the moment. One > reason for this is that this would remove any suspicion that firewall > administrators have for the use of the Routing Header and > which might consequently lead to disabling MIPv6 because of these > fears. Also, the firewall rules necessary to process the Routing > Header are complex and accidental disabling of MIPv6 might also > occur. The use of the Routing Header for other purposes would > also not be affected. There are also drawbacks in alternative #3. > One such issue is that existing MIPv6 implementations have to > be changed. We feel that this drawback is offset by the expected > wider usability of MIPv6 as a result. This change will also imply > a substantial document modification for the MIPv6 I-D. This > does not appear to be a structural change, however, and in > general we feel that direct procedure is easier to describe than > attempting to describe some additional rules to constrain the use > of the Routing Header. Finally, alternative #3 might lead us to > depend on the external work such as the new tunnel encapsulation > work at IPNG. The design team feels that we should stay away > from these non-MIPv6 solutions due schedule issues as well > as in the interests of making a self-contained RFC. > > --- From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 19:33:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18868 for ; Fri, 25 Jan 2002 19:33:44 -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 RAA23600; Fri, 25 Jan 2002 17:33:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07129; Fri, 25 Jan 2002 16: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 g0Q0W72Q025996 for ; Fri, 25 Jan 2002 16:32:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0Q0W7am025995 for mobile-ip-dist; Fri, 25 Jan 2002 16:32: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 g0Q0W32Q025988 for ; Fri, 25 Jan 2002 16:32:03 -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 QAA07617 for ; Fri, 25 Jan 2002 16:32:09 -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 RAA18557 for ; Fri, 25 Jan 2002 17:32:09 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA17516; Fri, 25 Jan 2002 16:32:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0Q0W3s06098; Fri, 25 Jan 2002 16:32:03 -0800 X-mProtect: Fri, 25 Jan 2002 16:32:03 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv5Ozp7; Fri, 25 Jan 2002 16:32:01 PST Message-ID: <3C51F901.65A72ED6@iprg.nokia.com> Date: Fri, 25 Jan 2002 16:32:01 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, Pekka.Nikander@nomadiclab.com CC: jari.arkko@kolumbus.fi Subject: [mobile-ip] Future attacks and threats 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, This is an effort to compile all the "future attacks". there are just too many mails and many people are not sure what exactly "future attacks" are. there are 4 future attackes as far as I can see (Pekka, please let me know if there are more). 1. described in http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf (Pekka's slides) Solution for this threat: There is one way of preventing this attack by having a check at the CN. lets assume MN1 has created a binding A (HoA) - B (CoA) at the CN. when MN2 tries to create a binding C (HoA) - A (CoA), the CN performs a check. if (bc_lookup(C) == NULL) a new binding, process it; if (bc_lookup(A) != NULL) reject binding; in the example in the slides when the target MN tries to bind 3ff0::1 to its home address, the second check would fail because the Attacker has already bound 3ff0::1 has its home address. so the scenario in slide 11 is prevented from happening. 2. described in draft-aura-mipv6-bu-attacks-00.txt For this attack to succeed, it requires an unauthenticated binding update. since any BU has to pass the return routability test, this is not a threat IMO. 3. (cut and paste from a Pekka's mail) > you can use the future attack technique for bombing too. > You physically go to your target network (or tap to a link > in between), plug in your laptop, pretend to be your own HA, > establish a binding at the CN, go away, and later let the > binding to expire. If you have active communications going > on when the binding expires (e.g. a large file transfer), > the packets start bombing to your target, and you can even > keep the TCP transfer to go on for some time by carefully > sending false ACKs. I am not sure I understand this threat correctly. if the attack is to target a network, it would work. but if you want to target a single host, it wont work. to target a single host, the attacker has to be on the same link as the target node, and it also has to pretend that it is HA, and both the CoA and HoA have to be from the same prefix (maybe I am missing something very obvious). 4. cut and paste from Pekka's mail with subject "A threat RR doesn't solve and that doesn't seem to exist in IPv4" > Let us consider an attacker A, a corrensponding node CN, and > a pre-selected mobile node MN whose home address is HoA. > Now, A has decided to steal all traffic that CN will > initiate towards MN. To do so, it somehow arranges itself > _once_ to the path between CN and MN's HA. It may do this, > for example, by visiting the network where CN is located, > where MN's HA is located, or any network in between. > > While being at the path between CN and MN's HA, the attacker > creates a binding (and a corresponding BSA) at CN. This will > succeed, since A knows MN's home address and it can foil the > RR test. As a result, CN believes that MN is currently located > at the adddress given by A, and therefor whenever it sends > packets to MN, it will send them to the attacker. Thus, A > is able to steal all connections initiated by CN towards MN. > Furthermore, if CN does not check the return routability > of the MN's home address if there is already an existing BSA, > then the attacker can keep up the faulty binding as long as it > wishes, simply by renewing the binding and BSA periodically. > To renew, it no longer needs to be at the path between the CN > and the MN's HA. I agree this is a threat that does not exist in IPv4. but this threat is too far fetched - the main reason being the attacker has to plug into the path between CN and HA. We could live with this threat. I do agree with the observation that the threats from "future attacks" can be minimized by limiting the binding lifetime (obtained by Return Routability) to a few minutes. none of the above threats are so serious that you need a potentially expensive (computationally) mechanism like CGA. IMO CGA is very useful for IPv6. it actually eliminates a few threats that exist in IPv6 protocol. proving address ownership is a big deal IMO. it also takes care of neighbor discovery threats identified in draft-kempf-ipng-netaccess-threats-00.txt to a certain extent. it SHOULD be taken up in the IPv6 WG. if I am missing something, please let me know. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jan 25 19:47:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19009 for ; Fri, 25 Jan 2002 19:47:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29617; Fri, 25 Jan 2002 17:47:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10794; Fri, 25 Jan 2002 16:47: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 g0Q0kJ2Q026096 for ; Fri, 25 Jan 2002 16:46:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0Q0kJj7026095 for mobile-ip-dist; Fri, 25 Jan 2002 16:46: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 g0Q0kG2Q026088 for ; Fri, 25 Jan 2002 16:46: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 QAA10533 for ; Fri, 25 Jan 2002 16:46:22 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24449 for ; Fri, 25 Jan 2002 17:46: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 QAA18453; Fri, 25 Jan 2002 16:46:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0Q0kGX26453; Fri, 25 Jan 2002 16:46:16 -0800 X-mProtect: Fri, 25 Jan 2002 16:46:16 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhIWx3r; Fri, 25 Jan 2002 16:46:14 PST Message-ID: <3C51FC56.31572CC1@iprg.nokia.com> Date: Fri, 25 Jan 2002 16:46:14 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Pekka.Nikander@nomadiclab.com, jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] Future attacks and threats References: <3C51F901.65A72ED6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, (2) is in sec 2.5 (Bombing CoA with Unwanted Data), draft-aura-mipv6-bu-attacks-00.txt Vijay Vijay Devarapalli wrote: > > Hi all, > > This is an effort to compile all the "future attacks". there > are just too many mails and many people are not sure what > exactly "future attacks" are. > > there are 4 future attackes as far as I can see (Pekka, please > let me know if there are more). > > 1. described in > http://www.tml.hut.fi/~pnr/presentations/IETF50-SAAG-AddrOwn-Slides.pdf > (Pekka's slides) > > Solution for this threat: > There is one way of preventing this attack by having > a check at the CN. > > lets assume > > MN1 has created a binding A (HoA) - B (CoA) at the CN. > when MN2 tries to create a binding C (HoA) - A (CoA), > the CN performs a check. > > if (bc_lookup(C) == NULL) > a new binding, process it; > if (bc_lookup(A) != NULL) > reject binding; > > in the example in the slides > > when the target MN tries to bind 3ff0::1 to its home > address, the second check would fail because the Attacker > has already bound 3ff0::1 has its home address. so the > scenario in slide 11 is prevented from happening. > > 2. described in draft-aura-mipv6-bu-attacks-00.txt > > For this attack to succeed, it requires an unauthenticated > binding update. since any BU has to pass the return > routability test, this is not a threat IMO. > > 3. (cut and paste from a Pekka's mail) > > you can use the future attack technique for bombing too. > > You physically go to your target network (or tap to a link > > in between), plug in your laptop, pretend to be your own HA, > > establish a binding at the CN, go away, and later let the > > binding to expire. If you have active communications going > > on when the binding expires (e.g. a large file transfer), > > the packets start bombing to your target, and you can even > > keep the TCP transfer to go on for some time by carefully > > sending false ACKs. > > I am not sure I understand this threat correctly. if the > attack is to target a network, it would work. but if you > want to target a single host, it wont work. to target a > single host, the attacker has to be on the same link > as the target node, and it also has to pretend that it > is HA, and both the CoA and HoA have to be from the same > prefix (maybe I am missing something very obvious). > > > 4. cut and paste from Pekka's mail with subject "A threat RR doesn't > solve and that doesn't seem to exist in IPv4" > > Let us consider an attacker A, a corrensponding node CN, and > > a pre-selected mobile node MN whose home address is HoA. > > Now, A has decided to steal all traffic that CN will > > initiate towards MN. To do so, it somehow arranges itself > > _once_ to the path between CN and MN's HA. It may do this, > > for example, by visiting the network where CN is located, > > where MN's HA is located, or any network in between. > > > > While being at the path between CN and MN's HA, the attacker > > creates a binding (and a corresponding BSA) at CN. This will > > succeed, since A knows MN's home address and it can foil the > > RR test. As a result, CN believes that MN is currently located > > at the adddress given by A, and therefor whenever it sends > > packets to MN, it will send them to the attacker. Thus, A > > is able to steal all connections initiated by CN towards MN. > > Furthermore, if CN does not check the return routability > > of the MN's home address if there is already an existing BSA, > > then the attacker can keep up the faulty binding as long as it > > wishes, simply by renewing the binding and BSA periodically. > > To renew, it no longer needs to be at the path between the CN > > and the MN's HA. > > I agree this is a threat that does not exist in IPv4. but > this threat is too far fetched - the main reason being > the attacker has to plug into the path between CN and > HA. We could live with this threat. > > I do agree with the observation that the threats from "future > attacks" can be minimized by limiting the binding lifetime > (obtained by Return Routability) to a few minutes. none of > the above threats are so serious that you need a potentially > expensive (computationally) mechanism like CGA. IMO CGA is > very useful for IPv6. it actually eliminates a few threats > that exist in IPv6 protocol. proving address ownership is > a big deal IMO. it also takes care of neighbor discovery > threats identified in draft-kempf-ipng-netaccess-threats-00.txt > to a certain extent. it SHOULD be taken up in the IPv6 WG. > > if I am missing something, please let me know. > > regards > Vijay From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 26 09:04: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 JAA07091 for ; Sat, 26 Jan 2002 09:04: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 HAA28005; Sat, 26 Jan 2002 07:04: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 GAA00519; Sat, 26 Jan 2002 06:04: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 g0QE2t2Q026737 for ; Sat, 26 Jan 2002 06:02:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0QE2tDA026736 for mobile-ip-dist; Sat, 26 Jan 2002 06:02: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 g0QE2p2Q026729 for ; Sat, 26 Jan 2002 06:02: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 GAA29891 for ; Sat, 26 Jan 2002 06:02:56 -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 HAA27745 for ; Sat, 26 Jan 2002 07:02:55 -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 g0QE2r513487 for ; Sat, 26 Jan 2002 15:02:53 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA13037 for ; Sat, 26 Jan 2002 15:02:53 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0QE2rg21740 for ; Sat, 26 Jan 2002 15:02:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201261402.g0QE2rg21740@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) In-reply-to: Your message of Fri, 25 Jan 2002 09:35:21 PST. <3C519759.C70EC3D3@iprg.nokia.com> Date: Sat, 26 Jan 2002 15:02:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I agree with the Design Team's recommendation. And I would prefer changing it to a destination option. (True Destination Address??) >... Agree completely on the last point. and going by the last point, a destination option seems to be the best thing to do (IMO). => a new destination option doesn't work well for a mobile router. IMHO we should keep the "routing" element from Routing Headers (so I am still in favour of either a new type of RH or Steve Deering's special cases of tunnels. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 26 09:29:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07408 for ; Sat, 26 Jan 2002 09:29: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 HAA01991; Sat, 26 Jan 2002 07:29:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24455; Sat, 26 Jan 2002 06:29:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0QES92Q026828 for ; Sat, 26 Jan 2002 06:28:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0QES9cA026827 for mobile-ip-dist; Sat, 26 Jan 2002 06:28:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0QES52Q026820 for ; Sat, 26 Jan 2002 06:28:06 -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 GAA16556 for ; Sat, 26 Jan 2002 06:28:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08987 for ; Sat, 26 Jan 2002 07:28:05 -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 g0QES3514835 for ; Sat, 26 Jan 2002 15:28:03 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA13293 for ; Sat, 26 Jan 2002 15:28:03 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0QES3g21893 for ; Sat, 26 Jan 2002 15:28:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201261428.g0QES3g21893@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Fri, 25 Jan 2002 16:28:05 CST. <697DAA22C5004B4596E033803A7CEF444CD5B4@daebe007.NOE.Nokia.com> Date: Sat, 26 Jan 2002 15:28:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I agree and am in favor of the DTs recommendation for replacing the RH with a new DO. => another argument about a new Destination Option: - if we don't specify where to put the DO we'll get a mess - if we specify the DO must be before any IPsec header (same case than current HAO) we have no difference with a new RH type, only more complexity... - if we specify the DO must be after any IPsec header in order to be able to protect it using ESP for instance, we'll mess the SADB lookup which is done using the destination address. IMHO we should only conclude we'd like a new mechanism and let the choice to the IPv6 WG (this will give us more time for other points too). Regards Francis.Dupont@enst-bretagne.fr PS: no mechanism has an advantage for efficiency, all are 24 byte long. From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 26 10:22: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 KAA07812 for ; Sat, 26 Jan 2002 10:22:10 -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 HAA20248; Sat, 26 Jan 2002 07:21:53 -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 HAA19426; Sat, 26 Jan 2002 07:21: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 g0QFKf2Q026994 for ; Sat, 26 Jan 2002 07:20:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0QFKfVh026993 for mobile-ip-dist; Sat, 26 Jan 2002 07:20: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 g0QFKc2Q026986 for ; Sat, 26 Jan 2002 07:20:38 -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 HAA02839 for ; Sat, 26 Jan 2002 07:20:41 -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 IAA17725 for ; Sat, 26 Jan 2002 08:20:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0QFKb516976; Sat, 26 Jan 2002 16:20:37 +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 QAA13891; Sat, 26 Jan 2002 16:20:38 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0QFKbg22272; Sat, 26 Jan 2002 16:20:37 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201261520.g0QFKbg22272@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Pekka.Nikander@nomadiclab.com, jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] Future attacks and threats In-reply-to: Your message of Fri, 25 Jan 2002 16:32:01 PST. <3C51F901.65A72ED6@iprg.nokia.com> Date: Sat, 26 Jan 2002 16:20:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: This is an effort to compile all the "future attacks". there are just too many mails and many people are not sure what exactly "future attacks" are. => this is not a comment about the remainder of this message but on principles: these "future attacks" should be clearly documented into the threat model document aka draft-ietf-mobileip-mipv6-scrty-reqts-xx.txt of course if they are not yet. BTW it seems there are more than 4 issues... Regards Francis.Dupont@enst-bretagne.fr PS: this is not against you, if this is not done soon the pressure should be put on authors of security requirements. From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 26 20:59: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 UAA13181 for ; Sat, 26 Jan 2002 20:59: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 RAA10925; Sat, 26 Jan 2002 17:59:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21008; Sat, 26 Jan 2002 17:58:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0R1vv2Q027494 for ; Sat, 26 Jan 2002 17:57:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0R1vv41027493 for mobile-ip-dist; Sat, 26 Jan 2002 17: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0R1vs2Q027486 for ; Sat, 26 Jan 2002 17:57:54 -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 RAA21409 for ; Sat, 26 Jan 2002 17:58:00 -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 RAA21858 for ; Sat, 26 Jan 2002 17:57:59 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA27870 for ; Sat, 26 Jan 2002 17:57:59 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0R1vxf20488 for ; Sat, 26 Jan 2002 17:57:59 -0800 X-mProtect: Sat, 26 Jan 2002 17:57:59 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdtfzNBO; Sat, 26 Jan 2002 17:57:57 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 RAA47000 for ; Sat, 26 Jan 2002 17:57:57 -0800 (PST) Message-ID: <3C535EA5.B7743563@iprg.nokia.com> Date: Sat, 26 Jan 2002 17:57:57 -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: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: <200201261428.g0QES3g21893@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: > > => another argument about a new Destination Option: > - if we don't specify where to put the DO we'll get a mess Agreed, the spec needs to tell where it is. > - if we specify the DO must be before any IPsec header (same > case than current HAO) we have no difference with a new RH type, > only more complexity... Hmm.. both use a known header type and are resolved in the next octet (RH type or DO type). For packet input these seem equally complex. If it really is the case FW admins do not want any RHs in their domains, it may be administratively simpler let them drop RHs and use another known header. Then they do not need to worry so much details of this part of IPv6 :-) A downside is that this is then a confession RHs cannot be used too much. If the FW admin constraint is considered important, I tend to favor the use of a DO near the place of current HAO. > - if we specify the DO must be after any IPsec header in order > to be able to protect it using ESP for instance, we'll mess > the SADB lookup which is done using the destination address. > > IMHO we should only conclude we'd like a new mechanism and let > the choice to the IPv6 WG (this will give us more time for other > points too). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: no mechanism has an advantage for efficiency, all are 24 byte long. Agreed. BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Jan 26 23:26: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 XAA16338 for ; Sat, 26 Jan 2002 23:26: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 VAA16890; Sat, 26 Jan 2002 21:26: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 UAA05446; Sat, 26 Jan 2002 20:26: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 g0R4P42Q027819 for ; Sat, 26 Jan 2002 20:25:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0R4P4Wh027818 for mobile-ip-dist; Sat, 26 Jan 2002 20:25: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 g0R4Ox2Q027811 for ; Sat, 26 Jan 2002 20:25:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14082 for ; Sat, 26 Jan 2002 20:25:04 -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 UAA07179 for ; Sat, 26 Jan 2002 20:25: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 UAA01341 for ; Sat, 26 Jan 2002 20:25:04 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0R4P3a17195 for ; Sat, 26 Jan 2002 20:25:03 -0800 X-mProtect: Sat, 26 Jan 2002 20:25:03 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdAwOifZ; Sat, 26 Jan 2002 20:25: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 UAA47163 for ; Sat, 26 Jan 2002 20:25:01 -0800 (PST) Message-ID: <3C53811D.166142FC@iprg.nokia.com> Date: Sat, 26 Jan 2002 20:25:01 -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: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: <200201261428.g0QES3g21893@givry.rennes.enst-bretagne.fr> <3C535EA5.B7743563@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 > > Regards > > > > Francis.Dupont@enst-bretagne.fr > > > > PS: no mechanism has an advantage for efficiency, all are 24 byte long. > > Agreed. ..that there should be no significant difference in protocol message efficiency. BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 27 10:02: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 KAA00293 for ; Sun, 27 Jan 2002 10:02:49 -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 IAA11985; Sun, 27 Jan 2002 08:02:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15829; Sun, 27 Jan 2002 07:01: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 g0RF0J2Q028398 for ; Sun, 27 Jan 2002 07:00:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0RF0JAw028397 for mobile-ip-dist; Sun, 27 Jan 2002 07:00:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0RF0G2Q028390 for ; Sun, 27 Jan 2002 07:00:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21840 for ; Sun, 27 Jan 2002 07:00:27 -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 IAA18599 for ; Sun, 27 Jan 2002 08:00:26 -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 g0RF0K516189 for ; Sun, 27 Jan 2002 16:00: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 QAA23712 for ; Sun, 27 Jan 2002 16:00:21 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0RF0Kg24637 for ; Sun, 27 Jan 2002 16:00:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201271500.g0RF0Kg24637@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Sat, 26 Jan 2002 17:57:57 PST. <3C535EA5.B7743563@iprg.nokia.com> Date: Sun, 27 Jan 2002 16:00:20 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > - if we specify the DO must be before any IPsec header (same > case than current HAO) we have no difference with a new RH type, > only more complexity... Hmm.. both use a known header type and are resolved in the next octet (RH type or DO type). For packet input these seem equally complex. If it really is the case FW admins do not want any RHs in their domains, it may be administratively simpler let them drop RHs and use another known header. => in fact you'll force firewalls to scan DOs... I prefer to use another RH type in order to make the decision easy (IMHO this feature is a routing one so a RH has to be used). I have some arguments in favour of the routing basis of this feature: - the first one is the special case of a tunnel, i.e. this feature is an optimization of a tunnel where the inner and the outer sources are the same (so only destination addresses are needed). - if the end of the tunnel is a mobile router, the final destination is behind the router so a DO doesn't work (the missing thing is the capacity of a RH to advance from an intermediate destination to the next one). - if you implement ingress filtering based on unicast RPF, you have to deal with two cases: * internal forwarded packets (M_LOOP flag in KAME) which should be always accepted. * for other packets you take the source, compute the route to it and verify the route is through the input interface of the packet. The source is in the IPv6 header if there is no routing header: with a routing header the source is the last intermediate router (the segleft + 1 field when there is one). To refuse to accept this routing basis should give only confusion and extra complexity. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun Jan 27 17:51: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 RAA04347 for ; Sun, 27 Jan 2002 17:51:19 -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 OAA14341; Sun, 27 Jan 2002 14:50:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17165; Sun, 27 Jan 2002 14:50: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 g0RMnY2Q028975 for ; Sun, 27 Jan 2002 14:49:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0RMnYLP028974 for mobile-ip-dist; Sun, 27 Jan 2002 14:49: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 g0RMnV2Q028967 for ; Sun, 27 Jan 2002 14:49:31 -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 OAA20692 for ; Sun, 27 Jan 2002 14:49:43 -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 PAA18289 for ; Sun, 27 Jan 2002 15:49:42 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0RMnfP09318; Mon, 28 Jan 2002 00:49:41 +0200 Date: Mon, 28 Jan 2002 00:49:40 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] Re: Routing headers (ISSUE) In-Reply-To: <3C51430C.4CE642DB@lmf.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: On Fri, 25 Jan 2002, Jari Arkko wrote: > >Currently some IPv6 implementations don't safely deal with RH, > >for instance they blindly forward by default packets with RH > >in the host mode. The IPv6 WG should warn ASAP implementers > >that RFC 1122 section 3.3.5 security considerations apply > >without possible harm to Mobile IPv6 (fine consequence of approch #3). > >I don't know how this recommendation should be broadcasted. > > Right. Perhaps we can make a some sort of announcement > somewhere, but little further down the road this recommendation > must find itself to the IPv6 host requirements document. I can make a very short draft (~2 pages including the disclaimers :-) on the issue before IETF53 as a placeholder until the requirements draft appears, and if ipv6wg deems it appropriate, present the issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 01:30: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 BAA10929 for ; Mon, 28 Jan 2002 01:30: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 WAA16611; Sun, 27 Jan 2002 22:30:34 -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 WAA02097; Sun, 27 Jan 2002 22:30:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0S6TK2Q029310 for ; Sun, 27 Jan 2002 22:29:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0S6TKbg029309 for mobile-ip-dist; Sun, 27 Jan 2002 22:29:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0S6TH2Q029302 for ; Sun, 27 Jan 2002 22:29:17 -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 WAA13427 for ; Sun, 27 Jan 2002 22:29:31 -0800 (PST) Received: from WS0005.indiatimes.com ([203.199.93.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03323 for ; Sun, 27 Jan 2002 22:29:29 -0800 (PST) Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id LAA31623 for ; Mon, 28 Jan 2002 11:49:47 +0530 From: "Nitin" Message-Id: <200201280619.LAA31623@WS0005.indiatimes.com> To: Subject: [mobile-ip] which draft should be used Date: Mon, 28 Jan 2002 11:47:08 +0530 X-URL: http://indiatimes.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_MAILER_ATTACH_BOUNDARY_20021281114781631518149" Sender: owner-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_BOUNDARY_20021281114781631518149 Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2002128111478200747796" --=_MAILER_ATTACH_BOUNDARY1_2002128111478200747796 Content-Type: text/plain; charset=us-ascii Message from nitinkumars@indiatimes.com Forwarded as attachment 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_2002128111478200747796 Content-Type: text/html; charset=us-ascii
Message from nitinkumars@indiatimes.com Forwarded as attachment
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_2002128111478200747796-- --=_MAILER_ATTACH_BOUNDARY_20021281114781631518149 Content-Type: message/rfc822 From: "Nitin" Full-Name: "Nitin" To: Reply-To: nitinkumars@indiatimes.com Subject: which draft should be used Date: Mon, 28 Jan 2002 11:34:27 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200212811134271843993368" MIME-Version: 1.0 --=_MAILER_ATTACH_BOUNDARY1_200212811134271843993368 Content-type: text/plain; charset="us-ascii" Hi I am writing the code for IPv6 Lite fot Host only. The draft "mobility support in Ipv6" is expired on Jan2. We r going to implement dual (ipv4 and ipv6) stack. Do we have to support Tunneling also (its host only implementation) ? Some where i have read that these two r different methods. Regards Nitin 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_200212811134271843993368 Content-type: text/html; charset="us-ascii"

Hi

  I am writing the code for IPv6 Lite fot Host only. The draft "mobility support in Ipv6" is expired on Jan2.

We r going to implement dual (ipv4 and ipv6) stack. Do we have to support Tunneling also (its host only implementation) ? Some where i have read that these two r different methods.

Regards

Nitin

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_200212811134271843993368-- --=_MAILER_ATTACH_BOUNDARY_20021281114781631518149-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 01:54: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 BAA11110 for ; Mon, 28 Jan 2002 01:54:58 -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 WAA20519; Sun, 27 Jan 2002 22:54:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA06471; Sun, 27 Jan 2002 22:54: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 g0S6rc2Q029366 for ; Sun, 27 Jan 2002 22:53:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0S6rcTc029365 for mobile-ip-dist; Sun, 27 Jan 2002 22:53: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 g0S6rZ2Q029358 for ; Sun, 27 Jan 2002 22:53:35 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA06331 for ; Sun, 27 Jan 2002 22:53:47 -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 WAA12569 for ; Sun, 27 Jan 2002 22:53: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 WAA10227 for ; Sun, 27 Jan 2002 22:53:47 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0S6rkP16576 for ; Sun, 27 Jan 2002 22:53:46 -0800 X-mProtect: Sun, 27 Jan 2002 22:53:46 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdvilgYx; Sun, 27 Jan 2002 22:53:45 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 WAA50047 for ; Sun, 27 Jan 2002 22:53:45 -0800 (PST) Message-ID: <3C54F579.71924950@iprg.nokia.com> Date: Sun, 27 Jan 2002 22:53:45 -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: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: <200201271500.g0RF0Kg24637@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: > > > - if we specify the DO must be before any IPsec header (same > > case than current HAO) we have no difference with a new RH > > only more complexity... > > Hmm.. both use a known header type and are resolved in the next > octet (RH type or DO type). For packet input these seem equally > complex. If it really is the case FW admins do not want any RHs > in their domains, it may be administratively simpler let them > drop RHs and use another known header. > > => in fact you'll force firewalls to scan DOs... Wouldn't this depend on whether there is a reason to block MIPv6-specific traffic, which we hopefully after all these changes shouldn't have? A Destination Header, on the other hand, can already be skipped. So I suspect this does not automatically force this scanning, one may want to do it for other reasons, though. And, since a HAO is a DO, it would make the situation "symmetric". Also, the discussions demonstrate how many subtle issues there are, hence a mobility-specific "end node tunneling" option should isolate the mobility case from unforeseen problems (security etc) present in options that have more generic uses. Mobility-specific extra limitations to processing could be added in the future without jeopardizing other uses or adding semantical confusion. It's a compromise. > I prefer to use > another RH type in order to make the decision easy (IMHO this > feature is a routing one so a RH has to be used). > I have some arguments in favour of the routing basis of this > feature: > - the first one is the special case of a tunnel, i.e. this feature > is an optimization of a tunnel where the inner and the outer > sources are the same (so only destination addresses are needed). Seems like it, yes, though this might be considered a semantical difference rather than something where the actual format matters. > - if the end of the tunnel is a mobile router, the final > destination is behind the router so a DO doesn't work (the > missing thing is the capacity of a RH to advance from an > intermediate destination to the next one). I agree here but want to mention that this applies only to a route-optimized or triangle mobile router case, another way of doing it without this affecting is discussed in a draft, http://search.ietf.org/internet-drafts/draft-kniveton-mobrtr-00.txt with the use of bidirectional tunneling. If MN is the initiator of connection, it can even with the current MIPv6 draft use bidir tunneling, a MN is not mandated to insert HAOs. So DO is not a showstopper for mobile routers, in some cases it may be a limitation. It is, however, not well understood, if RH-based mobile routing to middle nodes securitywise is desired. But you have a point here, "end node tunneling" causes a limitation to some speculative future scenarios of optimized routing. > - if you implement ingress filtering based on unicast RPF, you > have to deal with two cases: > * internal forwarded packets (M_LOOP flag in KAME) which should > be always accepted. > * for other packets you take the source, compute the route to it > and verify the route is through the input interface of the > packet. > The source is in the IPv6 header if there is no routing header: > with a routing header the source is the last intermediate > router (the segleft + 1 field when there is one). > To refuse to accept this routing basis should give only confusion > and extra complexity. I agree there is a routing basis and that it is a compromise with a possibility for some extra confusion both ways. To not go beyond this I just conclude that I do not have a strong position either way, both RH type 2 and new DO have their pros and cons and both seem doable. > Regards > > Francis.Dupont@enst-bretagne.fr BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 03:58: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 DAA20596 for ; Mon, 28 Jan 2002 03:58: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 BAA06291; Mon, 28 Jan 2002 01:58: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 AAA10879; Mon, 28 Jan 2002 00: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 g0S8uS2Q029772 for ; Mon, 28 Jan 2002 00:56:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0S8uSYc029771 for mobile-ip-dist; Mon, 28 Jan 2002 00: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 g0S8uP2Q029764 for ; Mon, 28 Jan 2002 00:56:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29389 for ; Mon, 28 Jan 2002 00:56:41 -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 BAA04570 for ; Mon, 28 Jan 2002 01:56:37 -0700 (MST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id AF9CAA; Mon, 28 Jan 2002 10:57:23 +0200 (EET) Message-ID: <3C551217.6030108@nomadiclab.com> Date: Mon, 28 Jan 2002 10:55:51 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, Erik Nordmark , James Kempf Subject: [mobile-ip] Re: Future attacks and threats References: <3C51F901.65A72ED6@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, > This is an effort to compile all the "future attacks". there > are just too many mails and many people are not sure what > exactly "future attacks" are. > > there are 4 future attackes as far as I can see (Pekka, please > let me know if there are more). Thanks for compiling this list. Right now (Monday morning and I still haven't had my coffee) I can't right away thing about additional future attacks, but I am pretty sure that there are others, too. That is, as far as I know, nobody has tried to perform a rigorious analysis on the area. The basic mechanisms is well understood, though. The basic idea in all the future attacks is that you create a false binding, and use it then to launch some kind of attack in the future. Depending on the protections involved, creating the false binding may be easier or harder, and therefore the risks created by a particular attack scenario depend on the protections applied. What makes the future attacks perhaps more devious than the other attacks is that the attacker can select the _time_ when to establish the false binding. In other types of attacks, the attacker usually has to wait for the the target node or network to talk to a CN, or in other ways must be able to wait for the right time to launch the attack. In the future attacks usually not so; the preparations can be done beforehand, e.g. in the night when the target MN is likely to be off-line. > I do agree with the observation that the threats from "future > attacks" can be minimized by limiting the binding lifetime > (obtained by Return Routability) to a few minutes. none of > the above threats are so serious that you need a potentially > expensive (computationally) mechanism like CGA. I tend to agree, at least in the light of my current understanding. The residual threats left after applying two-way-RR (both towards the CoA and HoA) and limiting the binding lifetime to a few minitutes _seem_ to be small enough that we can accept them. It is important to understand, though, that the lifetime limitation is a very essential element here. RR is needed to limit the _place_ of the attacker; to succeed, the attacker must somehow get into the vulnerable spots in RR, i.e. at the MN link, HA link, CN link, or a path between the MN and CN or CN and HA, depending on the attack. The lifetime limitation is needed to limit the _time_ when the attacker can prepare for the attack. Without this time limitation, the attacker could prepare hours or even days before the actual attack. The lifetime limitation brings back this to something reasonable, i.e. minutes. > IMO CGA is > very useful for IPv6. it actually eliminates a few threats > that exist in IPv6 protocol. proving address ownership is > a big deal IMO. it also takes care of neighbor discovery > threats identified in draft-kempf-ipng-netaccess-threats-00.txt > to a certain extent. it SHOULD be taken up in the IPv6 WG. I tend to agree here, too. However, since the scope of the problem is fairly limited, MAYBE it would be better to split off a new WG from IPv6 WG, prepare solutions there, and then bring them back to the IPv6 WG. I don't just know. Could you, Vijay, raise this issue with Bob and Steve? I know that at least Erik (Nordmark) and James (Kempf) are very keen on seeing something to happen in that area. --Pekka From chcho@hosim.kwangju.ac.kr Mon Jan 28 04:03: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 EAA20807 for ; Mon, 28 Jan 2002 04:03: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 BAA18497; Mon, 28 Jan 2002 01:03: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 BAA12402; Mon, 28 Jan 2002 01:03:15 -0800 (PST) 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 g0S91k2Q029837 for ; Mon, 28 Jan 2002 01:01:46 -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 BAA16392 for ; Mon, 28 Jan 2002 01:02:03 -0800 (PST) Received: from hosim.kwangju.ac.kr ([202.30.35.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA06459 for ; Mon, 28 Jan 2002 02:02:00 -0700 (MST) Received: from HOST ([203.246.91.26]) by hosim.kwangju.ac.kr (8.12.1/8.12.1) with SMTP id g0S92wvk025453 for ; Mon, 28 Jan 2002 18:02:58 +0900 (KST) Date: Mon, 28 Jan 2002 18:02:58 +0900 (KST) From: chcho Message-Id: <200201280902.g0S92wvk025453@hosim.kwangju.ac.kr> To: mobile-ip-dist@sunroof.eng.sun.com Subject: new photos from my party! Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I```````````````````````````````````````````````````````% end From EXCHSRV-ENG-SA@cosinecom.com Mon Jan 28 04:06: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 EAA20890 for ; Mon, 28 Jan 2002 04:06: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 CAA10386; Mon, 28 Jan 2002 02:06: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 BAA13291; Mon, 28 Jan 2002 01:05:47 -0800 (PST) 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 g0S94F2Q029868 for ; Mon, 28 Jan 2002 01:04:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00872 for ; Mon, 28 Jan 2002 01:04:22 -0800 (PST) Received: from exchsrv2.cosinecom.com (proxy127.cosinecom.com [63.88.104.127]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15242 for ; Mon, 28 Jan 2002 02:04:22 -0700 (MST) Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 01:03:54 -0800 Message-ID: <69BCCDDC980B4641BFC908D7BF95F184DD1D5E@exchsrv-eng> From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 01:04:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A7DA.C3D4D920" 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_01C1A7DA.C3D4D920 Content-Type: text/plain ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = chcho@hosim.kwangju.ac.kr Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 01:04:15 Action on virus found: The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55140e4.com_. Warning to recipient. ScanMail has detected a virus sent to you from chcho@hosim.kwangju.ac.kr on 01/28/2002 at 01:04 AM with a subject of new photos from my party!.##################################################################### ################################# This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## ------_=_NextPart_001_01C1A7DA.C3D4D920 Content-Type: text/html Content-Transfer-Encoding: quoted-printable ScanMail Message: To Recipient virus found and action = taken.

ScanMail for Microsoft Exchange has detected = virus-infected attachment(s).

Sender =3D chcho@hosim.kwangju.ac.kr
Recipient(s) =3D = mobile-ip-dist@sunroof.eng.sun.com
Subject =3D new photos from my party!
Scanning Time =3D 01/28/2002 01:04:15

Action on virus found:
The attachment www.myparty.yahoo.com exists = WORM_MYPARTY.A virus. ScanMail has Moved it.  The attachment was = moved to C:\Program = Files\Trend\Smex\Virus\www.myparty.yahoo3c55140e4.com_.

Warning to recipient. ScanMail has detected a virus = sent to you from chcho@hosim.kwangju.ac.kr on 01/28/2002 at 01:04 AM = with a subject of new photos from my party!.###############################################################= ####################################### This email communication may = contain CONFIDENTIAL INFORMATION and is intended only for the use of = the intended recipients identified above.  If you are not the = intended recipient of this communication, you must not use, disclose, = distribute, copy or print this email. If you have received this = communication in error, please immediately notify the sender by reply = email, delete the communication and destroy all copies. = ########################################################################= ##############################

------_=_NextPart_001_01C1A7DA.C3D4D920-- From LEO-SA@sony.de Mon Jan 28 04:07: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 EAA20924 for ; Mon, 28 Jan 2002 04:07: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 BAA19810; Mon, 28 Jan 2002 01:06:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13443; Mon, 28 Jan 2002 01:06:18 -0800 (PST) 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 g0S94X2Q029870 for ; Mon, 28 Jan 2002 01:04:34 -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 BAA29368 for ; Mon, 28 Jan 2002 01:04:50 -0800 (PST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17006 for ; Mon, 28 Jan 2002 01:04:49 -0800 (PST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id KAA12830 for ; Mon, 28 Jan 2002 10:04:48 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 10:04:48 +0100 Message-ID: From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Mon, 28 Jan 2002 10:03:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = chcho Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 10:03:03 Engine/Pattern = 5.630-1025/207 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c5513c773.com_. Warning to recipient. ScanMail has detected a virus. From LEO-SA@sony.de Mon Jan 28 04:10: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 EAA21011 for ; Mon, 28 Jan 2002 04:10:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA21008; Mon, 28 Jan 2002 01:10: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 BAA14856; Mon, 28 Jan 2002 01:10:07 -0800 (PST) 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 g0S96t2Q029896 for ; Mon, 28 Jan 2002 01:06:55 -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 BAA13894 for ; Mon, 28 Jan 2002 01:07:12 -0800 (PST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16121 for ; Mon, 28 Jan 2002 02:07:10 -0700 (MST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id KAA12846 for ; Mon, 28 Jan 2002 10:07:04 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 10:07:04 +0100 Message-ID: From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Mon, 28 Jan 2002 10:05:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = chcho Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 10:05:20 Engine/Pattern = 5.630-1025/207 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c55145074.com_. Warning to recipient. ScanMail has detected a virus. From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 04:14: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 EAA21074 for ; Mon, 28 Jan 2002 04:14:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14445; Mon, 28 Jan 2002 02:13: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 BAA15598; Mon, 28 Jan 2002 01:13: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 g0S9Ch2Q029928 for ; Mon, 28 Jan 2002 01:12:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0S9Ch3u029927 for mobile-ip-dist; Mon, 28 Jan 2002 01:12: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 g0S9Ce2Q029920 for ; Mon, 28 Jan 2002 01:12: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 BAA21980 for ; Mon, 28 Jan 2002 01:12:57 -0800 (PST) Received: from pusren01.risti.telkom.co.id (pusren01.risti.telkom.co.id [202.134.2.61]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10232 for ; Mon, 28 Jan 2002 01:12:00 -0800 (PST) Received: from rtimail01.telkom.go.id (rtimail01.telkom.go.id [10.14.0.29]) by pusren01.risti.telkom.co.id (8.9.1/8.9.1) with ESMTP id QAA07543 for ; Mon, 28 Jan 2002 16:17:33 +0700 (JVT) Received: by rtimail01.telkom.go.id with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 16:08:17 +0700 Message-ID: From: Beny T To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] FW: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 16:08:09 +0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A7DB.4E7D1060" Sender: owner-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_01C1A7DB.4E7D1060 Content-Type: text/plain; charset="iso-8859-1" be carefull !! -----Original Message----- From: System Attendant [mailto:EXCHSRV-ENG-SA@cosinecom.com] Sent: 28 Januari 2002 16:04 To: 'mobile-ip-dist@sunroof.eng.sun.com' Subject: ScanMail Message: To Recipient virus found and action taken. ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = chcho@hosim.kwangju.ac.kr Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 01:04:15 Action on virus found: The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55140e4.com_. Warning to recipient. ScanMail has detected a virus sent to you from chcho@hosim.kwangju.ac.kr on 01/28/2002 at 01:04 AM with a subject of new photos from my party!.##################################################################### ################################# This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## ------_=_NextPart_001_01C1A7DB.4E7D1060 Content-Type: text/html; charset="iso-8859-1" ScanMail Message: To Recipient virus found and action taken.
be carefull !!
 
-----Original Message-----
From: System Attendant [mailto:EXCHSRV-ENG-SA@cosinecom.com]
Sent: 28 Januari 2002 16:04
To: 'mobile-ip-dist@sunroof.eng.sun.com'
Subject: ScanMail Message: To Recipient virus found and action taken.

ScanMail for Microsoft Exchange has detected virus-infected attachment(s).

Sender = chcho@hosim.kwangju.ac.kr
Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com
Subject = new photos from my party!
Scanning Time = 01/28/2002 01:04:15

Action on virus found:
The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it.  The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55140e4.com_.

Warning to recipient. ScanMail has detected a virus sent to you from chcho@hosim.kwangju.ac.kr on 01/28/2002 at 01:04 AM with a subject of new photos from my party!.###################################################################################################### This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above.  If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ######################################################################################################

------_=_NextPart_001_01C1A7DB.4E7D1060-- From chcho@hosim.kwangju.ac.kr Mon Jan 28 06:38: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 GAA22456 for ; Mon, 28 Jan 2002 06:38:03 -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 DAA13853; Mon, 28 Jan 2002 03:37:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29370; Mon, 28 Jan 2002 03:37:20 -0800 (PST) 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 g0SBaH2Q000417 for ; Mon, 28 Jan 2002 03:36:17 -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 DAA16200 for ; Mon, 28 Jan 2002 03:36:32 -0800 (PST) Received: from hosim.kwangju.ac.kr ([202.30.35.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27266 for ; Mon, 28 Jan 2002 04:36:29 -0700 (MST) Received: from HOST ([203.246.91.26]) by hosim.kwangju.ac.kr (8.12.1/8.12.1) with SMTP id g0SBbSvk028759 for ; Mon, 28 Jan 2002 20:37:28 +0900 (KST) Date: Mon, 28 Jan 2002 20:37:28 +0900 (KST) From: chcho Message-Id: <200201281137.g0SBbSvk028759@hosim.kwangju.ac.kr> To: mobile-ip-dist@sunroof.eng.sun.com Subject: new photos from my party! Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I```````````````````````````````````````````````````````% end From ANTIGEN_SAPXCH01@alleghenypower.com Mon Jan 28 06:39:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22474 for ; Mon, 28 Jan 2002 06:39:11 -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 DAA14270; Mon, 28 Jan 2002 03:38:50 -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 DAA29624; Mon, 28 Jan 2002 03:38:44 -0800 (PST) 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 g0SBbk2Q000434 for ; Mon, 28 Jan 2002 03:37:47 -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 DAA00796 for ; Mon, 28 Jan 2002 03:38:02 -0800 (PST) Received: from viper1.alleghenypower.com (viper1.alleghenypower.com [63.68.200.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27957 for ; Mon, 28 Jan 2002 04:37:58 -0700 (MST) Received: from viper1.alleghenypower.com (root@localhost) by viper1.alleghenypower.com with ESMTP id g0SBbvq10742 for ; Mon, 28 Jan 2002 06:37:57 -0500 (EST) Received: from sapxch01.corp.commenergy.com (sapxch01.alleghenypower.com [10.83.181.21]) by viper1.alleghenypower.com with ESMTP id g0SBbv710737 for ; Mon, 28 Jan 2002 06:37:57 -0500 (EST) Received: by sapxch01.corp.commenergy.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 06:37:57 -0500 Message-ID: From: ANTIGEN_SAPXCH01 To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: Antigen found =*.com file Date: Mon, 28 Jan 2002 06:37:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Antigen for Exchange found www.myparty.yahoo.com matching =*.com file filter. The file is currently Removed. The message, "new photos from my party!", was sent from chcho and was discovered in Rakers, Jason\Inbox located at Allegheny Power/EXCHANGE1/SAPXCH01. From LEO-SA@sony.de Mon Jan 28 06:39:45 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22501 for ; Mon, 28 Jan 2002 06:39:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28694; Mon, 28 Jan 2002 04:39:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29788; Mon, 28 Jan 2002 03:39:24 -0800 (PST) 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 g0SBcC2Q000445 for ; Mon, 28 Jan 2002 03:38:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18713 for ; Mon, 28 Jan 2002 03:38:28 -0800 (PST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27833 for ; Mon, 28 Jan 2002 04:38:26 -0700 (MST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id MAA14368 for ; Mon, 28 Jan 2002 12:38:20 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:38:20 +0100 Message-ID: From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Mon, 28 Jan 2002 12:36:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = chcho Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 12:36:37 Engine/Pattern = 5.630-1025/207 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c5537c578.com_. Warning to recipient. ScanMail has detected a virus. From EXCHSRV-ENG-SA@cosinecom.com Mon Jan 28 06: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 GAA22513 for ; Mon, 28 Jan 2002 06:39: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 DAA14590; Mon, 28 Jan 2002 03:39:26 -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 DAA29759; Mon, 28 Jan 2002 03:39:18 -0800 (PST) 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 g0SBc52Q000436 for ; Mon, 28 Jan 2002 03:38:05 -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 DAA16309 for ; Mon, 28 Jan 2002 03:38:21 -0800 (PST) Received: from exchsrv2.cosinecom.com (proxy127.cosinecom.com [63.88.104.127]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17491 for ; Mon, 28 Jan 2002 04:38:21 -0700 (MST) Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 03:37:54 -0800 Message-ID: <69BCCDDC980B4641BFC908D7BF95F184DD1D6D@exchsrv-eng> From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 03:38:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A7F0.47326840" 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_01C1A7F0.47326840 Content-Type: text/plain ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = chcho@hosim.kwangju.ac.kr Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 03:38:14 Action on virus found: The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c5538268.com_. Warning to recipient. ScanMail has detected a virus sent to you from chcho@hosim.kwangju.ac.kr on 01/28/2002 at 03:38 AM with a subject of new photos from my party!.##################################################################### ################################# This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## ------_=_NextPart_001_01C1A7F0.47326840 Content-Type: text/html Content-Transfer-Encoding: quoted-printable ScanMail Message: To Recipient virus found and action = taken.

ScanMail for Microsoft Exchange has detected = virus-infected attachment(s).

Sender =3D chcho@hosim.kwangju.ac.kr
Recipient(s) =3D = mobile-ip-dist@sunroof.eng.sun.com
Subject =3D new photos from my party!
Scanning Time =3D 01/28/2002 03:38:14

Action on virus found:
The attachment www.myparty.yahoo.com exists = WORM_MYPARTY.A virus. ScanMail has Moved it.  The attachment was = moved to C:\Program = Files\Trend\Smex\Virus\www.myparty.yahoo3c5538268.com_.

Warning to recipient. ScanMail has detected a virus = sent to you from chcho@hosim.kwangju.ac.kr on 01/28/2002 at 03:38 AM = with a subject of new photos from my party!.###############################################################= ####################################### This email communication may = contain CONFIDENTIAL INFORMATION and is intended only for the use of = the intended recipients identified above.  If you are not the = intended recipient of this communication, you must not use, disclose, = distribute, copy or print this email. If you have received this = communication in error, please immediately notify the sender by reply = email, delete the communication and destroy all copies. = ########################################################################= ##############################

------_=_NextPart_001_01C1A7F0.47326840-- From Postmaster@JRC.Co.Jp Mon Jan 28 06:42:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22573 for ; Mon, 28 Jan 2002 06:42:31 -0500 (EST) From: Postmaster@JRC.Co.Jp Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29973; Mon, 28 Jan 2002 04:42:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00421; Mon, 28 Jan 2002 03:42:06 -0800 (PST) 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 g0SBfC2Q000464 for ; Mon, 28 Jan 2002 03:41:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16544 for ; Mon, 28 Jan 2002 03:41:28 -0800 (PST) Received: from inet11.jrc.co.jp (inet11.jrc.co.jp [203.180.124.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27854 for ; Mon, 28 Jan 2002 03:41:27 -0800 (PST) Received: from gate1 by inet11.jrc.co.jp (8.9.3/3.7W) id UAA25270; Mon, 28 Jan 2002 20:41:26 +0900 (JST) Received: from jrcgw1 ([10.8.1.31]) by gate1.noc.jrc.co.jp; Mon, 28 Jan 2002 20:41:15 +0000 (JST) Received: from localhost by jrcgw1.noc.jrc.co.jp (8.9.3/3.7WSaTaMa99081014) id UAA09228; Mon, 28 Jan 2002 20:41:14 +0900 (JST) Date: Mon, 28 Jan 2002 20:41:14 +0900 (JST) Message-Id: <200201281141.UAA09228@jrcgw1.noc.jrc.co.jp> To: mobile-ip-dist@sunroof.eng.sun.com Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Our virus check system has detected a virus WORM_MYPARTY.A in your mail traffic on 01/28/2002 20:41:06+09:00. (Attachment file is removed for safe) From LEO-SA@sony.de Mon Jan 28 06:45:28 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22612 for ; Mon, 28 Jan 2002 06:45:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16475; Mon, 28 Jan 2002 03:44:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00953; Mon, 28 Jan 2002 03:44:25 -0800 (PST) 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 g0SBhZ2Q000476 for ; Mon, 28 Jan 2002 03:43:35 -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 DAA16739 for ; Mon, 28 Jan 2002 03:43:51 -0800 (PST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16050 for ; Mon, 28 Jan 2002 03:43:50 -0800 (PST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id MAA14396 for ; Mon, 28 Jan 2002 12:43:48 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:43:48 +0100 Message-ID: From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Mon, 28 Jan 2002 12:42:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = chcho Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 12:42:06 Engine/Pattern = 5.630-1025/207 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c55390e79.com_. Warning to recipient. ScanMail has detected a virus. From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 08:08: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 IAA23716 for ; Mon, 28 Jan 2002 08:08: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 GAA10673; Mon, 28 Jan 2002 06:08: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 FAA16594; Mon, 28 Jan 2002 05: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 g0SD7K2Q000665 for ; Mon, 28 Jan 2002 05:07:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SD7KD3000664 for mobile-ip-dist; Mon, 28 Jan 2002 05:07:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SD7H2Q000657 for ; Mon, 28 Jan 2002 05:07:17 -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 FAA12863 for ; Mon, 28 Jan 2002 05:07:34 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27336 for ; Mon, 28 Jan 2002 06:07:33 -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 g0SD7VX4022111 for ; Mon, 28 Jan 2002 14:07:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Jan 28 14:07:13 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 13:58:19 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A95B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONC LUSION) Date: Mon, 28 Jan 2002 14:07:07 +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 agree with the Design Team's recommendation. And I would prefer > changing it to a destination option. (True Destination Address??) > > >... > > Agree completely on the last point. and going by the last point, > a destination option seems to be the best thing to do (IMO). > > => a new destination option doesn't work well for a mobile router. > IMHO we should keep the "routing" element from Routing Headers > (so I am still in favour of either a new type of RH or Steve > Deering's special cases of tunnels. => I agree with the analysis and recommendation, but would prefer to use a new RH type, than a DO. For the same reasons that Francis mentioned. RH type or IP_NO_SRC, I'm neutral, whatever takes less time. Cheers, Hesham From ANTIGEN_SAPXCH01@alleghenypower.com Mon Jan 28 08:26:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24410 for ; Mon, 28 Jan 2002 08:26:36 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23245; Mon, 28 Jan 2002 06:26: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 FAA21304; Mon, 28 Jan 2002 05:26:15 -0800 (PST) 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 g0SDNo2Q000800 for ; Mon, 28 Jan 2002 05:23:51 -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 FAA08568 for ; Mon, 28 Jan 2002 05:24:08 -0800 (PST) Received: from viper3.alleghenypower.com (viper3.alleghenypower.com [63.68.200.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12755 for ; Mon, 28 Jan 2002 06:24:03 -0700 (MST) Received: from viper3.alleghenypower.com (root@localhost) by viper3.alleghenypower.com with ESMTP id g0SDO2828250 for ; Mon, 28 Jan 2002 08:24:02 -0500 (EST) Received: from sapxch01.corp.commenergy.com (sapxch01.alleghenypower.com [10.83.181.21]) by viper3.alleghenypower.com with ESMTP id g0SDO2028227 for ; Mon, 28 Jan 2002 08:24:02 -0500 (EST) Received: by sapxch01.corp.commenergy.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 08:24:01 -0500 Message-ID: From: ANTIGEN_SAPXCH01 To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: Antigen found =*.com file Date: Mon, 28 Jan 2002 08:23:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Antigen for Exchange found www.myparty.yahoo.com matching =*.com file filter. The file is currently Removed. The message, "new photos from my party!", was sent from chcho and was discovered in Rakers, Jason\Deleted Items located at Allegheny Power/EXCHANGE1/SAPXCH01. From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 08:32: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 IAA24580 for ; Mon, 28 Jan 2002 08:32:30 -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 FAA22561; Mon, 28 Jan 2002 05:27: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 FAA19783; Mon, 28 Jan 2002 05:20: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 g0SDJ22Q000765 for ; Mon, 28 Jan 2002 05:19:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SDJ1Yk000764 for mobile-ip-dist; Mon, 28 Jan 2002 05:19:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SDIv2Q000757 for ; Mon, 28 Jan 2002 05:18:58 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SDJ1F20261; Mon, 28 Jan 2002 14:19:02 +0100 (MET) Date: Mon, 28 Jan 2002 14:15:28 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Re: Future attacks and threats To: Pekka Nikander Cc: Vijay Devarapalli , mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, Erik Nordmark , James Kempf In-Reply-To: "Your message with ID" <3C551217.6030108@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: > It is important to understand, though, that the lifetime > limitation is a very essential element here. RR is needed > to limit the _place_ of the attacker; to succeed, the attacker > must somehow get into the vulnerable spots in RR, i.e. > at the MN link, HA link, CN link, or a path between > the MN and CN or CN and HA, depending on the attack. > The lifetime limitation is needed to limit the _time_ when > the attacker can prepare for the attack. Without this time > limitation, the attacker could prepare hours or even days > before the actual attack. The lifetime limitation brings > back this to something reasonable, i.e. minutes. And if the HA-MN part of the communication is protected by something like a secure tunnel for the BU associated messages then of course the MN link as the path between the HA and MA can be made not vulnerable to any such attacks. > > IMO CGA is > > very useful for IPv6. it actually eliminates a few threats > > that exist in IPv6 protocol. proving address ownership is > > a big deal IMO. it also takes care of neighbor discovery > > threats identified in draft-kempf-ipng-netaccess-threats-00.txt > > to a certain extent. it SHOULD be taken up in the IPv6 WG. > > > I tend to agree here, too. However, since the scope of > the problem is fairly limited, MAYBE it would be better > to split off a new WG from IPv6 WG, prepare solutions there, > and then bring them back to the IPv6 WG. I don't just know. > Could you, Vijay, raise this issue with Bob and Steve? > I know that at least Erik (Nordmark) and James (Kempf) > are very keen on seeing something to happen in that area. So far there's been some discussion in PANA about whether (part of) this problem belongs there but the correct answer from a management perspective seems to be NO (need to make sure that PANA can deliver a more basic authentication first). I wonder if there is a set of people that would make to drive a CGA BoF to point out what the addresses can be useful for? So far I know: Authenticate and authorize hosts joining anycast addresses (in charter for MAGMA WG really) Same for multicast (need to understand how this fits with the multicast architecture that anybody can join a group) DAD and Address resolution spoofing (part of netacess-threats) Binding Updates So I don't know what the best steps are for this. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 08:41: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 IAA24893 for ; Mon, 28 Jan 2002 08:41:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA27491; Mon, 28 Jan 2002 05:40:41 -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 FAA17297; Mon, 28 Jan 2002 05:40: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 g0SDdP2Q000837 for ; Mon, 28 Jan 2002 05:39:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SDdPHh000836 for mobile-ip-dist; Mon, 28 Jan 2002 05:39:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SDdK2Q000829 for ; Mon, 28 Jan 2002 05:39:22 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SDdXF23071; Mon, 28 Jan 2002 14:39:33 +0100 (MET) Date: Mon, 28 Jan 2002 14:36:02 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: Routing headers (CLARIFICATION) To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201251013.g0PADXg13148@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: > IMHO and if there is a consensus about the solution #3 (my opinion > is this is the best solution if this is implemented carefully) > I believe we should not propose a new non-final extension header. > So if other points show a strong interest for IPv6_NO_SRC stuff, > we should use it. If not, a new routing header type is the simplest > so the best solution. Of course in the last case a type value > should be proposed ASAP. Francis, You didn't comment on the relative preference of defining a new destination option. Perhaps the writeup wasn't clear on the different alternatives for implementing #3. The ones I know of are: - New destination option - IPv6_NO_SRC extension header type - Some other new extension header type just for the additional destination addr - New routing header type Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 08:45: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 IAA25177 for ; Mon, 28 Jan 2002 08:45: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 GAA03966; Mon, 28 Jan 2002 06:45:45 -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 FAA19548; Mon, 28 Jan 2002 05:45: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 g0SDih2Q000884 for ; Mon, 28 Jan 2002 05:44:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SDiho9000883 for mobile-ip-dist; Mon, 28 Jan 2002 05:44: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SDic2Q000876 for ; Mon, 28 Jan 2002 05:44:39 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SDirF23497; Mon, 28 Jan 2002 14:44:53 +0100 (MET) Date: Mon, 28 Jan 2002 14:41:22 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: Routing headers (ISSUE) To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201251022.g0PAMsg13190@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: > Currently some IPv6 implementations don't safely deal with RH, > for instance they blindly forward by default packets with RH > in the host mode. The IPv6 WG should warn ASAP implementers > that RFC 1122 section 3.3.5 security considerations apply > without possible harm to Mobile IPv6 (fine consequence of approch #3). > I don't know how this recommendation should be broadcasted. I think it makes sense to discuss this just on the ipng mailing list, but the actual discussion depends on whether MIPv6 will use RH or not so it makes sense to wait until the WG has consensus on that topic. The above section in RFC 1122 says among other things: To define the rules restricting host forwarding of source- routed datagrams, we use the term "local source-routing" if the next hop will be through the same physical interface through which the datagram arrived; otherwise, it is "non-local source-routing". o A host is permitted to perform local source-routing without restriction. o A host that supports non-local source-routing MUST have a configurable switch to disable forwarding, and this switch MUST default to disabled. In private mail some folks have questioned the wisdow of recommend this "local source routing" in IPv6, and that level of discussion belongs in the IPv6 WG. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 09:21: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 JAA26750 for ; Mon, 28 Jan 2002 09:21:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11198; Mon, 28 Jan 2002 06:19: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 GAA26702; Mon, 28 Jan 2002 06:18: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 g0SEHb2Q000975 for ; Mon, 28 Jan 2002 06:17:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SEHbvO000974 for mobile-ip-dist; Mon, 28 Jan 2002 06:17:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SEHW2Q000967 for ; Mon, 28 Jan 2002 06:17:33 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SEHlF26704; Mon, 28 Jan 2002 15:17:47 +0100 (MET) Date: Mon, 28 Jan 2002 15:14:15 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 To: petrescu@crm.mot.com Cc: Pekka Nikander , 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: > > On the other hand, if we want to support long term bindings (hours > > or so), CGA seems to be necessary. Thus, the turnside of RR is that > > you have to perform the RR check against both the CoA and HoA every > > few minutes, and the benefit is low computational cost. > > Respectively, the benefit of CGA is that you need to perform HoA RR > > just once an hour or so, and CoA check only if you refresh or change > > your binding, but the computational (and possibly IPR) cost is > > higher. > > I entirely agree with the above. Striking the right balance doesn't > seem easy. Fast handovers with RR and with CGA's... I don't understand the reference to fast handovers so just to make sure there isn't confusion I want to offer a perhaps unneeded clairification. Just because the max lifetime of a binding is on the order of a few minutes shouldn't affect handover performance. I just means that the MN and/or CN need to be able to refresh the binding to prevent it from expiring. We have e.g. the Binding Request message for the CN to to this today. So the effect of the short lifetime on existing communication is that every few minutes there will be 5-6 BU related packets exchanged to extend the lifetime of the binding before it expires. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 09:34: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 JAA27209 for ; Mon, 28 Jan 2002 09:34:38 -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 HAA03759; Mon, 28 Jan 2002 07:34: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 GAA00084; Mon, 28 Jan 2002 06:34: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 g0SEXG2Q001061 for ; Mon, 28 Jan 2002 06:33:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SEXF5s001060 for mobile-ip-dist; Mon, 28 Jan 2002 06:33:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SEXB2Q001053 for ; Mon, 28 Jan 2002 06:33:11 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SEX9F28431; Mon, 28 Jan 2002 15:33:09 +0100 (MET) Date: Mon, 28 Jan 2002 15:29:38 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201261402.g0QE2rg21740@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: > => a new destination option doesn't work well for a mobile router. > IMHO we should keep the "routing" element from Routing Headers > (so I am still in favour of either a new type of RH or Steve > Deering's special cases of tunnels. While mobile routers and mobile networks are out of scope I think it would be useful to try to understand what you think is the requirement here because deering/zill tunneling and a new RH type seems to have rather different properties. Is the requirement that a mobile router should be able to (or always) remove this "routing element" from the packet before delivering them to MNs behind the MR? Deering/zill tunneling would potentially allow that (assuming the tunnel terminates at the MR) but destination options or new RH type would not allow that as far as I can tell. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 09:44: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 JAA27612 for ; Mon, 28 Jan 2002 09:44:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15133; Mon, 28 Jan 2002 06:28:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28612; Mon, 28 Jan 2002 06:28: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 g0SERR2Q001020 for ; Mon, 28 Jan 2002 06:27:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SERRoX001019 for mobile-ip-dist; Mon, 28 Jan 2002 06:27: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SERM2Q001012 for ; Mon, 28 Jan 2002 06:27:23 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0SERbF27600; Mon, 28 Jan 2002 15:27:37 +0100 (MET) Date: Mon, 28 Jan 2002 15:24:06 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 To: petrescu@crm.mot.com Cc: Pekka Nikander , 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: > So extend itrace to handle these MIP cases. > > Extend ingress filtering to disallow malicious laptops to send RR > messages for incorrect CoA/HoA. While that avenue could be explored my views as an implementor of this, and in particular after having added HAO support in Solaris 8 (which is being disabled by default as we speak), is that it doesn't provide control in the right place. As an implementor of MIPv6 correspondent nodes I want to make sure that our boxes can't be used to cause new forms of damage to the Internet. Therefor, I would not feel comfortable saying that "we assume that better itrace and ingress filtering will solve this" as an argument for not having our software apply prudent checking; as a implementor that would sound far too much like "somebody elses problem". Of course, I don't know what other CN implementors are thinking. As a aside, if you look at IPPT (BoF in SLC) in addition to ITRACE you'll find that IPPT will have more problems than ITRACE. There is no counterpart to 3-way ITRACE for IPPT, but instead each node doing "unpredictable transformations" to packets need to record hashes of those packets and make them available to the IPPT system. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 11:47: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 LAA02105 for ; Mon, 28 Jan 2002 11:47:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14562; Mon, 28 Jan 2002 09:46: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 HAA11866; Mon, 28 Jan 2002 07:58: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 g0SFvj2Q001161 for ; Mon, 28 Jan 2002 07:57:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SFvjDT001160 for mobile-ip-dist; Mon, 28 Jan 2002 07:57: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 g0SFvg2Q001153 for ; Mon, 28 Jan 2002 07:57: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 HAA20461 for ; Mon, 28 Jan 2002 07:57:58 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04352 for ; Mon, 28 Jan 2002 08:57:58 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA22018 for ; Mon, 28 Jan 2002 08:57:56 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA27927 for ; Mon, 28 Jan 2002 08:57:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 28 Jan 2002 09:57:50 -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 0CD9B2EC8B; Mon, 28 Jan 2002 16:53:33 +0100 (CET) To: Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, Pekka Nikander Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: From: Alexandru Petrescu Date: 28 Jan 2002 15:57:11 +0100 In-Reply-To: Message-Id: Lines: 36 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: > As an implementor of MIPv6 correspondent nodes I want to make sure that > our boxes can't be used to cause new forms of damage to the Internet. > Therefor, I would not feel comfortable saying that "we assume that better > itrace and ingress filtering will solve this" as an argument for > not having our software apply prudent checking; as a implementor that > would sound far too much like "somebody elses problem". Erik, I perfectly understand this position, and as such I support this group's decisions with respect to future attacks. I hope my messages, already proven wrong, can at least help enlighten a way that shouldn't be explored. > Of course, I don't know what other CN implementors are thinking. I don't know either, maybe someone from MIPL can speak out here. Reversing your statement, I truly support the future attacks argument in that, as an implementor of MN, I don't want CN's services to our MN's be denied. But also as an implementor of MN's I can say that everything is possible; only when crypto comes in it gets rather complex. I'm a bit doubtful of public key operations every time MN moves or by core network routing according to keys (in addresses). Again, I'm not pushing, just expressing an oppinion, my last on this subject. > As a aside, if you look at IPPT (BoF in SLC) in addition to ITRACE > you'll find that IPPT will have more problems than ITRACE. > There is no counterpart to 3-way ITRACE for IPPT, but instead each > node doing "unpredictable transformations" to packets need to > record hashes of those packets and make them available to the IPPT > system. Thanks I will. Alex From Administrator@strixsystems.com Mon Jan 28 12:04: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 MAA02545 for ; Mon, 28 Jan 2002 12:04:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29057; Mon, 28 Jan 2002 09:04: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 JAA08440; Mon, 28 Jan 2002 09:04:22 -0800 (PST) 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 g0SH362Q001503 for ; Mon, 28 Jan 2002 09:03:06 -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 JAA15350 for ; Mon, 28 Jan 2002 09:03:23 -0800 (PST) Received: from londonbridge.strixsystems.com ([208.179.69.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20712 for ; Mon, 28 Jan 2002 10:03:21 -0700 (MST) Received: from mail pickup service by londonbridge.strixsystems.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 09:06:43 -0800 thread-index: AcGoHikjn5oP513QSG+K2gD2kBbfNA== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: Sender: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 09:06:43 -0800 Message-ID: <000301c1a81e$2923c5a0$2c45b3d0@strixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 28 Jan 2002 17:06:43.0781 (UTC) FILETIME=[2942BF50:01C1A81E] Content-Transfer-Encoding: 7bit ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = chcho Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 09:06:43 Engine/Pattern = 5.630-1025/212 Action on virus found: The message body contains WORM_MYPARTY.A virus. ScanMail has deleted the message body. Warning to mobile-ip-dist@sunroof.eng.sun.com. chcho sent you a mail with the subject new photos from my party! which included a virus. From Administrator@strixsystems.com Mon Jan 28 12:04: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 MAA02558 for ; Mon, 28 Jan 2002 12:04:44 -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 JAA29134; Mon, 28 Jan 2002 09:04:38 -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 JAA08472; Mon, 28 Jan 2002 09:04:29 -0800 (PST) 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 g0SH312Q001491 for ; Mon, 28 Jan 2002 09:03:01 -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 JAA15320 for ; Mon, 28 Jan 2002 09:03:18 -0800 (PST) Received: from londonbridge.strixsystems.com ([208.179.69.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26289 for ; Mon, 28 Jan 2002 09:03:17 -0800 (PST) Received: from mail pickup service by londonbridge.strixsystems.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 09:06:40 -0800 thread-index: AcGoHidEEfOAqoRMRH2d5um8Uv/tXQ== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: Sender: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 09:06:40 -0800 Message-ID: <000101c1a81e$27447e50$2c45b3d0@strixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 28 Jan 2002 17:06:40.0468 (UTC) FILETIME=[27493940:01C1A81E] Content-Transfer-Encoding: 7bit ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = chcho Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 09:06:38 Engine/Pattern = 5.630-1025/212 Action on virus found: The message body contains WORM_MYPARTY.A virus. ScanMail has deleted the message body. Warning to mobile-ip-dist@sunroof.eng.sun.com. chcho sent you a mail with the subject new photos from my party! which included a virus. From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 12:19: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 MAA03015 for ; Mon, 28 Jan 2002 12:19: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 KAA12966; Mon, 28 Jan 2002 10:19: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 JAA12227; Mon, 28 Jan 2002 09:18:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHHf2Q001681 for ; Mon, 28 Jan 2002 09:17:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SHHf1C001680 for mobile-ip-dist; Mon, 28 Jan 2002 09:17:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHHb2Q001673 for ; Mon, 28 Jan 2002 09:17:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11962 for ; Mon, 28 Jan 2002 09:17:54 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12026 for ; Mon, 28 Jan 2002 10:17:53 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g0SHHdh28472; Mon, 28 Jan 2002 18:17:39 +0100 (MET) Message-ID: <3C5587B3.31676C44@inrialpes.fr> Date: Mon, 28 Jan 2002 18:17:39 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Erik.Nordmark@eng.sun.com, Pekka Nikander Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: Content-Type: multipart/alternative; boundary="------------F7E29F118ED2C53C837A6BC4" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------F7E29F118ED2C53C837A6BC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > complex. I'm a bit doubtful of public key operations every time MN > moves or by core network routing according to keys (in addresses). Alexandru, FYI with SUCV the public key operations you are talking about are not performed each time the MN moves but only once, i.e. when the MN starts communicating with the CN....they then exchange a key and use it for the following BUs. regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------F7E29F118ED2C53C837A6BC4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote:
 
complex.  I'm a bit doubtful of public key operations every time MN
moves or by core network routing according to keys (in addresses).
Alexandru,

FYI with SUCV the public key operations you are talking about are not performed
each time the MN moves but  only once, i.e. when the MN starts communicating
with the CN....they then exchange a key and use it for the following BUs.

regards,
Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------F7E29F118ED2C53C837A6BC4-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 12:21: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 MAA03055 for ; Mon, 28 Jan 2002 12:21: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 JAA09180; Mon, 28 Jan 2002 09:21:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12817; Mon, 28 Jan 2002 09: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 g0SHK62Q001716 for ; Mon, 28 Jan 2002 09:20:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SHK6eX001715 for mobile-ip-dist; Mon, 28 Jan 2002 09:20: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 g0SHK22Q001708 for ; Mon, 28 Jan 2002 09:20:02 -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 JAA12590 for ; Mon, 28 Jan 2002 09:20:20 -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 KAA29996 for ; Mon, 28 Jan 2002 10:20:19 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA02886; Mon, 28 Jan 2002 09:20:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0SHKHo17512; Mon, 28 Jan 2002 09:20:17 -0800 X-mProtect: Mon, 28 Jan 2002 09:20:17 -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 smtpdLRpEeb; Mon, 28 Jan 2002 09:20:11 PST Message-ID: <3C55884C.3EB332C5@iprg.nokia.com> Date: Mon, 28 Jan 2002 09:20:12 -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: "Basavaraj Patil (NTC/Dallas)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation References: <697DAA22C5004B4596E033803A7CEF444CD5B4@daebe007.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 Basavaraj, While I think a new Destination Option will work fine, I also think the Routing Header would work fine. If protocol cannot be built using the Routing Header, then it should be removed from the IPv6 protocol specification. It is a huge waste of time for us to build according to the IPv6 specification, only to be told later that the specs were "just kidding" -- e.g., because of firewall administrative bias. Regards, Charlie P. Basavaraj.Patil@nokia.com wrote: > > I agree and am in favor of the DTs recommendation for replacing the > RH with a new DO. > > -Basavaraj > > > RECOMMENDATION > > ============== > > > > The design team is leaning towards #3 at the moment. One > > reason for this is that this would remove any suspicion that firewall > > administrators have for the use of the Routing Header and > > which might consequently lead to disabling MIPv6 because of these > > fears. Also, the firewall rules necessary to process the Routing > > Header are complex and accidental disabling of MIPv6 might also > > occur. The use of the Routing Header for other purposes would > > also not be affected. There are also drawbacks in alternative #3. > > One such issue is that existing MIPv6 implementations have to > > be changed. We feel that this drawback is offset by the expected > > wider usability of MIPv6 as a result. This change will also imply > > a substantial document modification for the MIPv6 I-D. This > > does not appear to be a structural change, however, and in > > general we feel that direct procedure is easier to describe than > > attempting to describe some additional rules to constrain the use > > of the Routing Header. Finally, alternative #3 might lead us to > > depend on the external work such as the new tunnel encapsulation > > work at IPNG. The design team feels that we should stay away > > from these non-MIPv6 solutions due schedule issues as well > > as in the interests of making a self-contained RFC. > > > > --- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 12:35: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 MAA03512 for ; Mon, 28 Jan 2002 12:35:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27439; Mon, 28 Jan 2002 10:35: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 JAA16963; Mon, 28 Jan 2002 09:35: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 g0SHYL2Q001857 for ; Mon, 28 Jan 2002 09:34:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SHYLJ4001856 for mobile-ip-dist; Mon, 28 Jan 2002 09:34:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHYI2Q001849 for ; Mon, 28 Jan 2002 09:34:18 -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 JAA27284 for ; Mon, 28 Jan 2002 09:34:35 -0800 (PST) Received: from mail.qualitymobile.com ([208.186.17.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29420 for ; Mon, 28 Jan 2002 10:34:34 -0700 (MST) Received: from nbruark [64.122.14.90] by mail.qualitymobile.com with ESMTP (SMTPD32-7.04) id A03760F0126; Mon, 28 Jan 2002 10:53:59 -0700 Message-ID: <002901c1a822$960be180$6401a8c0@nbruark> From: "Nick Ruark" To: Subject: [mobile-ip] VIRUS Alert Date: Mon, 28 Jan 2002 09:38:23 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C1A7DF.8749F080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-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_0026_01C1A7DF.8749F080 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Suggestion: Up-date and run your anti-virus program now. We have = received several messages posted to this list that have contained viruses - thankfully, our A/V software caught and = destroyed them. =20 ------=_NextPart_000_0026_01C1A7DF.8749F080 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Suggestion: Up-date and run your = anti-virus=20 program now.  We have received several messages posted to this=20 list
that have contained viruses - = thankfully, our=20 A/V software caught and destroyed them. 
 
 
------=_NextPart_000_0026_01C1A7DF.8749F080-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 12:36: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 MAA03564 for ; Mon, 28 Jan 2002 12:36: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 KAA28256; Mon, 28 Jan 2002 10:36: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 JAA17512; Mon, 28 Jan 2002 09:36:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHZD2Q001874 for ; Mon, 28 Jan 2002 09:35:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SHZDSp001873 for mobile-ip-dist; Mon, 28 Jan 2002 09:35:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SHZ92Q001866 for ; Mon, 28 Jan 2002 09:35:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27845 for ; Mon, 28 Jan 2002 09:35:26 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06124 for ; Mon, 28 Jan 2002 09:35:26 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA17356 for ; Mon, 28 Jan 2002 10:35:26 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA09126 for ; Mon, 28 Jan 2002 10:35:25 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r4.mot.com with ESMTP; Mon, 28 Jan 2002 11:35:25 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id CF7552EC83; Mon, 28 Jan 2002 18:31:17 +0100 (CET) To: claude.castelluccia@inrialpes.fr Cc: Erik.Nordmark@eng.sun.com, Pekka Nikander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C5587B3.31676C44@inrialpes.fr> From: Alexandru Petrescu Date: 28 Jan 2002 18:35:22 +0100 In-Reply-To: <3C5587B3.31676C44@inrialpes.fr> 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: Claude Castelluccia writes: > FYI with SUCV the public key operations you are talking about are > not performed each time the MN moves but only once, i.e. when the MN > starts communicating with the CN....they then exchange a key and use > it for the following BUs. Yes, I agree with that, I wrote in a hurry. There's however a case where public key operations are done often enough to worry about: privacy and _ephem of same proposal? Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 12:49: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 MAA03872 for ; Mon, 28 Jan 2002 12:49: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 JAA25327; Mon, 28 Jan 2002 09:48:51 -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 JAA20669; Mon, 28 Jan 2002 09:46: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 g0SHjU2Q002285 for ; Mon, 28 Jan 2002 09:45:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SHjUf3002284 for mobile-ip-dist; Mon, 28 Jan 2002 09:45: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 g0SHjR2Q002277 for ; Mon, 28 Jan 2002 09:45:27 -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 JAA13450 for ; Mon, 28 Jan 2002 09:45:44 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA20804 for ; Mon, 28 Jan 2002 09:45:40 -0800 (PST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 18:45:28 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C1QZYFXA; Mon, 28 Jan 2002 18:45:22 +0100 From: "Jean-Michel COMBES" To: Subject: RE: [mobile-ip] Routing headers: design team recommendation Date: Mon, 28 Jan 2002 18:45:09 +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: <3C55884C.3EB332C5@iprg.nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, just one question : are there others cases (eg. protocols) where RH are used ? Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Charles E. > Perkins > Envoye : lundi 28 janvier 2002 18:20 > A : Basavaraj Patil (NTC/Dallas) > Cc : mobile-ip@sunroof.eng.sun.com > Objet : Re: [mobile-ip] Routing headers: design team recommendation > > > Hello Basavaraj, > > While I think a new Destination Option will work fine, > I also think the Routing Header would work fine. If protocol > cannot be built using the Routing Header, then it should > be removed from the IPv6 protocol specification. > > It is a huge waste of time for us to build according to > the IPv6 specification, only to be told later that the > specs were "just kidding" -- e.g., because of firewall > administrative bias. > > Regards, > Charlie P. > > > > Basavaraj.Patil@nokia.com wrote: > > > > I agree and am in favor of the DTs recommendation for replacing the > > RH with a new DO. > > > > -Basavaraj > > > > > RECOMMENDATION > > > ============== > > > > > > The design team is leaning towards #3 at the moment. One > > > reason for this is that this would remove any suspicion that firewall > > > administrators have for the use of the Routing Header and > > > which might consequently lead to disabling MIPv6 because of these > > > fears. Also, the firewall rules necessary to process the Routing > > > Header are complex and accidental disabling of MIPv6 might also > > > occur. The use of the Routing Header for other purposes would > > > also not be affected. There are also drawbacks in alternative #3. > > > One such issue is that existing MIPv6 implementations have to > > > be changed. We feel that this drawback is offset by the expected > > > wider usability of MIPv6 as a result. This change will also imply > > > a substantial document modification for the MIPv6 I-D. This > > > does not appear to be a structural change, however, and in > > > general we feel that direct procedure is easier to describe than > > > attempting to describe some additional rules to constrain the use > > > of the Routing Header. Finally, alternative #3 might lead us to > > > depend on the external work such as the new tunnel encapsulation > > > work at IPNG. The design team feels that we should stay away > > > from these non-MIPv6 solutions due schedule issues as well > > > as in the interests of making a self-contained RFC. > > > > > > --- From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 13:05:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04401 for ; Mon, 28 Jan 2002 13:05:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04768; Mon, 28 Jan 2002 10:04:53 -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 KAA27713; Mon, 28 Jan 2002 10: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 g0SI3L2Q002380 for ; Mon, 28 Jan 2002 10:03:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SI3LGU002379 for mobile-ip-dist; Mon, 28 Jan 2002 10: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SI3H2Q002369 for ; Mon, 28 Jan 2002 10:03: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 KAA24822 for ; Mon, 28 Jan 2002 10:03:35 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22548 for ; Mon, 28 Jan 2002 11:03:34 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0SI3XX4006240 for ; Mon, 28 Jan 2002 19:03:33 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Jan 28 19:03:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 19:03:32 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A965@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Routing headers: design team recommendation Date: Mon, 28 Jan 2002 19:03:12 +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: RH can be used for traffic engineering. This maybe limited to packets sent within a site (within the FW domain) due to the security concerns but I don't know if that means it's useless. Hesham > -----Original Message----- > From: Jean-Michel COMBES > [mailto:jeanmichel.combes@francetelecom.com] > Sent: Monday, January 28, 2002 6:45 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing headers: design team recommendation > > > Hi, > > just one question : are there others cases (eg. protocols) > where RH are used > ? > > Regards. > > JMC. > > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > > > -----Message d'origine----- > > De : owner-mobile-ip@sunroof.eng.sun.com > > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de > Charles E. > > Perkins > > Envoye : lundi 28 janvier 2002 18:20 > > A : Basavaraj Patil (NTC/Dallas) > > Cc : mobile-ip@sunroof.eng.sun.com > > Objet : Re: [mobile-ip] Routing headers: design team > recommendation > > > > > > Hello Basavaraj, > > > > While I think a new Destination Option will work fine, > > I also think the Routing Header would work fine. If protocol > > cannot be built using the Routing Header, then it should > > be removed from the IPv6 protocol specification. > > > > It is a huge waste of time for us to build according to > > the IPv6 specification, only to be told later that the > > specs were "just kidding" -- e.g., because of firewall > > administrative bias. > > > > Regards, > > Charlie P. > > > > > > > > Basavaraj.Patil@nokia.com wrote: > > > > > > I agree and am in favor of the DTs recommendation for > replacing the > > > RH with a new DO. > > > > > > -Basavaraj > > > > > > > RECOMMENDATION > > > > ============== > > > > > > > > The design team is leaning towards #3 at the moment. One > > > > reason for this is that this would remove any > suspicion that firewall > > > > administrators have for the use of the Routing Header and > > > > which might consequently lead to disabling MIPv6 > because of these > > > > fears. Also, the firewall rules necessary to process > the Routing > > > > Header are complex and accidental disabling of MIPv6 > might also > > > > occur. The use of the Routing Header for other purposes would > > > > also not be affected. There are also drawbacks in > alternative #3. > > > > One such issue is that existing MIPv6 implementations have to > > > > be changed. We feel that this drawback is offset by > the expected > > > > wider usability of MIPv6 as a result. This change > will also imply > > > > a substantial document modification for the MIPv6 I-D. This > > > > does not appear to be a structural change, however, and in > > > > general we feel that direct procedure is easier to > describe than > > > > attempting to describe some additional rules to > constrain the use > > > > of the Routing Header. Finally, alternative #3 might > lead us to > > > > depend on the external work such as the new tunnel > encapsulation > > > > work at IPNG. The design team feels that we should stay away > > > > from these non-MIPv6 solutions due schedule issues as well > > > > as in the interests of making a self-contained RFC. > > > > > > > > --- > From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 13:22: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 NAA05013 for ; Mon, 28 Jan 2002 13:22:41 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14060; Mon, 28 Jan 2002 10:22:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05180; Mon, 28 Jan 2002 10:22: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 g0SIKm2Q002547 for ; Mon, 28 Jan 2002 10:20:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SIKmKb002546 for mobile-ip-dist; Mon, 28 Jan 2002 10:20:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SIKj2Q002539 for ; Mon, 28 Jan 2002 10:20: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 KAA04868 for ; Mon, 28 Jan 2002 10:21:03 -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 KAA26466 for ; Mon, 28 Jan 2002 10:21:03 -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 KAA07974 for ; Mon, 28 Jan 2002 10:21:03 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0SIL2X21915 for ; Mon, 28 Jan 2002 10:21:02 -0800 X-mProtect: Mon, 28 Jan 2002 10:21:02 -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 smtpduxitlA; Mon, 28 Jan 2002 10:21:01 PST Message-ID: <3C55968D.3180DEC@iprg.nokia.com> Date: Mon, 28 Jan 2002 10:21:01 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: <200201261428.g0QES3g21893@givry.rennes.enst-bretagne.fr> <3C535EA5.B7743563@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 I thought it was pretty obvious. the new destination option has to be before the fragment header and after the routing header. it makes no sense having it after the fragment header (if ever fragmentation is done for a packet). Vijay "Jari T. Malinen" wrote: > > Francis Dupont wrote: > > > > => another argument about a new Destination Option: > > - if we don't specify where to put the DO we'll get a mess > > Agreed, the spec needs to tell where it is. > > > - if we specify the DO must be before any IPsec header (same > > case than current HAO) we have no difference with a new RH type, > > only more complexity... > > Hmm.. both use a known header type and are resolved in the next > octet (RH type or DO type). For packet input these seem equally > complex. If it really is the case FW admins do not want any RHs > in their domains, it may be administratively simpler let them > drop RHs and use another known header. Then they do not need > to worry so much details of this part of IPv6 :-) A downside > is that this is then a confession RHs cannot be used too much. > If the FW admin constraint is considered important, I tend to > favor the use of a DO near the place of current HAO. > > > - if we specify the DO must be after any IPsec header in order > > to be able to protect it using ESP for instance, we'll mess > > the SADB lookup which is done using the destination address. > > > > IMHO we should only conclude we'd like a new mechanism and let > > the choice to the IPv6 WG (this will give us more time for other > > points too). > > > > Regards > > > > Francis.Dupont@enst-bretagne.fr > > > > PS: no mechanism has an advantage for efficiency, all are 24 byte long. > > Agreed. > > BR, > > -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 13:30:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05205 for ; Mon, 28 Jan 2002 13:30:44 -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 LAA11114; Mon, 28 Jan 2002 11:30: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 KAA08901; Mon, 28 Jan 2002 10:30: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 g0SIT72Q002652 for ; Mon, 28 Jan 2002 10:29:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SIT7e3002651 for mobile-ip-dist; Mon, 28 Jan 2002 10:29: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 g0SIT32Q002644 for ; Mon, 28 Jan 2002 10:29: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 KAA19152 for ; Mon, 28 Jan 2002 10:29:21 -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 LAA10051 for ; Mon, 28 Jan 2002 11:29:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA08506; Mon, 28 Jan 2002 10:29:18 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0SITIK03331; Mon, 28 Jan 2002 10:29:18 -0800 X-mProtect: Mon, 28 Jan 2002 10:29:18 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdpO28bw; Mon, 28 Jan 2002 10:29:16 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 KAA50949; Mon, 28 Jan 2002 10:29:16 -0800 (PST) Message-ID: <3C55987C.BECFF1EB@iprg.nokia.com> Date: Mon, 28 Jan 2002 10:29:16 -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: petrescu@crm.mot.com, Pekka Nikander Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: Content-Type: text/plain; charset=us-ascii 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: > > > So extend itrace to handle these MIP cases. > > > > Extend ingress filtering to disallow malicious laptops to send RR > > messages for incorrect CoA/HoA. > > While that avenue could be explored my views as an implementor of > this, and in particular after having added HAO support in Solaris 8 > (which is being disabled by default as we speak), is that it doesn't > provide control in the right place. > > As an implementor of MIPv6 correspondent nodes I want to make sure that > our boxes can't be used to cause new forms of damage to the Internet. > Therefor, I would not feel comfortable saying that "we assume that better > itrace and ingress filtering will solve this" as an argument for > not having our software apply prudent checking; as a implementor that > would sound far too much like "somebody elses problem". > > Of course, I don't know what other CN implementors are thinking. I would briefly just like to note (being involved implementing some other things too) that _if_ solutions fulfilling the security requirements can be achieved by changes in places other than CN, it might be of interest to consider these, too. As of the placement of the problem, if I am responsible for a filter and a cloud of routers where I want locally to ensure optimal traffic and that malicious things can't happen, would I not have the same question whether somebody else (a CN) does or does not do this for me, e.g., if a CN is just a reflector rather than the victim potentially in my domain. This seemed one point in your analysis on alternatives on RH? > As a aside, if you look at IPPT (BoF in SLC) in addition to ITRACE > you'll find that IPPT will have more problems than ITRACE. > There is no counterpart to 3-way ITRACE for IPPT, but instead each > node doing "unpredictable transformations" to packets need to > record hashes of those packets and make them available to the IPPT system. > > Erik BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 13:49: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 NAA05697 for ; Mon, 28 Jan 2002 13:49:50 -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 KAA28098; Mon, 28 Jan 2002 10:49: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 KAA14381; Mon, 28 Jan 2002 10:49:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SIm72Q002909 for ; Mon, 28 Jan 2002 10:48:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SIm7LR002908 for mobile-ip-dist; Mon, 28 Jan 2002 10:48:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SIm32Q002901 for ; Mon, 28 Jan 2002 10:48:04 -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 KAA20958 for ; Mon, 28 Jan 2002 10:48:20 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA24488 for ; Mon, 28 Jan 2002 11:48:20 -0700 (MST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 19:48:09 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C1QZYFYM; Mon, 28 Jan 2002 19:48:06 +0100 From: "Jean-Michel COMBES" To: Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Mon, 28 Jan 2002 19:47:53 +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: <3C55968D.3180DEC@iprg.nokia.com> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Excuse me but I think I missed an episode : 1. at first, RH is said to be dangerous [Why not ...] 2. after, one idea to replace RH functionality is to create a new DO [Why not ...] 3. and now, it is proposed to place this new DO between the fragment header and the ... RH [!?!] Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Vijay > Devarapalli > Envoye : lundi 28 janvier 2002 19:21 > A : mobile-ip@sunroof.eng.sun.com > Objet : Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team > recommendation > > > I thought it was pretty obvious. the new destination option > has to be before the fragment header and after the routing > header. it makes no sense having it after the fragment header > (if ever fragmentation is done for a packet). > > Vijay > > "Jari T. Malinen" wrote: > > > > Francis Dupont wrote: > > > > > > => another argument about a new Destination Option: > > > - if we don't specify where to put the DO we'll get a mess > > > > Agreed, the spec needs to tell where it is. > > > > > - if we specify the DO must be before any IPsec header (same > > > case than current HAO) we have no difference with a new RH type, > > > only more complexity... > > > > Hmm.. both use a known header type and are resolved in the next > > octet (RH type or DO type). For packet input these seem equally > > complex. If it really is the case FW admins do not want any RHs > > in their domains, it may be administratively simpler let them > > drop RHs and use another known header. Then they do not need > > to worry so much details of this part of IPv6 :-) A downside > > is that this is then a confession RHs cannot be used too much. > > If the FW admin constraint is considered important, I tend to > > favor the use of a DO near the place of current HAO. > > > > > - if we specify the DO must be after any IPsec header in order > > > to be able to protect it using ESP for instance, we'll mess > > > the SADB lookup which is done using the destination address. > > > > > > IMHO we should only conclude we'd like a new mechanism and let > > > the choice to the IPv6 WG (this will give us more time for other > > > points too). > > > > > > Regards > > > > > > Francis.Dupont@enst-bretagne.fr > > > > > > PS: no mechanism has an advantage for efficiency, all are 24 > byte long. > > > > Agreed. > > > > BR, > > > > -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 13:55: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 NAA05822 for ; Mon, 28 Jan 2002 13:55: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 KAA00799; Mon, 28 Jan 2002 10:55:05 -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 KAA15906; Mon, 28 Jan 2002 10:54: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 g0SIru2Q002961 for ; Mon, 28 Jan 2002 10:53:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SIrtGb002960 for mobile-ip-dist; Mon, 28 Jan 2002 10:53: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 g0SIrq2Q002953 for ; Mon, 28 Jan 2002 10:53:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29834 for ; Mon, 28 Jan 2002 10:54:08 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22867 for ; Mon, 28 Jan 2002 11:54:07 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0SIs6L04300; Mon, 28 Jan 2002 10:54:06 -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 AAT55619; Mon, 28 Jan 2002 10:53:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA21069; Mon, 28 Jan 2002 10:54:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.40521.660622.110222@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 10:54:01 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Francis.Dupont@enst-bretagne.fr Subject: Re: [mobile-ip] Re: Routing headers (ISSUE) In-Reply-To: References: <200201251022.g0PAMsg13190@givry.rennes.enst-bretagne.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark writes: > o A host that supports non-local source-routing MUST have a > configurable switch to disable forwarding, and this switch > MUST default to disabled. Under what conditions would a user not be crazy to enable it? Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 14:21:51 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06455 for ; Mon, 28 Jan 2002 14:21:50 -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 LAA14607; Mon, 28 Jan 2002 11:21: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 LAA22968; Mon, 28 Jan 2002 11:21:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SJKE2Q003125 for ; Mon, 28 Jan 2002 11:20:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SJKEYL003124 for mobile-ip-dist; Mon, 28 Jan 2002 11:20:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SJKA2Q003117 for ; Mon, 28 Jan 2002 11:20:11 -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 LAA22694 for ; Mon, 28 Jan 2002 11:20:26 -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 MAA01233 for ; Mon, 28 Jan 2002 12:20:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA12385 for ; Mon, 28 Jan 2002 11:20:25 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0SJKPC15142 for ; Mon, 28 Jan 2002 11:20:25 -0800 X-mProtect: Mon, 28 Jan 2002 11:20:25 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdqkjFuc; Mon, 28 Jan 2002 11:20:22 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 LAA51001 for ; Mon, 28 Jan 2002 11:20:23 -0800 (PST) Message-ID: <3C55A477.3A4E89C1@iprg.nokia.com> Date: Mon, 28 Jan 2002 11:20:23 -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: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jean, > Excuse me but I think I missed an episode : > 1. at first, RH is said to be dangerous [Why not ...] > 2. after, one idea to replace RH functionality is to create a new DO [Why > not ...] > 3. and now, it is proposed to place this new DO between the fragment header > and the ... RH [!?!] Seems a bit funny, doesn't it. However, what does not meet the eye are the ordering rules for a packet as compared to what is actually in the packet. RH issue seems to be rather thoroughly analyzed in the security recommendations.. > Regards. > > JMC. > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 14:27:12 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06561 for ; Mon, 28 Jan 2002 14:27:12 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17064; Mon, 28 Jan 2002 11:26: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 LAA24452; Mon, 28 Jan 2002 11:26: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 g0SJPW2Q003315 for ; Mon, 28 Jan 2002 11:25:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SJPWLf003314 for mobile-ip-dist; Mon, 28 Jan 2002 11:25:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SJPS2Q003307 for ; Mon, 28 Jan 2002 11:25:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22089 for ; Mon, 28 Jan 2002 11:25:45 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23533 for ; Mon, 28 Jan 2002 12:25:44 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA04040 for ; Mon, 28 Jan 2002 12:25:43 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA01502 for ; Mon, 28 Jan 2002 12:14:39 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 28 Jan 2002 13:25:34 -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 E694B2EC83; Mon, 28 Jan 2002 20:21:34 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Pekka Nikander Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: From: Alexandru Petrescu Date: 28 Jan 2002 20:25:39 +0100 In-Reply-To: Message-Id: Lines: 33 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: > > I entirely agree with the above. Striking the right balance doesn't > > seem easy. Fast handovers with RR and with CGA's... > > I don't understand the reference to fast handovers so just to make sure > there isn't confusion I want to offer a perhaps unneeded > clairification. Erik, I'm trying to avoid generating too much text, this is why my phrases are short. My observation was mainly that when handing over with change in CoAs and according to existing "fast" proposals there is a certain number of messages involved before being able to use that CoA. To those messages one should potentially add RR _and_ CGA's exchanges. This, again IMHO, inevitably lengthens the timespan over which my MN won't use the new CoA. If I'm missing anything, please correct me. I know you already pointed that "number of messages" is an odd criteria to compare MIP security proposals, just thought that it might make more sense here. > Just because the max lifetime of a binding is on the order of a few > minutes shouldn't affect handover performance. I just means that > the MN and/or CN need to be able to refresh the binding to prevent > it from expiring. We have e.g. the Binding Request message for the > CN to to this today. So the effect of the short lifetime on > existing communication is that every few minutes there will be 5-6 > BU related packets exchanged to extend the lifetime of the binding > before it expires. Aha, I see. I didn't think about this. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 15:43: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 PAA08189 for ; Mon, 28 Jan 2002 15:43: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 MAA21573; Mon, 28 Jan 2002 12:42:45 -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 MAA01550; Mon, 28 Jan 2002 12:42:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SKf32Q003657 for ; Mon, 28 Jan 2002 12:41:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SKf2Qp003656 for mobile-ip-dist; Mon, 28 Jan 2002 12:41:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0SKew2Q003649 for ; Mon, 28 Jan 2002 12:40:59 -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 MAA07740; Mon, 28 Jan 2002 12:41: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 NAA06425; Mon, 28 Jan 2002 13:41:13 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17819; Mon, 28 Jan 2002 12:41:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0SKfBv04737; Mon, 28 Jan 2002 12:41:11 -0800 X-mProtect: Mon, 28 Jan 2002 12:41:11 -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 smtpda8VQOR; Mon, 28 Jan 2002 12:41:09 PST Message-ID: <3C55B765.23C8800@iprg.nokia.com> Date: Mon, 28 Jan 2002 12:41:09 -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: Pekka Nikander CC: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi, Erik Nordmark , James Kempf Subject: [mobile-ip] Re: Future attacks and threats References: <3C51F901.65A72ED6@iprg.nokia.com> <3C551217.6030108@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka Nikander wrote: > I tend to agree here, too. However, since the scope of > the problem is fairly limited, MAYBE it would be better > to split off a new WG from IPv6 WG, prepare solutions there, > and then bring them back to the IPv6 WG. I don't just know. > Could you, Vijay, raise this issue with Bob and Steve? > I know that at least Erik (Nordmark) and James (Kempf) > are very keen on seeing something to happen in that area. I think it would be better if Gabriel or Claude (Castelluccia) take this up. Vijay > > --Pekka From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 17:47: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 RAA10467 for ; Mon, 28 Jan 2002 17:47:10 -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 OAA13425; Mon, 28 Jan 2002 14:46:54 -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 OAA12996; Mon, 28 Jan 2002 14:46: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 g0SMjX2Q003982 for ; Mon, 28 Jan 2002 14:45:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0SMjX0Z003981 for mobile-ip-dist; Mon, 28 Jan 2002 14:45: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 g0SMjN2Q003974 for ; Mon, 28 Jan 2002 14:45:30 -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 OAA18226; Mon, 28 Jan 2002 14:45:40 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25421; Mon, 28 Jan 2002 15:45:38 -0700 (MST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0SMjZe11606; Mon, 28 Jan 2002 14:45:35 -0800 (PST) Message-ID: <004701c1a84d$4796fc30$1b6015ac@T23KEMPF> From: "James Kempf" To: , "Pekka Nikander" Cc: , , "Erik Nordmark" References: <3C51F901.65A72ED6@iprg.nokia.com> <3C551217.6030108@nomadiclab.com> <3C55B765.23C8800@iprg.nokia.com> Subject: Re: [mobile-ip] Re: Future attacks and threats Date: Mon, 28 Jan 2002 14:43: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 Vjay, Erik and I have a draft on threats to Neighbor Discovery (draft-kempf-ipng-netaccess-threats-00.txt). I am very interested in finding some solutions to securing Neighbor Discovery for public access networks, because it is a problem that wireless access providers will have when deploying 802.11 public access networks. The problem came up in PANA but we were requested to move out of there because it didn't seem to be in scope, it probably isn't in scope here either. We've been discussing it privately, perhaps it's time to set up a mailing list? Also, maybe Erik can tell us if we should contact Bob and Steve about whether to keep it in IPNG or start a separate BOF? Were there any other threats besides those to Neighbor Discovery that you had in mind? It might make sense to handle this as a separate activity if they were bundled (provided bundling makes sense technically). jak ----- Original Message ----- From: "Vijay Devarapalli" To: "Pekka Nikander" Cc: ; ; "Erik Nordmark" ; "James Kempf" Sent: Monday, January 28, 2002 12:41 PM Subject: [mobile-ip] Re: Future attacks and threats > Pekka Nikander wrote: > > > I tend to agree here, too. However, since the scope of > > the problem is fairly limited, MAYBE it would be better > > to split off a new WG from IPv6 WG, prepare solutions there, > > and then bring them back to the IPv6 WG. I don't just know. > > Could you, Vijay, raise this issue with Bob and Steve? > > I know that at least Erik (Nordmark) and James (Kempf) > > are very keen on seeing something to happen in that area. > > I think it would be better if Gabriel or Claude (Castelluccia) > take this up. > > Vijay > > > > > --Pekka > From g904382@oz.nthu.edu.tw Mon Jan 28 20:26: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 UAA12903 for ; Mon, 28 Jan 2002 20:26:07 -0500 (EST) From: g904382@oz.nthu.edu.tw Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03394; Mon, 28 Jan 2002 18:25:58 -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 RAA18470; Mon, 28 Jan 2002 17:25:50 -0800 (PST) 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 g0T1OT2Q004523 for ; Mon, 28 Jan 2002 17:24:30 -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 RAA18233 for ; Mon, 28 Jan 2002 17:24:47 -0800 (PST) Received: from thccx9.oz.nthu.edu.tw (u-mail.HCRC.edu.tw [163.28.65.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12807 for ; Mon, 28 Jan 2002 18:24:44 -0700 (MST) Received: from HOST (mantis.cs.nthu.edu.tw [140.114.79.52]) by thccx9.oz.nthu.edu.tw (Postfix) with SMTP id A6CD86BD65 for ; Tue, 29 Jan 2002 09:24:04 +0800 (CST) To: mobile-ip-dist@sunroof.eng.sun.com Subject: new photos from my party! Message-Id: <20020129012404.A6CD86BD65@thccx9.oz.nthu.edu.tw> Date: Tue, 29 Jan 2002 09:24:04 +0800 (CST) Hello! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I``````````````````````````````````````````````````````"Y end From Administrator@strixsystems.com Mon Jan 28 20:28: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 UAA12941 for ; Mon, 28 Jan 2002 20:28:12 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07799; Mon, 28 Jan 2002 17:27:58 -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 RAA18971; Mon, 28 Jan 2002 17:27:49 -0800 (PST) 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 g0T1QX2Q004543 for ; Mon, 28 Jan 2002 17:26:34 -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 RAA07436 for ; Mon, 28 Jan 2002 17:26:50 -0800 (PST) Received: from londonbridge.strixsystems.com ([208.179.69.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14748 for ; Mon, 28 Jan 2002 17:26:50 -0800 (PST) Received: from mail pickup service by londonbridge.strixsystems.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 17:30:15 -0800 thread-index: AcGoZIBkJ5wkxYIUSQmbvc1AhA8gdw== Thread-Topic: ScanMail Message: To Recipient virus found and action taken. From: Sender: To: Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 17:30:14 -0800 Message-ID: <000601c1a864$8066c7e0$2c45b3d0@strixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 29 Jan 2002 01:30:15.0031 (UTC) FILETIME=[8091A870:01C1A864] Content-Transfer-Encoding: 7bit ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = g904382@oz.nthu.edu.tw Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 17:30:14 Engine/Pattern = 5.630-1025/212 Action on virus found: The message body contains WORM_MYPARTY.A virus. ScanMail has deleted the message body. Warning to mobile-ip-dist@sunroof.eng.sun.com. g904382@oz.nthu.edu.tw sent you a mail with the subject new photos from my party! which included a virus. From EXCHSRV-ENG-SA@cosinecom.com Mon Jan 28 20:28: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 UAA12958 for ; Mon, 28 Jan 2002 20:28: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 SAA04503; Mon, 28 Jan 2002 18:28:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19038; Mon, 28 Jan 2002 17:28:04 -0800 (PST) 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 g0T1Qi2Q004547 for ; Mon, 28 Jan 2002 17:26:44 -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 RAA07586 for ; Mon, 28 Jan 2002 17:27:02 -0800 (PST) Received: from exchsrv2.cosinecom.com (proxy127.cosinecom.com [63.88.104.127]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03967 for ; Mon, 28 Jan 2002 18:27:02 -0700 (MST) Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 17:26:33 -0800 Message-ID: <69BCCDDC980B4641BFC908D7BF95F184DD1D7A@exchsrv-eng> From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found and action taken. Date: Mon, 28 Jan 2002 17:26:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A864.0BD8AD30" 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_01C1A864.0BD8AD30 Content-Type: text/plain ScanMail for Microsoft Exchange has detected virus-infected attachment(s). Sender = g904382@oz.nthu.edu.tw Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/28/2002 17:26:58 Action on virus found: The attachment www.myparty.yahoo.com exists WORM_MYPARTY.A virus. ScanMail has Moved it. The attachment was moved to C:\Program Files\Trend\Smex\Virus\www.myparty.yahoo3c55fa62c.com_. Warning to recipient. ScanMail has detected a virus sent to you from g904382@oz.nthu.edu.tw on 01/28/2002 at 05:26 PM with a subject of new photos from my party!.##################################################################### ################################# This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## ------_=_NextPart_001_01C1A864.0BD8AD30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable ScanMail Message: To Recipient virus found and action = taken.

ScanMail for Microsoft Exchange has detected = virus-infected attachment(s).

Sender =3D g904382@oz.nthu.edu.tw
Recipient(s) =3D = mobile-ip-dist@sunroof.eng.sun.com
Subject =3D new photos from my party!
Scanning Time =3D 01/28/2002 17:26:58

Action on virus found:
The attachment www.myparty.yahoo.com exists = WORM_MYPARTY.A virus. ScanMail has Moved it.  The attachment was = moved to C:\Program = Files\Trend\Smex\Virus\www.myparty.yahoo3c55fa62c.com_.

Warning to recipient. ScanMail has detected a virus = sent to you from g904382@oz.nthu.edu.tw on 01/28/2002 at 05:26 PM with = a subject of new photos from my party!.###############################################################= ####################################### This email communication may = contain CONFIDENTIAL INFORMATION and is intended only for the use of = the intended recipients identified above.  If you are not the = intended recipient of this communication, you must not use, disclose, = distribute, copy or print this email. If you have received this = communication in error, please immediately notify the sender by reply = email, delete the communication and destroy all copies. = ########################################################################= ##############################

------_=_NextPart_001_01C1A864.0BD8AD30-- From LEO-SA@sony.de Mon Jan 28 20:28: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 UAA12971 for ; Mon, 28 Jan 2002 20:28: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 RAA08039; Mon, 28 Jan 2002 17:28:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19095; Mon, 28 Jan 2002 17:28:16 -0800 (PST) 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 g0T1R22Q004549 for ; Mon, 28 Jan 2002 17:27:02 -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 RAA23804 for ; Mon, 28 Jan 2002 17:27:20 -0800 (PST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02995 for ; Mon, 28 Jan 2002 17:27:19 -0800 (PST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id CAA17762 for ; Tue, 29 Jan 2002 02:27:18 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 02:27:17 +0100 Message-ID: From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Tue, 29 Jan 2002 02:25:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = g904382@oz.nthu.edu.tw Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/29/2002 02:25:26 Engine/Pattern = 5.630-1025/212 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c55fa0683.com_. Warning to recipient. ScanMail has detected a virus. From LEO-SA@sony.de Mon Jan 28 20:30: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 UAA13045 for ; Mon, 28 Jan 2002 20:30: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 RAA08905; Mon, 28 Jan 2002 17:30:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19707; Mon, 28 Jan 2002 17:30:13 -0800 (PST) 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 g0T1Sh2Q004572 for ; Mon, 28 Jan 2002 17:28:45 -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 RAA08068 for ; Mon, 28 Jan 2002 17:29:01 -0800 (PST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16984 for ; Mon, 28 Jan 2002 18:29:00 -0700 (MST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id CAA17773 for ; Tue, 29 Jan 2002 02:29:00 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 02:28:59 +0100 Message-ID: From: System Attendant To: "'mobile-ip-dist@sunroof.eng.sun.com'" Subject: ScanMail Message: To Recipient virus found or matched file blocki ng setting. Date: Tue, 29 Jan 2002 02:27:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = g904382@oz.nthu.edu.tw Recipient(s) = mobile-ip-dist@sunroof.eng.sun.com Subject = new photos from my party! Scanning Time = 01/29/2002 02:27:12 Engine/Pattern = 5.630-1025/212 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c55fa7084.com_. Warning to recipient. ScanMail has detected a virus. From Postmaster@JRC.Co.Jp Mon Jan 28 20:30:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13061 for ; Mon, 28 Jan 2002 20:30:37 -0500 (EST) From: Postmaster@JRC.Co.Jp Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06006; Mon, 28 Jan 2002 18:30:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19740; Mon, 28 Jan 2002 17:30:22 -0800 (PST) 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 g0T1Sv2Q004574 for ; Mon, 28 Jan 2002 17:28: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 RAA03238 for ; Mon, 28 Jan 2002 17:29:15 -0800 (PST) Received: from inet11.jrc.co.jp (inet11.jrc.co.jp [203.180.124.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17034 for ; Mon, 28 Jan 2002 18:29:14 -0700 (MST) Received: from gate1 by inet11.jrc.co.jp (8.9.3/3.7W) id KAA14477; Tue, 29 Jan 2002 10:29:12 +0900 (JST) Received: from jrcgw1 ([10.8.1.31]) by gate1.noc.jrc.co.jp; Tue, 29 Jan 2002 10:28:56 +0000 (JST) Received: from localhost by jrcgw1.noc.jrc.co.jp (8.9.3/3.7WSaTaMa99081014) id KAA29566; Tue, 29 Jan 2002 10:28:56 +0900 (JST) Date: Tue, 29 Jan 2002 10:28:56 +0900 (JST) Message-Id: <200201290128.KAA29566@jrcgw1.noc.jrc.co.jp> To: mobile-ip-dist@sunroof.eng.sun.com Subject: Virus Alert Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Our virus check system has detected a virus WORM_MYPARTY.A in your mail traffic on 01/29/2002 10:28:54+09:00. (Attachment file is removed for safe) From owner-mobile-ip@sunroof.eng.sun.com Mon Jan 28 21:31: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 VAA13799 for ; Mon, 28 Jan 2002 21:31: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 SAA23972; Mon, 28 Jan 2002 18:31:16 -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 SAA00399; Mon, 28 Jan 2002 18:31: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 g0T2T22Q004708 for ; Mon, 28 Jan 2002 18:29:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0T2T2QU004707 for mobile-ip-dist; Mon, 28 Jan 2002 18:29: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 g0T2Sv2Q004700 for ; Mon, 28 Jan 2002 18:28: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 SAA19034 for ; Mon, 28 Jan 2002 18:29:15 -0800 (PST) Received: from mail.qualitymobile.com ([208.186.17.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA29558 for ; Mon, 28 Jan 2002 19:29:15 -0700 (MST) Received: from C851792A [12.225.231.41] by mail.qualitymobile.com with ESMTP (SMTPD32-7.04) id AD8486D00E4; Mon, 28 Jan 2002 19:48:36 -0700 Message-ID: <001f01c1a86c$a73b72f0$29e7e10c@C851792A> From: "Nick Ruark" To: "Mobile-IP" Cc: Subject: [mobile-ip] IMPORTANT VIRUS ALERT Date: Mon, 28 Jan 2002 18:28:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High 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: Content-Transfer-Encoding: 7bit The sender shown in the From field below has a computer infected with a VIRUS. ----- Original Message ----- From: To: Sent: Monday, January 28, 2002 5:24 PM Subject: new photos from my party! | Hello! | | My party... It was absolutely amazing! | I have attached my web page with new photos! | If you can please make color prints of my photos. Thanks! | | | | From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 04:19: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 EAA28587 for ; Tue, 29 Jan 2002 04:19: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 BAA16890; Tue, 29 Jan 2002 01:18:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05177; Tue, 29 Jan 2002 01:18: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 g0T9Gu2Q005175 for ; Tue, 29 Jan 2002 01:16:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0T9GusK005174 for mobile-ip-dist; Tue, 29 Jan 2002 01:16:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0T9Gp2Q005167 for ; Tue, 29 Jan 2002 01:16:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04937 for ; Tue, 29 Jan 2002 01:17:07 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02924 for ; Tue, 29 Jan 2002 01:17:05 -0800 (PST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g0T9Ggh11396; Tue, 29 Jan 2002 10:16:42 +0100 (MET) Message-ID: <3C56687D.9C4DB4E6@inrialpes.fr> Date: Tue, 29 Jan 2002 10:16:45 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Erik.Nordmark@eng.sun.com, Pekka Nikander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C5587B3.31676C44@inrialpes.fr> Content-Type: multipart/alternative; boundary="------------6938144C7CE3F1CE23CDD341" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------6938144C7CE3F1CE23CDD341 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Claude Castelluccia writes: > > FYI with SUCV the public key operations you are talking about are > > not performed each time the MN moves but only once, i.e. when the MN > > starts communicating with the CN....they then exchange a key and use > > it for the following BUs. > > Yes, I agree with that, I wrote in a hurry. There's however a case > where public key operations are done often enough to worry about: > privacy and _ephem of same proposal? > > Alex I guess you are talking about the location privacy extension of SUCV? In this case we propose to use ephem. HomeAddress and change it frequently... however i don't think it makes sense to change it while you already have a SA with a CN....it makes sense to change it when you starts communicating with a new CN and in this case you have to perform the public key operations anyway (the SUCV msg exchanges)... The only additional load is on the MN that has to generate a new CGA address...but this operation can possibly be done by the HomeAgent as explained in the draft/paper... Alex, did i answer your question or did i miss something? Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------6938144C7CE3F1CE23CDD341 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote:
Claude Castelluccia <claude.castelluccia@inrialpes.fr> writes:
> FYI with SUCV the public key operations you are talking about are
> not performed each time the MN moves but only once, i.e. when the MN
> starts communicating with the CN....they then exchange a key and use
> it for the following BUs.

Yes, I agree with that, I wrote in a hurry.  There's however a case
where public key operations are done often enough to worry about:
privacy and _ephem of same proposal?

Alex

I guess you are talking about the location privacy extension of SUCV?
In this case we propose to use ephem. HomeAddress and change it frequently...
however i don't think it makes sense to change it while you already have a
SA with a CN....it makes sense to change it when you starts communicating with a
new CN and in this case you have to perform the public key operations anyway (the SUCV
msg exchanges)...

The only additional load is on the MN that has to generate a new CGA address...but
this operation can possibly be done by the HomeAgent as explained in the draft/paper...

Alex, did i answer your question or did i miss something?
Claude.
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------6938144C7CE3F1CE23CDD341-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 05:09: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 FAA29165 for ; Tue, 29 Jan 2002 05:09:58 -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 CAA02340; Tue, 29 Jan 2002 02:09:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16417; Tue, 29 Jan 2002 02:09: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 g0TA8j2Q005303 for ; Tue, 29 Jan 2002 02:08:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TA8jVF005302 for mobile-ip-dist; Tue, 29 Jan 2002 02:08: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 g0TA8e2Q005295 for ; Tue, 29 Jan 2002 02:08:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20139 for ; Tue, 29 Jan 2002 02:08:56 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18050 for ; Tue, 29 Jan 2002 02:08:56 -0800 (PST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id DAA01749 for ; Tue, 29 Jan 2002 03:08:55 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA00576 for ; Tue, 29 Jan 2002 02:57:50 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Tue, 29 Jan 2002 03:08:53 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id F30052EC83; Tue, 29 Jan 2002 11:04:30 +0100 (CET) To: claude.castelluccia@inrialpes.fr Cc: Erik.Nordmark@eng.sun.com, Pekka Nikander , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C5587B3.31676C44@inrialpes.fr> <3C56687D.9C4DB4E6@inrialpes.fr> From: Alexandru Petrescu Date: 29 Jan 2002 11:08:38 +0100 In-Reply-To: <3C56687D.9C4DB4E6@inrialpes.fr> Message-Id: Lines: 41 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 Claude and thank you for your reply. I inlined some remarks. > Alexandru Petrescu wrote: > > Yes, I agree with that, I wrote in a hurry. There's however a case > > where public key operations are done often enough to worry about: > > privacy and _ephem of same proposal? Claude Castelluccia writes: > I guess you are talking about the location privacy extension of > SUCV? Indeed. > In this case we propose to use ephem. HomeAddress and change it > frequently... however i don't think it makes sense to change it > while you already have a SA with a CN.... In location privacy, you suggest that it's not good to reveal the Home Address and as such you indicate using an ephemeral Home Address. This looks valid to me. A logical extension is that, IMHO, later on people will think that privacy is probably to not even reveal that ephemeral address 1 was in cell x and now it's in cell y. This would boil down to using a new ephemeral address everytime changing cells. Or maybe I'm wrong. In any case, I feel most of this is very much close to speculation and what we need is probably implementation experience. If anyone were to start writing code, first would need to identify a library of public key code, better if for kernel. > The only additional load is on the MN that has to generate a new CGA > address...but this operation can possibly be done by the HomeAgent > as explained in the draft/paper... I need to look at this HA offloading in detail. Thanks, Alex From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 05:15: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 FAA29255 for ; Tue, 29 Jan 2002 05:15: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 CAA04141; Tue, 29 Jan 2002 02:14:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17829; Tue, 29 Jan 2002 02:14: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 g0TADw2Q005518 for ; Tue, 29 Jan 2002 02:13:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TADw9W005517 for mobile-ip-dist; Tue, 29 Jan 2002 02:13: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TADs2Q005510 for ; Tue, 29 Jan 2002 02:13:54 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TAE3F01712; Tue, 29 Jan 2002 11:14:04 +0100 (MET) Date: Tue, 29 Jan 2002 11:10:31 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: Future attacks and threats To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com, Pekka Nikander , jari.arkko@kolumbus.fi, Erik Nordmark In-Reply-To: "Your message with ID" <004701c1a84d$4796fc30$1b6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik and I have a draft on threats to Neighbor Discovery > (draft-kempf-ipng-netaccess-threats-00.txt). I am very interested in > finding some solutions to securing Neighbor Discovery for public access > networks, because it is a problem > that wireless access providers will have when deploying 802.11 public > access networks. The problem came up in > PANA but we were requested to move out of there because it didn't seem > to be in scope, it probably > isn't in scope here either. We've been discussing it privately, perhaps > it's time to set up a mailing list? > Also, maybe Erik can tell us if we should contact Bob and Steve about > whether to keep it in > IPNG or start a separate BOF? How about setting up a separate mailing list and check on how many people are interested in working on solving these types of problems? It might be that a focused BoF and perhaps WG makes more sense, but it would require that a number of people are willing to work on the problem. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 06:54: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 GAA00422 for ; Tue, 29 Jan 2002 06:54:42 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01651; Tue, 29 Jan 2002 03:54: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 DAA20874; Tue, 29 Jan 2002 03:54: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 g0TBr32Q005704 for ; Tue, 29 Jan 2002 03:53:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TBr37X005703 for mobile-ip-dist; Tue, 29 Jan 2002 03:53:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TBqw2Q005696 for ; Tue, 29 Jan 2002 03:52:59 -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 DAA04052 for ; Tue, 29 Jan 2002 03:53:13 -0800 (PST) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11695 for ; Tue, 29 Jan 2002 04:53:08 -0700 (MST) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id NAA27399 for ; Tue, 29 Jan 2002 13:50:45 +0200 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma027395; Tue, 29 Jan 02 13:50:19 +0200 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id g0TBqc825452 for ; Tue, 29 Jan 2002 13:52:38 +0200 (EET) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id NAA19208 for ; Tue, 29 Jan 2002 13:52:37 +0200 (EET) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Tue, 29 Jan 2002 13:52:37 +0200 (EET) From: Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 In-Reply-To: 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 28 Jan 2002, Alexandru Petrescu wrote: > Erik Nordmark writes: > > As an implementor of MIPv6 correspondent nodes I want to make sure that > > our boxes can't be used to cause new forms of damage to the Internet. > > Therefor, I would not feel comfortable saying that "we assume that better > > itrace and ingress filtering will solve this" as an argument for > > not having our software apply prudent checking; as a implementor that > > would sound far too much like "somebody elses problem". > > Erik, I perfectly understand this position, and as such I support this > group's decisions with respect to future attacks. I hope my messages, > already proven wrong, can at least help enlighten a way that shouldn't > be explored. > > > Of course, I don't know what other CN implementors are thinking. > > I don't know either, maybe someone from MIPL can speak out here. Alex, I had originally a negative attitude towards RR, since it could be easily misused to attack CNs and third parties. For this reason we have not included BAKE in MIPL for now. I reconsidered my view on RR, when I wrote a short paper on the vulnerabilities of BAKE as an authorization mechanism with also some ideas on how to fix them or limit their scope. (A preliminary version of it is available at http://www.tml.hut.fi/~lpetande/publications/bake.ps) IMHO RR could be used to authorize BUs, if the design takes the relevant threats into account and there exists a way for CNs to back off from accepting a suspicious BSA in BAKE, or a BU in N-way, and require stronger proof of addres ownership, e.g. CGA. Henrik ---------------------------------- Henrik Petander Helsinki University of Technology, GO/Core Project Henrik.Petander@hut.fi Office: +358 (0)9 451 5846 GSM: +358 (0)40 741 5248 ---------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 07:43: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 HAA01393 for ; Tue, 29 Jan 2002 07:43: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 FAA20722; Tue, 29 Jan 2002 05:43: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 EAA04633; Tue, 29 Jan 2002 04:43: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 g0TCgK2Q005949 for ; Tue, 29 Jan 2002 04:42:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TCgK1A005948 for mobile-ip-dist; Tue, 29 Jan 2002 04:42: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 g0TCgF2Q005941 for ; Tue, 29 Jan 2002 04:42:16 -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 EAA04531 for ; Tue, 29 Jan 2002 04:42:31 -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 EAA10928 for ; Tue, 29 Jan 2002 04:42:30 -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 HAA01201; Tue, 29 Jan 2002 07:42:27 -0500 (EST) Message-Id: <200201291242.HAA01201@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-morrow-mipv6-zod-00.txt Date: Tue, 29 Jan 2002 07:42:26 -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 : Diversion with No Transport Overhead Author(s) : G. Morrow Filename : draft-morrow-mipv6-zod-00.txt Pages : 20 Date : 28-Jan-02 Under certain circumstances the desired effects of diversion can be achieved with no per-packet transport overhead. This draft describes these circumstances as well as the per-packet bearer processing and general signaling requirements of some proposals that strive to remove the need for this overhead. The first proposal is referred to as Zero-Overhead Diversion (ZOD). The second is referred to as More Robust Zero-Overhead Diversion (MR. ZOD). Mobile IP and load distribution are examples of the useful application of diversion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morrow-mipv6-zod-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-morrow-mipv6-zod-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-morrow-mipv6-zod-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020128151033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-morrow-mipv6-zod-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-morrow-mipv6-zod-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020128151033.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 08:52: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 IAA03090 for ; Tue, 29 Jan 2002 08:52:26 -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 GAA24443; Tue, 29 Jan 2002 06:52: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 FAA11149; Tue, 29 Jan 2002 05:52: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 g0TDp52Q006093 for ; Tue, 29 Jan 2002 05:51:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TDp5v4006092 for mobile-ip-dist; Tue, 29 Jan 2002 05:51:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TDox2Q006085 for ; Tue, 29 Jan 2002 05:51:00 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TDpCF20188; Tue, 29 Jan 2002 14:51:12 +0100 (MET) Date: Tue, 29 Jan 2002 14:47:38 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation To: charliep@iprg.nokia.com Cc: "Basavaraj Patil (NTC/Dallas)" , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C55884C.3EB332C5@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Hello Basavaraj, > > While I think a new Destination Option will work fine, > I also think the Routing Header would work fine. If protocol > cannot be built using the Routing Header, then it should > be removed from the IPv6 protocol specification. Charlie, I think the routing header works fine for doing source routing i.e. specifying the addresses for different routers (or sets of routers using anycast addresses) to indicate the path that packets will take. While the mechanism could be used to specify multiple IP addresses assigned to the same node as done in MIPv6, this overloading might have some issues as the writeup points out. So I don't see what this has to due with the usefulness of the routing header in general. > It is a huge waste of time for us to build according to > the IPv6 specification, only to be told later that the > specs were "just kidding" -- e.g., because of firewall > administrative bias. Your wording makes it look like you think that this is some proclamation from a higher authority, which is not the case. The email I sent was trying to capture the issues that have been discussed in the WG for some time to see if there is concensus about the direction of the thinking in the design team. Thus there isn't an "us" and "them" here. The folks on the design team as well as the working group want to see MIPv6 finished and deployed. If we identify deployment concerns around firewalls it is better to resolve those sooner rather than later. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 08:58: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 IAA03262 for ; Tue, 29 Jan 2002 08:58:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07856; Tue, 29 Jan 2002 05:58:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12052; Tue, 29 Jan 2002 05:58: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 g0TDvg2Q006154 for ; Tue, 29 Jan 2002 05:57:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TDvf8Q006153 for mobile-ip-dist; Tue, 29 Jan 2002 05:57:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TDvb2Q006146 for ; Tue, 29 Jan 2002 05:57:38 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TDvmF20723; Tue, 29 Jan 2002 14:57:49 +0100 (MET) Date: Tue, 29 Jan 2002 14:54:15 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 To: jmalinen@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com, petrescu@crm.mot.com, Pekka Nikander In-Reply-To: "Your message with ID" <3C55987C.BECFF1EB@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I would briefly just like to note (being involved implementing > some other things too) that _if_ solutions fulfilling > the security requirements can be achieved by changes in places > other than CN, it might be of interest to consider these, too. As > of the placement of the problem, if I am responsible for a filter > and a cloud of routers where I want locally to ensure optimal > traffic and that malicious things can't happen, would I not have > the same question whether somebody else (a CN) does or does > not do this for me, e.g., if a CN is just a reflector rather > than the victim potentially in my domain. This seemed one point > in your analysis on alternatives on RH? Jari, Perhaps the topic doesn't match the subject line any more and that is causing confusion. By comment was a rather general one with some references to HAO and it didn't have much to do with RH. So I'm a bit puzzled. In general I think you want to apply security both locally and as part of the infrastructure (the routers and firewalls) in order to minimize the risks. I don't think just because roads can be built better (better visibility, less turns, etc) we should reduce the capacity of the breaks in the individual cars; we need some of both. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 09:04: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 JAA03419 for ; Tue, 29 Jan 2002 09:04:18 -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 GAA09738; Tue, 29 Jan 2002 06:03: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 GAA18795; Tue, 29 Jan 2002 06:02: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 g0TE1u2Q006207 for ; Tue, 29 Jan 2002 06:01:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TE1uRV006206 for mobile-ip-dist; Tue, 29 Jan 2002 06:01:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TE1p2Q006199 for ; Tue, 29 Jan 2002 06:01:52 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TE22F21355; Tue, 29 Jan 2002 15:02:02 +0100 (MET) Date: Tue, 29 Jan 2002 14:58:28 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: Routing headers (ISSUE) To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, Francis.Dupont@enst-bretagne.fr In-Reply-To: "Your message with ID" <15445.40521.660622.110222@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik Nordmark writes: > > o A host that supports non-local source-routing MUST have a > > configurable switch to disable forwarding, and this switch > > MUST default to disabled. > > Under what conditions would a user not be crazy to > enable it? Parsing problems. I'm assuming you're asking why would anybody ever enable this switch. Perhaps there is a site which internally is using traceroute -g for hosts today (i.e. the NOC does a traceroute -g when the debug problems) and they want to preserve this. So they use their automagic management tools to automatically turn on the switch in all of their hosts. But mostly this is a way to handle exceptions to the norm, with the norm being that hosts not forward source routed packets. But, this is a discussion for the ipv6 WG. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 09:13: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 JAA03762 for ; Tue, 29 Jan 2002 09:13: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 HAA07332; Tue, 29 Jan 2002 07:13:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23946; Tue, 29 Jan 2002 06:13: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 g0TECg2Q006280 for ; Tue, 29 Jan 2002 06:12:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TECgcX006279 for mobile-ip-dist; Tue, 29 Jan 2002 06:12: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 g0TECb2Q006272 for ; Tue, 29 Jan 2002 06:12:39 -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 GAA09253 for ; Tue, 29 Jan 2002 06:12:54 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA05161 for ; Tue, 29 Jan 2002 07:12:52 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 15:12:35 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C1QZYG72; Tue, 29 Jan 2002 15:12:28 +0100 From: "Jean-Michel COMBES" To: Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Tue, 29 Jan 2002 15:12:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C55A477.3A4E89C1@iprg.nokia.com> Importance: Normal 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: Content-Transfer-Encoding: 7bit Hi, another question : is RH case really a MIPv6 problem or an IPv6 problem ? Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Jari T. > Malinen > Envoye : lundi 28 janvier 2002 20:20 > A : mobile-ip@sunroof.eng.sun.com > Objet : Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team > recommendation > > > Jean, > > > Excuse me but I think I missed an episode : > > 1. at first, RH is said to be dangerous [Why not ...] > > 2. after, one idea to replace RH functionality is to create a > new DO [Why > > not ...] > > 3. and now, it is proposed to place this new DO between the > fragment header > > and the ... RH [!?!] > > Seems a bit funny, doesn't it. However, what does not meet the > eye are the ordering rules for a packet as compared to what > is actually in the packet. RH issue seems to be rather thoroughly > analyzed in the security recommendations.. > > > Regards. > > > > JMC. > > > > France Telecom R&D - DTL/SSR > > Jean-Michel COMBES, Internet/Intranet Security > > E-Mail : jeanmichel.combes@francetelecom.com > > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > > BR, > > -Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 09:17: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 JAA03855 for ; Tue, 29 Jan 2002 09:17:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09311; Tue, 29 Jan 2002 07:17:01 -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 GAA25560; Tue, 29 Jan 2002 06:16:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TEEc2Q006318 for ; Tue, 29 Jan 2002 06:14:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TEEchU006317 for mobile-ip-dist; Tue, 29 Jan 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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TEEX2Q006307 for ; Tue, 29 Jan 2002 06:14:33 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TEEgF23121; Tue, 29 Jan 2002 15:14:42 +0100 (MET) Date: Tue, 29 Jan 2002 15:11:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 To: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com, Pekka Nikander In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik, I'm trying to avoid generating too much text, this is why my > phrases are short. My observation was mainly that when handing over > with change in CoAs and according to existing "fast" proposals there > is a certain number of messages involved before being able to use that > CoA. To those messages one should potentially add RR _and_ CGA's > exchanges. This, again IMHO, inevitably lengthens the timespan over > which my MN won't use the new CoA. If I'm missing anything, please > correct me. So you are talking about both regular MIPv6 and MIPv6 with some local mobility management it seems. In the regular MIPv6 case the need for an RR check against the new CoA (in order to prevent bombing attacks) adds time to the handover - 3 times the one way delay compared to 1 times the one way delay (MN-CN) without an RR check. In the case of CGA where the bottom 64 bits of the CoA is the same as the bottom 64 of the HoA then potentially one could avoid such an RR check - without the RR check it would not be possible to bomb a host but "merely" be able to bomb a /64 prefix (a link) with unwanted traffic. But the most safe thing would be to always do the RR check. In any case the CGA calculations would not need to be redone - with CGA it makes a lot of sense to have a binding security association. I guess there is an open question for localized mobility management around trust issues, threat models, etc that may or may not result in a need for a *local* RR check e.g. involving the previous AR, new AR, and MN. But that's just utter speculation on my behalf at this point in time. > I know you already pointed that "number of messages" is an odd > criteria to compare MIP security proposals, just thought that it might > make more sense here. I think I pointed out that number of messages multiplied by the number of "hops" might be an odd one. Number of rtts, especially for packets over a high latency wireless link, is quite important. But assuming that the goal is to be able to refresh the binding when not moving bthen we can let local mobility management of some form help optimize the when the CoA changes. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 09:49: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 JAA04660 for ; Tue, 29 Jan 2002 09:49: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 HAA29445; Tue, 29 Jan 2002 07:48: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 GAA11651; Tue, 29 Jan 2002 06:48:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TElE2Q006447 for ; Tue, 29 Jan 2002 06:47:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TElET0006446 for mobile-ip-dist; Tue, 29 Jan 2002 06:47: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 g0TEl92Q006439 for ; Tue, 29 Jan 2002 06:47:11 -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 GAA06209 for ; Tue, 29 Jan 2002 06:47:25 -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 HAA26926 for ; Tue, 29 Jan 2002 07:47:24 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TElOj27902 for ; Tue, 29 Jan 2002 16:47:24 +0200 Date: Tue, 29 Jan 2002 16:47:23 +0200 (EET) From: Pekka Savola To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONC LUSION) In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A95B@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: On Mon, 28 Jan 2002, Hesham Soliman (ERA) wrote: > => I agree with the analysis and recommendation, but > would prefer to use a new RH type, than a DO. For > the same reasons that Francis mentioned. RH type > or IP_NO_SRC, I'm neutral, whatever takes less time. A note on new RH type: if we go this direction, I think the best semantic to specify is that it must be Home Address of the node. Simple and elegant. Another note: make sure that old RH (for traffic engineering) and new RH (CoA, HA mapping): that is, new RH must be after old RH in the header chain. -- 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 Jan 29 10:07: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 KAA05254 for ; Tue, 29 Jan 2002 10:07: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 HAA05064; Tue, 29 Jan 2002 07:07: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 HAA21326; Tue, 29 Jan 2002 07:06: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 g0TF5A2Q006515 for ; Tue, 29 Jan 2002 07:05:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TF5Awl006514 for mobile-ip-dist; Tue, 29 Jan 2002 07:05: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 g0TF562Q006507 for ; Tue, 29 Jan 2002 07:05: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 HAA22150 for ; Tue, 29 Jan 2002 07:04:55 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02641 for ; Tue, 29 Jan 2002 08:04:54 -0700 (MST) Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g0TF4dh21865 for ; Tue, 29 Jan 2002 16:04:39 +0100 (MET) Message-ID: <3C56BA91.2C32B2D4@inrialpes.fr> Date: Tue, 29 Jan 2002 16:06:57 +0100 From: Pars MUTAF X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: 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 Nordmark wrote: > > > I know you already pointed that "number of messages" is an odd > > criteria to compare MIP security proposals, just thought that it might > > make more sense here. > > I think I pointed out that number of messages multiplied by the number of > "hops" might be an odd one. > Number of rtts, especially for packets over a high latency wireless link, > is quite important. > But assuming that the goal is to be able to refresh the binding > when not moving bthen we can let local mobility management of some form > help optimize the when the CoA changes. > I wonder why "packet size" is not taken into consideration. In a radio network packet transmission is the most power consuming thing and power consumption linearly increases with packet size. So, if a key establishment extension contains lots of cryptographic data, this will: 1. Increase power consumption on hosts, 2. Increase packet loss rate, hence the actual number of packets exchanged (and, consume more power). I'm too pessimistic? REgards, pars From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 10:10: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 KAA05406 for ; Tue, 29 Jan 2002 10:10: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 HAA06569; Tue, 29 Jan 2002 07:10:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23037; Tue, 29 Jan 2002 07:10: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 g0TF9V2Q006567 for ; Tue, 29 Jan 2002 07:09:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TF9VT5006566 for mobile-ip-dist; Tue, 29 Jan 2002 07:09:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TF9R2Q006559 for ; Tue, 29 Jan 2002 07:09:27 -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 HAA22781 for ; Tue, 29 Jan 2002 07:09:32 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16755 for ; Tue, 29 Jan 2002 07:09:31 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0TF9UC19164 for ; Tue, 29 Jan 2002 16:09:30 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jan 29 16:09:29 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:00:16 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A96D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONC LUSION) Date: Tue, 29 Jan 2002 16:09:02 +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: > From: Pekka Savola > > => I agree with the analysis and recommendation, but > > would prefer to use a new RH type, than a DO. For > > the same reasons that Francis mentioned. RH type > > or IP_NO_SRC, I'm neutral, whatever takes less time. > > A note on new RH type: if we go this direction, I think the > best semantic > to specify is that it must be Home Address of the node. Simple and > elegant. > > Another note: make sure that old RH (for traffic > engineering) and new RH > (CoA, HA mapping): that is, new RH must be after old RH in > the header > chain. => Yes, makes sense. Hesham > > -- > 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 Jan 29 10:15:57 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05527 for ; Tue, 29 Jan 2002 10:15:56 -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 HAA09080; Tue, 29 Jan 2002 07:15:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26037; Tue, 29 Jan 2002 07:15: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 g0TFEP2Q006724 for ; Tue, 29 Jan 2002 07:14:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFEPNY006723 for mobile-ip-dist; Tue, 29 Jan 2002 07:14: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 g0TFEM2Q006716 for ; Tue, 29 Jan 2002 07:14:22 -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 HAA22955 for ; Tue, 29 Jan 2002 07:14:37 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18683 for ; Tue, 29 Jan 2002 07:14:36 -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 g0TFEZC23221 for ; Tue, 29 Jan 2002 16:14:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 29 16:13:34 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:04:21 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A96E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Tue, 29 Jan 2002 16:13:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > I wonder why "packet size" is not taken into consideration. > In a radio > network packet transmission is the most power consuming thing and > power consumption linearly increases with packet size. > > So, if a key establishment extension contains lots of > cryptographic data, > this will: > > 1. Increase power consumption on hosts, > 2. Increase packet loss rate, hence the actual number of > packets exchanged > (and, consume more power). > > I'm too pessimistic? => No. But maybe one thing to consider is that if we have cryptographic data, then we can establish a BSA. So the MN doesn't need to re-send a number of messages every time it moves. Instead only one BU. If this is not an issue and the MN will not move very often, then reducing cryptographic data might have some advantages for power saving. Hesham > > REgards, > pars > From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 10:29:37 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06085 for ; Tue, 29 Jan 2002 10:29:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14994; Tue, 29 Jan 2002 07:29:24 -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 HAA03876; Tue, 29 Jan 2002 07:29: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 g0TFSA2Q006878 for ; Tue, 29 Jan 2002 07:28:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFSAZj006877 for mobile-ip-dist; Tue, 29 Jan 2002 07: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFS52Q006870 for ; Tue, 29 Jan 2002 07:28:06 -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 HAA03256 for ; Tue, 29 Jan 2002 07:28:20 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19558 for ; Tue, 29 Jan 2002 08:28:19 -0700 (MST) Received: from jariws1 ([62.248.150.39]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020129152817.UBZO24910.fep01-app.kolumbus.fi@jariws1>; Tue, 29 Jan 2002 17:28:17 +0200 Message-ID: <005101c1a8d9$942978c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pars MUTAF" Cc: References: <3C56BA91.2C32B2D4@inrialpes.fr> Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 Date: Tue, 29 Jan 2002 17:28:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I wonder why "packet size" is not taken into consideration. In a radio > network packet transmission is the most power consuming thing and > power consumption linearly increases with packet size. It has an effect, yes. Maybe even a significant effect even for our case if we start to include 1500 byte packets. However, the current state of the art in e.g. cellular networks seems to be that the limiting factor is latency, not so much power consumption. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 10:32:53 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06200 for ; Tue, 29 Jan 2002 10: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 HAA16115; Tue, 29 Jan 2002 07:31:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05113; Tue, 29 Jan 2002 07:31: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 g0TFU92Q006913 for ; Tue, 29 Jan 2002 07:30:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFU8Uh006912 for mobile-ip-dist; Tue, 29 Jan 2002 07:30: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 g0TFU32Q006905 for ; Tue, 29 Jan 2002 07:30:04 -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 HAA26091 for ; Tue, 29 Jan 2002 07:30:09 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10747 for ; Tue, 29 Jan 2002 08:30:08 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0TFU6X4013404 for ; Tue, 29 Jan 2002 16:30:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jan 29 16:29:38 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:20:25 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A96F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , petrescu@crm.mot.com Cc: Pekka Nikander , "'Erik Nordmark'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Tue, 29 Jan 2002 16:29: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: Erik wrote: > I guess there is an open question for localized mobility > management around > trust issues, threat models, etc that may or may not result > in a need > for a *local* RR check e.g. involving the previous AR, new > AR, and MN. > But that's just utter speculation on my behalf at this > point in time. => I think this is true. I think LMM/FMIP schemes would require some stronger form of security due to the large impact of the security breach (switching all packets off for the MN !). Since these mechanisms were designed to speed up handovers and reduce signalling, it would make sense IMHO to have a solution that will be 'secure enough' to allow for a BSA. For example, a MN can have a BSA with a MAP so movement only results in one BU being sent. The same goes for the MN - old AR relationship, a BSA + Context transfer would reduce the time required for a MN to establish an SA and hence speed the IP handover. This is one of the reasons I'm in favour of a solution that allows for a BSA. If we have it, we wouldn't need to go through this work next time round. The price for that solution is certainly an important consideration, but maybe having optional optimisations (like CGA) from day one could solve this. I think the lack of 'fast handovers' for MIP can affect its deployment to a large extent. Sorry for the pessimism but people continue to claim the MIP as it is, is not fast enough :( I think we can prove that wrong, or at least try. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 10:39:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06375 for ; Tue, 29 Jan 2002 10:39:00 -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 IAA05520; Tue, 29 Jan 2002 08:38:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08879; Tue, 29 Jan 2002 07:38: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 g0TFbw2Q007034 for ; Tue, 29 Jan 2002 07:37:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFbvQt007033 for mobile-ip-dist; Tue, 29 Jan 2002 07:37:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFbr2Q007026 for ; Tue, 29 Jan 2002 07:37:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28177 for ; Tue, 29 Jan 2002 07:38:08 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04839 for ; Tue, 29 Jan 2002 08:38:06 -0700 (MST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id QAA28598; Tue, 29 Jan 2002 16:38:05 +0100 (MET) Date: Tue, 29 Jan 2002 16:38:05 +0100 (MET) Message-Id: <200201291538.QAA28598@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com In-reply-to: <3C56BA91.2C32B2D4@inrialpes.fr> (message from Pars MUTAF on Tue, 29 Jan 2002 16:06:57 +0100) Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C56BA91.2C32B2D4@inrialpes.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: Pars MUTAF writes: I wonder why "packet size" is not taken into consideration. In a radio network packet transmission is the most power consuming thing and power consumption linearly increases with packet size. So, if a key establishment extension contains lots of cryptographic data, this will: 1. Increase power consumption on hosts, 2. Increase packet loss rate, hence the actual number of packets exchanged (and, consume more power). I'm too pessimistic? Power consumption does not depend linearly on packet size, since much of the power is just powering up, running clocks, etc. Nor is transmitting the most power consuming aspect of wireless, in most cases it is receiving because you are in the receive state a lot longer than you are in the transmit state (especially for a mobile). In 1999, Elisabetta Carerra, wrote a MS thesis, "Wireless Adaptation of a security Management Protocol Suite", showing that you can do field specific compression - and thus fit the messages into as few radio frames as possible. In addition, she gives a detailed analysis of IPSec over a wireless link. You can find a copy at: http://www.it.kth.se/~maguire/Elisabetta_Carrara-thesis-final.ps Chip From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 10:48:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06709 for ; Tue, 29 Jan 2002 10:48:40 -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 IAA13394; Tue, 29 Jan 2002 08:48: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 HAA22522; Tue, 29 Jan 2002 07:48: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 g0TFlR2Q007119 for ; Tue, 29 Jan 2002 07:47:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFlRVd007118 for mobile-ip-dist; Tue, 29 Jan 2002 07:47:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TFlN2Q007111 for ; Tue, 29 Jan 2002 07:47:24 -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 HAA13441 for ; Tue, 29 Jan 2002 07:47:38 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27640 for ; Tue, 29 Jan 2002 07:47:35 -0800 (PST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id QAA28606; Tue, 29 Jan 2002 16:47:32 +0100 (MET) Date: Tue, 29 Jan 2002 16:47:32 +0100 (MET) Message-Id: <200201291547.QAA28606@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: pars.mutaf@inrialpes.fr, mobile-ip@sunroof.eng.sun.com In-reply-to: <005101c1a8d9$942978c0$8a1b6e0a@arenanet.fi> (jari.arkko@kolumbus.fi) Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C56BA91.2C32B2D4@inrialpes.fr> <005101c1a8d9$942978c0$8a1b6e0a@arenanet.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit For WLAN systems under 802.11 most use fixed transmit power even though this may mean using (much) more power than actually necessary and even though this may increase the range of interference with others using this channel (or adjacent channels) in another cells. Jean-Pierre Ebert of the Telecommunication Networks Lab, Department of Electrical Engineering, Technical University of Berlin - has written a report describing the power consumption aspect of WLAN transmission when using an interface card which does allow you to very the transmit power: B. Burns and J.-P. Ebert, "Power Consumption, Throughput and Packet Error Measurements of an IEEE 802.11 WLAN Interface", Technical Report TKN-01-007, Telecommunication Networks Group, Technische Universität Berlin, August 2001. http://www-tkn.ee.tu-berlin.de/publications/papers/tr_01_007.pdf There are several related papers such as: J.-P. Ebert and A. Wolisz, "Combined Tuning of RF Power and Medium Access Control for WLANs", Mobile Networks & Applications, vol. 6, no. 5, pp. 417-426, September 2001, in Journal of Mobile Networks and Applications (Monet), Netherlands. http://www-tkn.ee.tu-berlin.de/publications/papers/monet2000e_1.pdf J.-P. Ebert, B. Stremmel, E. Wiederhold, and A. Wolisz, "An Energy-efficient Power Control Approach for WLANs", Journal of Communications and Networks (JCN), vol. 2, no. 3, pp. 197-206, September 2000, publication of Korean Institute of Communications Sciences (KICS). http://www-tkn.ee.tu-berlin.de/publications/papers/JCN2000.pdf Since these effects occur with every packet you transmit and the fraction of packets which you will transmit to negociate keys, etc. is likely to be tiny -- I don't think that the optimization of key exchange has any significance with respect to power consumption. Except for latency, I'm not sure that the transmission and reception of these packets actually has _any_ significant effects on the mobile. Chip From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 10:49:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06766 for ; Tue, 29 Jan 2002 10:49:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14220; Tue, 29 Jan 2002 08:49: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 HAA22854; Tue, 29 Jan 2002 07:49: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 g0TFmZ2Q007139 for ; Tue, 29 Jan 2002 07:48:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFmZpH007138 for mobile-ip-dist; Tue, 29 Jan 2002 07:48: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 g0TFmU2Q007128 for ; Tue, 29 Jan 2002 07:48:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29478 for ; Tue, 29 Jan 2002 07:48:45 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03018 for ; Tue, 29 Jan 2002 07:48:44 -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 g0TFmhX4025034 for ; Tue, 29 Jan 2002 16:48:43 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 29 16:48:39 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:39:26 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A973@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 Date: Tue, 29 Jan 2002 16:48:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alex I don't know if this was already answered...so I'll answer it anyway > Reversing your statement, I truly support the future > attacks argument > in that, as an implementor of MN, I don't want CN's services to our > MN's be denied. But also as an implementor of MN's I can say that > everything is possible; only when crypto comes in it gets rather > complex. I'm a bit doubtful of public key operations every time MN > moves => But that does not need to be the case. A BSA can be established. or by core network routing according to keys (in addresses). => Routing in the core network is never done on the interface id anyway. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 11:53:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09098 for ; Tue, 29 Jan 2002 11:53: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 IAA24592; Tue, 29 Jan 2002 08:47:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10729; Tue, 29 Jan 2002 08:43: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 g0TGgc2Q007510 for ; Tue, 29 Jan 2002 08:42:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TGgbBH007509 for mobile-ip-dist; Tue, 29 Jan 2002 08:42: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 g0TGgW2Q007502 for ; Tue, 29 Jan 2002 08:42:34 -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 IAA13268 for ; Tue, 29 Jan 2002 08:42:48 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24687 for ; Tue, 29 Jan 2002 08:42:46 -0800 (PST) Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g0TGgLh25037 for ; Tue, 29 Jan 2002 17:42:21 +0100 (MET) Message-ID: <3C56D17A.7017A577@inrialpes.fr> Date: Tue, 29 Jan 2002 17:44:42 +0100 From: Pars MUTAF X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C56BA91.2C32B2D4@inrialpes.fr> <200201291538.QAA28598@dumburken.it.kth.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Gerald Maguire wrote: > > Power consumption does not depend linearly on packet size, since much > of the power is just powering up, running clocks, etc. I meant power consumption due to communication... > Nor is transmitting the most power consuming aspect of wireless, in > most cases it is receiving because you are in the receive state a lot > longer than you are in the transmit state (especially for a mobile). > I was referring to the following paper: "Measuring and Reducing Energy Consumption of Network Interfaces in Hand-Held Devices" Mark Stemm and Randy H. Katz {stemm,randy}@CS.Berkeley.EDU Computer Science... IEICE Transactions on Communications, vol.E80-B, no.8, p. 1125-31 http://citeseer.nj.nec.com/stemm97measuring.html ---- BTW, thank you for the papers, I'll read them. Regards, pars From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 11:55:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09122 for ; Tue, 29 Jan 2002 11:55:02 -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 IAA12679; Tue, 29 Jan 2002 08:25: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 IAA26151; Tue, 29 Jan 2002 08:00: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 g0TFx42Q007328 for ; Tue, 29 Jan 2002 07:59:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TFx3hE007327 for mobile-ip-dist; Tue, 29 Jan 2002 07: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 g0TFwx2Q007320 for ; Tue, 29 Jan 2002 07:59:00 -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 HAA03297 for ; Tue, 29 Jan 2002 07:59:14 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07204 for ; Tue, 29 Jan 2002 07:59:13 -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 g0TFxDC27282 for ; Tue, 29 Jan 2002 16:59:13 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jan 29 16:59:12 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 16:49:59 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A976@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] LMM requirements - last call ? Date: Tue, 29 Jan 2002 16:58:47 +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, I know this is off-track right now but are we going for last call with the LMM requirements draft ? As far as I remember all comments were addressed by Carl. I don't think this is dependant on any MIPv6 security discussions, is it ? Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:09:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09618 for ; Tue, 29 Jan 2002 12:09:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26577; Tue, 29 Jan 2002 10:09:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16859; Tue, 29 Jan 2002 09:09: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 g0TH8H2Q007674 for ; Tue, 29 Jan 2002 09:08:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TH8HBM007673 for mobile-ip-dist; Tue, 29 Jan 2002 09:08:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TH8D2Q007666 for ; Tue, 29 Jan 2002 09:08:14 -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 JAA23065 for ; Tue, 29 Jan 2002 09:08:28 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15518 for ; Tue, 29 Jan 2002 10:08:27 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0TH8Re13685; Tue, 29 Jan 2002 09:08:27 -0800 (PST) Message-ID: <00ae01c1a8e7$58077500$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: , "Pekka Nikander" References: Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 Date: Tue, 29 Jan 2002 09:06:50 -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, > So you are talking about both regular MIPv6 and MIPv6 with some > local mobility management it seems. > > In the regular MIPv6 case the need for an RR check against the new CoA > (in order to prevent bombing attacks) adds time to the handover - 3 times > the one way delay compared to 1 times the one way delay (MN-CN) without an > RR check. > In the case of CGA where the bottom 64 bits of the CoA is the same as > the bottom 64 of the HoA then potentially one could avoid such an RR > check - without the RR check it would not be possible to bomb a host but > "merely" be able to bomb a /64 prefix (a link) with unwanted traffic. > But the most safe thing would be to always do the RR check. > In any case the CGA calculations would not need to be redone - with CGA it > makes a lot of sense to have a binding security association. > > I guess there is an open question for localized mobility management around > trust issues, threat models, etc that may or may not result in a need > for a *local* RR check e.g. involving the previous AR, new AR, and MN. > But that's just utter speculation on my behalf at this point in time. > > > I know you already pointed that "number of messages" is an odd > > criteria to compare MIP security proposals, just thought that it might > > make more sense here. > > I think I pointed out that number of messages multiplied by the number of > "hops" might be an odd one. > Number of rtts, especially for packets over a high latency wireless link, > is quite important. > But assuming that the goal is to be able to refresh the binding > when not moving bthen we can let local mobility management of some form > help optimize the when the CoA changes. > Your calculations emphasize a point I have been trying to make for some time: changing CoA on every handover is expensive. Adding security to BUs will make it even more expensive. Now, I know there are people out there who believe: "If it doesn't change it's Care of Address on every handover, it isn't Mobile IP(tm)." I happen to believe that it is more important to get something that performs well, so IP can become a viable alternative for wireless real time traffic. Thus, I believe a mixture of handovers in which the MN changes its CoA and doesn't should be acceptable, with the MN and maybe the network deciding when the CoA should be changed. There is protocol in FMIPv6 now to do just that, and it can also be done using forwarding from previous CoA in the base spec with regular MIP. So I don't think the impact of BU security on handover should be a consideration. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:17: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 MAA09903 for ; Tue, 29 Jan 2002 12:17:08 -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 KAA03867; Tue, 29 Jan 2002 10:16: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 JAA18714; Tue, 29 Jan 2002 09:16: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 g0THFQ2Q007725 for ; Tue, 29 Jan 2002 09:15:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THFQAX007724 for mobile-ip-dist; Tue, 29 Jan 2002 09:15:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THFL2Q007717 for ; Tue, 29 Jan 2002 09:15:23 -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 JAA01380 for ; Tue, 29 Jan 2002 09:15:37 -0800 (PST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08252 for ; Tue, 29 Jan 2002 10:15:36 -0700 (MST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id SAA28761; Tue, 29 Jan 2002 18:15:34 +0100 (MET) Date: Tue, 29 Jan 2002 18:15:34 +0100 (MET) Message-Id: <200201291715.SAA28761@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com In-reply-to: <3C56D17A.7017A577@inrialpes.fr> (message from Pars MUTAF on Tue, 29 Jan 2002 17:44:42 +0100) Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 References: <3C56BA91.2C32B2D4@inrialpes.fr> <200201291538.QAA28598@dumburken.it.kth.se> <3C56D17A.7017A577@inrialpes.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: Pars MUTAF > Maguire: > Power consumption does not depend linearly on packet size, since much > of the power is just powering up, running clocks, etc. I meant power consumption due to communication... My point is that the tranmitting of the bits in the frame is not as dominant a source of power consumption as you might assume. For much deeper analysis & measurments of power consumption, along with ways to reduce power -- see the papers of Dr. Tajana Simunic, et al. http://akebono.stanford.edu/users/tajana/Papers.html Chip From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:23:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10104 for ; Tue, 29 Jan 2002 12:23:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11769; Tue, 29 Jan 2002 09:17:38 -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 JAA18373; Tue, 29 Jan 2002 09:16: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 g0THEq2Q007712 for ; Tue, 29 Jan 2002 09:14:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THEqs7007711 for mobile-ip-dist; Tue, 29 Jan 2002 09:14: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 g0THEm2Q007704 for ; Tue, 29 Jan 2002 09:14:49 -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 JAB25726 for ; Tue, 29 Jan 2002 09:15:03 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17983 for ; Tue, 29 Jan 2002 10:15:02 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0THF0e13985; Tue, 29 Jan 2002 09:15:00 -0800 (PST) Message-ID: <00be01c1a8e8$42380090$7e6015ac@T23KEMPF> From: "James Kempf" To: , Cc: "Pekka Nikander" , "'Erik Nordmark'" References: <4DA6EA82906FD511BE2F00508BCF053802C6A96F@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem to exist in IPv4 Date: Tue, 29 Jan 2002 09:13:23 -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 price for that solution is certainly an > important consideration, but maybe having optional > optimisations (like CGA) from day one could > solve this. > I have not yet made up my mind whether CGA or RR is a better solution, as I am waiting for the design team's report. However, one possibility that has me leaning in the direction of CGAs is the applicability to other problems in mobile computing, like, possibly, IP paging security. > I think the lack of 'fast handovers' for MIP > can affect its deployment to a large extent. > Sorry for the pessimism but people continue to > claim the MIP as it is, is not fast enough :( > I think we can prove that wrong, or at least > try. > Here we agree. It is most unfortunate, but probably inevitable, that the WG seems only able to concentrate on one problem at a time. The focus on security for MIPv6 seems to be excluding all but peripheral discussion on other issues. While I agree that it is the top priority, I wish we could get more attention to fast handovers. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:29: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 MAA10424 for ; Tue, 29 Jan 2002 12:29: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 KAA14555; Tue, 29 Jan 2002 10:29: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 JAA24237; Tue, 29 Jan 2002 09: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 g0THRs2Q007871 for ; Tue, 29 Jan 2002 09:27:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THRrUx007870 for mobile-ip-dist; Tue, 29 Jan 2002 09:27:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THRo2Q007863 for ; Tue, 29 Jan 2002 09:27:51 -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 JAA08282 for ; Tue, 29 Jan 2002 09:28:06 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18845 for ; Tue, 29 Jan 2002 09:28:02 -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 g0THSCi10542 for ; Tue, 29 Jan 2002 19:28:12 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Jan 2002 19:27:55 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 29 Jan 2002 19:27:56 +0200 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 11:27:52 -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] LMM requirements - last call ? Date: Tue, 29 Jan 2002 11:27:52 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD5D2@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] LMM requirements - last call ? Thread-Index: AcGo5cI2pAc1qocISzqAWiHZXUHWPQABCt5w To: X-OriginalArrivalTime: 29 Jan 2002 17:27:52.0699 (UTC) FILETIME=[480204B0:01C1A8EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0THRp2Q007864 Sender: owner-mobile-ip@sunroof.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, > > I know this is off-track right now but > are we going for last call with the LMM > requirements draft ? As far as I remember > all comments were addressed by Carl. > > I don't think this is dependant on any > MIPv6 security discussions, is it ? The LMM I-D does have a normative dependence on Mobile IPv6. Compleitng WG last call will not necessarily cause this I-D to progress unless we get MIPv6 done first. Conclusion: Lets hold off on WG last call until the MIPv6 spec is done. > > Cheers, > Hesham -Basavaraj > From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:38: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 MAA10737 for ; Tue, 29 Jan 2002 12:38: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 KAA23505; Tue, 29 Jan 2002 10:37: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 JAA27754; Tue, 29 Jan 2002 09:37: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 g0THaq2Q008048 for ; Tue, 29 Jan 2002 09:36:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THaqbf008047 for mobile-ip-dist; Tue, 29 Jan 2002 09:36:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THan2Q008040 for ; Tue, 29 Jan 2002 09:36:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13731 for ; Tue, 29 Jan 2002 09:37:05 -0800 (PST) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02854 for ; Tue, 29 Jan 2002 10:37:04 -0700 (MST) Received: from pthubertw2k (dhcp-nic-val-26-243.cisco.com [64.103.26.243]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id SAA28679 for ; Tue, 29 Jan 2002 18:37:03 +0100 (MET) From: "Pascal Thubert" To: Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) Date: Tue, 29 Jan 2002 18:37:03 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Is the requirement that a mobile router should be able to (or always) remove this "routing element" from the packet before delivering them to MNs behind the MR? I understand that this discussion is a bit out of scope, yet it would be beneficial if Mobile Nodes and Mobile Routers could as much as possible behave consistently. I agree that mobile Router may want to hide the mobility to Static Nodes. But the point here seems more that a Mobile Router may attach to a Mobile Network of another MR in a nested configuration. This recursively builds a graph of Mobile Routers. A solution which finally builds allows the CN/HA to send a RH with all the VIA MRs of the nested networks would be best from the MR standpoint... Pascal Thubert From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:50:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11102 for ; Tue, 29 Jan 2002 12:50:09 -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 KAA05525; Tue, 29 Jan 2002 10:50: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 JAA03369; Tue, 29 Jan 2002 09:49:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THmf2Q008168 for ; Tue, 29 Jan 2002 09:48:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THmeSA008167 for mobile-ip-dist; Tue, 29 Jan 2002 09:48:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THma2Q008160 for ; Tue, 29 Jan 2002 09:48:37 -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 JAA26560; Tue, 29 Jan 2002 09:48:52 -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 JAA26985; Tue, 29 Jan 2002 09:48:51 -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 g0THmn316449; Tue, 29 Jan 2002 18:48: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 SAA08376; Tue, 29 Jan 2002 18:48: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 g0THmng34527; Tue, 29 Jan 2002 18:48:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201291748.g0THmng34527@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) In-reply-to: Your message of Mon, 28 Jan 2002 15:29:38 +0100. Date: Tue, 29 Jan 2002 18:48: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: In your previous mail you wrote: > => a new destination option doesn't work well for a mobile router. > IMHO we should keep the "routing" element from Routing Headers > (so I am still in favour of either a new type of RH or Steve > Deering's special cases of tunnels. While mobile routers and mobile networks are out of scope => they are out of scope but we should not impede future works about them (we are in a "matter of taste" case so any argument should be accepted). I think it would be useful to try to understand what you think is the requirement here because deering/zill tunneling and a new RH type seems to have rather different properties. => tunnels, degenerated tunnels (Deering/Zill) and RH are routing devices (this is my first argument against DO which is not a routing device). None of them have a "end node" property like a DO, i.e. the action of the routing device can finish before the real destination. This is my second argument against DO which has not this feature (which can be very useful for mobile routers or networks). I can see a deep difference between tunnels and degenerated tunnels but I agree there is one between tunnels and RH: RH has a history feature, i.e. after its action it is possible to know what happens. This feature can be useful for security, for instance with ingress filtering a tunnel must be integrated in the whole routing system in order to be taken into account (a recurrent problem with tunneling :-), RH gives the previous intermediate source... This is the second "small" argument in favor of RH, the first one is of course the deployment/procedure simplicity. Is the requirement that a mobile router should be able to (or always) remove this "routing element" from the packet before delivering them to MNs behind the MR? => I can't see a general case where this removal is useful. Deering/zill tunneling would potentially allow that (assuming the tunnel terminates at the MR) but destination options or new RH type would not allow that as far as I can tell. => IMHO the "end node" property is far more important (in the down side) than the history property (where RH is better than DO because RH type 0 was designed to be reversible). But today I believe we should invest more to reach a consensus about approach #3... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 12:53:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11282 for ; Tue, 29 Jan 2002 12:53:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09960; Tue, 29 Jan 2002 10:53: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 JAA05108; Tue, 29 Jan 2002 09:53:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THqR2Q008301 for ; Tue, 29 Jan 2002 09:52:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0THqQjc008300 for mobile-ip-dist; Tue, 29 Jan 2002 09:52:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0THqN2Q008293 for ; Tue, 29 Jan 2002 09:52:23 -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 JAA24772 for ; Tue, 29 Jan 2002 09:52:39 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28521 for ; Tue, 29 Jan 2002 09:52:38 -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 g0THqbX4017780 for ; Tue, 29 Jan 2002 18:52:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Jan 29 18:52:37 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 18:43:24 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6A977@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] LMM requirements - last call ? Date: Tue, 29 Jan 2002 18:52: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: > I know this is off-track right now but > > are we going for last call with the LMM > > requirements draft ? As far as I remember > > all comments were addressed by Carl. > > > > I don't think this is dependant on any > > MIPv6 security discussions, is it ? > > The LMM I-D does have a normative dependence > on Mobile IPv6. Compleitng WG last call will not > necessarily cause this I-D to progress unless we > get MIPv6 done first. => Sure but I assume this is an informational RFC. You can reference a draft in an informational RFC then update it later. I'm just trying to parallelise things a bit. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 13:53: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 NAA15124 for ; Tue, 29 Jan 2002 13:53:35 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10832; Tue, 29 Jan 2002 11:53:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07070; Tue, 29 Jan 2002 10:53: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 g0TIpv2Q008684 for ; Tue, 29 Jan 2002 10:51:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TIpv1J008683 for mobile-ip-dist; Tue, 29 Jan 2002 10:51: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 g0TIps2Q008676 for ; Tue, 29 Jan 2002 10:51:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06329 for ; Tue, 29 Jan 2002 10:52:09 -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 LAA21255 for ; Tue, 29 Jan 2002 11:52:08 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TIq5E29812 for ; Tue, 29 Jan 2002 20:52:05 +0200 Date: Tue, 29 Jan 2002 20:52:04 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] RH for Hosts draft for ipv6 wg [Re: Routing headers (ISSUE)] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-931612806-1012330324=:29771" Sender: owner-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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1589707168-931612806-1012330324=:29771 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 28 Jan 2002, Pekka Savola wrote: > I can make a very short draft (~2 pages including the disclaimers :-) on > the issue before IETF53 as a placeholder until the requirements draft > appears, and if ipv6wg deems it appropriate, present the issue. Attached is a draft I wrote. Originally I didn't want to add my view of the issue (because then reaching consensus might be more difficult), but in the end put it in an appendix. Any comments? Disagreement? -- 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 --1589707168-931612806-1012330324=:29771 Content-Type: TEXT/plain; name="rh-hosts.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="rh-hosts.txt" Content-Transfer-Encoding: BASE64 DQoNCg0KDQoNCg0KSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUC4gU2F2b2xhDQpJbnRl cm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDU0MvRlVORVQNCkV4cGlyYXRpb24gRGF0ZTogSnVs eSAyMDAyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBKYW51YXJ5IDIwMDINCg0KDQogICAg ICAgICAgIE5vdGUgYWJvdXQgUm91dGluZyBIZWFkZXIgUHJvY2Vzc2luZyBv biBJUHY2IEhvc3RzDQoNCiAgICAgICAgICAgICAgICAgICBkcmFmdC1zYXZv bGEtaXB2Ni1yaC1ob3N0cy0wMC50eHQNCg0KU3RhdHVzIG9mIHRoaXMgTWVt bw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFu ZCBpcyBzdWJqZWN0IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBTZWN0aW9u IDEwIG9mIFJGQzIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29y a2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQog ICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtp bmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFs c28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBk b2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVu Y2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVu dCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAg IFRvIHZpZXcgdGhlIGxpc3QgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzLCBzZWUNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0 bWwuDQoNCkFic3RyYWN0DQoNCiAgIFtJUFY2XSBzcGVjaWZpZXMgcm91dGlu ZyBoZWFkZXIgcHJvY2Vzc2luZyBmb3Igbm9kZXMuICBUaGUgdGV4dCBpcw0K ICAgc3VmZmljaWVudGx5IGFtYmlndW91cyB3aGVyZSB0aGUgYmVoYXZpb3Vy IG9mIGhvc3RzIGlzIGNvbmNlcm5lZC4NCiAgIFRoaXMgZHJhZnQgY2xhcmlm aWVzIHRoZSBpc3N1ZSBieSByZWZlcnJpbmcgdG8gSVB2NCBIb3N0IFJlcXVp cmVtZW50cw0KICAgZG9jdW1lbnQgYW5kIHJlcXVpcmluZyBob3N0cyBtdXN0 IG5vdCwgYnkgZGVmYXVsdCwgZm9yd2FyZCByb3V0aW5nDQogICBoZWFkZXJz IG91dHNpZGUgb2YgdGhlIG5vZGUuDQoNCjEuIElzc3VlIHdpdGggUm91dGlu ZyBIZWFkZXIgUHJvY2Vzc2luZw0KDQogICBbSVBWNl0gc3BlY2lmaWVzIHJv dXRpbmcgaGVhZGVyIHByb2Nlc3NpbmcgZm9yIG5vZGVzLiAgVGhlIHRleHQg aXMNCiAgIHN1ZmZpY2llbnRseSBhbWJpZ3VvdXMsIGVzcGVjaWFsbHkgdGhl IDNyZCBwYXJhZ3JhcGggb24gcGFnZSAxMywgdG8NCiAgIG1ha2Ugb25lIGJl bGlldmUgdGhhdCByb3V0aW5nIGhlYWRlciBmb3J3YXJkaW5nIHNob3VsZCBi ZSBlbmFibGVkIG9uDQogICBhbGwgbm9kZXMgKGluY2x1ZGluZyBob3N0cyk7 IGEgZmV3IGltcGxlbWVudGF0aW9ucyBhcmUga25vd24gdG8gaGF2ZQ0KICAg aW50ZXJwcmV0ZWQgdGhlIHNwZWNpZmljYXRpb24gdGhpcyB3YXkuDQoNCg0K DQoNCg0KU2F2b2xhICAgICAgICAgICAgICAgICAgICAgW0V4cGlyZXMgSnVs eSAyMDAyXSAgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5l dCBEcmFmdCAgICAgIGRyYWZ0LXNhdm9sYS1pcHY2LXJoLWhvc3RzLTAwLnR4 dCAgICAgICBKYW51YXJ5IDIwMDINCg0KDQogICBGb3IgY2xhcmlmaWNhdGlv biwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgSVB2NCBIb3N0IFJlcXVpcmVt ZW50cw0KICAgW0hPU1RSRVFdLCBlc3BlY2lhbGx5IHNlY3Rpb24gMy4zLjUg c2hvdWxkIGJlIGludGVycHJldGVkIHRvIGFwcGx5DQogICBoZXJlIHdoZXJl IGFwcHJvcHJpYXRlOyB0aGUgaW50ZXJwcmV0YXRpb24gb2YgW0lQVjZdIGlz IHRoYXQgZXZlcnkNCiAgIG5vZGUgbXVzdCBiZSBhYmxlIHRvIHByb2Nlc3Mg cm91dGluZyBoZWFkZXJzLCBidXQgbm90IGV2ZXJ5IG5vZGUNCiAgIG5lZWRz IHRvIGhhdmUgdGhhdCBwcm9jZXNzaW5nIGVuYWJsZWQuDQoNCiAgIFNlZSBB cHBlbmRpeCBBIGZvciBhbiBleGFtcGxlIHNldCBvZiBJUHY2IHJlcXVpcmVt ZW50cyBmb3Igcm91dGluZw0KICAgaGVhZGVyIGZvcndhcmRpbmcuDQoNCjIu IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZHJhZnQgYW5k IFtSSEhBU0VDXSBkaXNjdXNzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0K DQogICBbSE9TVFJFUV0gcGVybWl0cyBpbXBsZW1lbnRhdGlvbnMgdG8gcGVy Zm9ybSAibG9jYWwgc291cmNlLXJvdXRpbmciLA0KICAgdGhhdCBpcywgZm9y d2FyZGluZyByb3V0aW5nIGhlYWRlciBvdXQgb24gdGhlIHNhbWUgaW50ZXJm YWNlIGl0IHdhcw0KICAgcmVjZWl2ZWQgZnJvbSwgd2l0aG91dCByZXN0cmlj dGlvbnMgZXZlbiBvbiBob3N0cy4gIFRoaXMgaXMgYQ0KICAgc2VjdXJpdHkg dGhyZWF0LCBhcyBwb2ludGVkIG91dCBpbiBbUkhIQVNFQ10sIGFuZCBpdCBp cyByZWNvbW1lbmRlZA0KICAgdGhhdCBJUHY2IGltcGxlbWVudGF0aW9ucyB3 aWxsIG5vdCBkbyB0aGF0Lg0KDQogICBNb3Jlb3ZlciwgYXMgW1JISEFTRUNd IHBvaW50cyBvdXQsIGZvcndhcmRpbmcgcm91dGluZyBoZWFkZXJzIGluc2lk ZQ0KICAgdGhlIHNhbWUgbm9kZSBoYXMgcmVzaWR1YWwgc2VjdXJpdHkgdGhy ZWF0cyBhcyB3ZWxsOiBjb25zaWRlciBhIGhvc3QNCiAgIHdpdGggdHdvIGlu dGVyZmFjZXMgdGhhdCBiZWxvbmcgdG8gZGlmZmVyZW50IHNlY3VyaXR5IHpv bmVzLiAgVGhlc2UNCiAgIGtpbmQgb2Ygbm9kZXMgYXJlIG9mdGVuICJzZWN1 cml0eSBnYXRld2F5cyIsIHRob3VnaCwgYW5kIGl0IG1heSBiZQ0KICAgZW5v dWdoIHRoYXQgdGhlIGltcGxlbWVudG9ycyBiZSBhd2FyZSBvZiB0aGlzIGlz c3VlLg0KDQozLiBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIEZyYW5jaXMgRHVw b250IGZvciBsb25nIGFuZCBjb2xvdXJmdWwgZGlzY3Vzc2lvbiBvbiB0aGUg UkZDMjQ2MA0KICAgaW50ZXJwcmV0YXRpb24sIFZsYWQgWWFzZXZpY2ggZm9y IHBvaW50aW5nIG91dCBhbiBSRkMyNDYwIGZvcndhcmRpbmcNCiAgIGRlZmlu aXRpb24gYW5kIEVyaWsgTm9yZG1hcmsgZm9yIHJlZmluaW5nIHRoZSBydWxl cy4gIFRoZSBpc3N1ZSB3YXMNCiAgIHJhaXNlZCBwcmltYXJpbHkgZHVlIHRv IE1vYmlsZSBJUHY2IGNvbmNlcm5zLg0KDQo0LiBSZWZlcmVuY2VzDQoNCiAg IFtJUFY2XSAgICAgIERlZXJpbmcsIFMuLCBIaW5kZW4sIFIuLCAiSW50ZXJu ZXQgUHJvdG9jb2wsIFZlcnNpb24gNg0KICAgICAgICAgICAgICAgKElQdjYp IFNwZWNpZmljYXRpb24iLCBSRkMgMjQ2MCwgRGVjZW1iZXIgMTk5OC4NCg0K ICAgW0hPU1RSRVFdICAgQnJhZGVuLCBSLiAoRWRpdG9yKSAiUmVxdWlyZW1l bnRzIGZvciBJbnRlcm5ldCBIb3N0cw0KICAgICAgICAgICAgICAgLS0gQ29t bXVuaWNhdGlvbiBMYXllcnMiLCBSRkMxMTIyLCBPY3RvYmVyIDE5ODkuDQoN CiAgIFtSSEhBU0VDXSAgIFNhdm9sYSwgUC4gIlNlY3VyaXR5IG9mIElQdjYg Um91dGluZyBIZWFkZXIgYW5kDQogICAgICAgICAgICAgICBIb21lIEFkZHJl c3MgT3B0aW9ucyIsIHdvcmstaW4tcHJvZ3Jlc3MsDQogICAgICAgICAgICAg ICBkcmFmdC1zYXZvbGEtaXB2Ni1yaC1oYS1zZWN1cml0eS0wMS50eHQsIE5v dmVtYmVyIDIwMDEuDQoNCg0KDQoNCg0KDQoNCg0KU2F2b2xhICAgICAgICAg ICAgICAgICAgICAgW0V4cGlyZXMgSnVseSAyMDAyXSAgICAgICAgICAgICAg ICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldCBEcmFmdCAgICAgIGRyYWZ0LXNh dm9sYS1pcHY2LXJoLWhvc3RzLTAwLnR4dCAgICAgICBKYW51YXJ5IDIwMDIN Cg0KDQpBdXRob3IncyBBZGRyZXNzDQoNCiAgIFBla2thIFNhdm9sYQ0KICAg Q1NDL0ZVTkVUDQogICBFc3BvbywgRmlubGFuZA0KICAgRU1haWw6IHBzYXZv bGFAZnVuZXQuZmkNCg0KQS4gQW4gZXhhbXBsZSBzZXQgb2YgcnVsZXMgZm9y IElQdjYgUkggZm9yd2FyZGluZyBmb3IgaG9zdHMNCg0KICAgSGVyZSwgYWJi cmV2aWF0aW9uICdSSCBwYWNrZXQnIGlzIHVzZWQgdG8gbWVhbiBhIHBhY2tl dCB3aXRoIHJvdXRpbmcNCiAgIGhlYWRlciB3aGljaCBoYXMgc2VnbWVudHMg bGVmdCA+IDAgYW5kIHdvdWxkIGJlIHByb2Nlc3NlZCBhdCB0aGUgbm9kZQ0K ICAgKHRoYXQgaXMsIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYW4gYWRkcmVz cyBvZiB0aGUgbm9kZSkuDQoNCiAgIEEgaG9zdCBNVVNUIE5PVCBieSBkZWZh dWx0IGZvcndhcmQgUkggcGFja2V0cyBvdXQgb2YgdGhlIG5vZGUuICBUaGlz DQogICBvcHRpb24gTUFZIGJlIGNvbmZpZ3VyYWJsZSwgYnV0IE1VU1QgZGVm YXVsdCB0byBkaXNhYmxlZC4NCg0KICAgQSBob3N0IE1BWSByZXN0cmljdCBm b3J3YXJkaW5nIFJIIHBhY2tldHMgaW4gdGhlIG5vZGUgYXMgd2VsbCwgZS5n Lg0KICAgYnkgZGlzYWJsaW5nIGFsbCByb3V0aW5nIGhlYWRlciBwcm9jZXNz aW5nIGJ5IGRlZmF1bHQuICBbTm90ZTogdGhlDQogICBhdXRob3IgYmVsaWV2 ZXMgdGhpcyBzaG91bGQgYmUgYSBTSE9VTERdDQoNCiAgIEEgaG9zdCBNQVkg cHJvdmlkZSBzb21lIG1lY2hhbmlzbXMgb2YgYWxsb3dpbmcgYWNjZXB0YWJs ZSByb3V0aW5nDQogICBoZWFkZXIgdXNlLCBmb3IgZXhhbXBsZSwgYWxsb3cg Ukggd2hlcmUgdGhlIGFkZHJlc3MtdG8tYmUtY2hhbmdlZCBhbmQNCiAgIHNv dXJjZSBhZGRyZXNzIGFyZSB0aGUgc2FtZSwgb3IgYWxsb3cgZm9yd2FyZGlu ZyBvdXQgb2YgdGhlIHNhbWUNCiAgIGludGVyZmFjZSB0aGUgcGFja2V0IHdh cyByZWNlaXZlZCBmcm9tLg0KDQogICBBIGhvc3Qgd2hpY2ggZm9yd2FyZHMg c291cmNlIHJvdXRlZCBwYWNrZXRzIE1VU1QgYmVoYXZlIHRoZSBzYW1lIHdh eQ0KICAgYXMgYSByb3V0ZXIgZG9pbmcgdGhpcyBlLmcuIGluIHRlcm1zIG9m IHNlbmRpbmcgSUNNUCBlcnJvciBtZXNzYWdlcy4NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNhdm9sYSAgICAg ICAgICAgICAgICAgICAgIFtFeHBpcmVzIEp1bHkgMjAwMl0gICAgICAgICAg ICAgICAgICBbUGFnZSAzXQ0K --1589707168-931612806-1012330324=:29771-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 14:41: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 OAA18813 for ; Tue, 29 Jan 2002 14:41: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 LAA21409; Tue, 29 Jan 2002 11:39:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28950; Tue, 29 Jan 2002 11:38: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 g0TJau2Q009003 for ; Tue, 29 Jan 2002 11:36:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TJau05009002 for mobile-ip-dist; Tue, 29 Jan 2002 11:36: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 g0TJaq2Q008992 for ; Tue, 29 Jan 2002 11:36:53 -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 LAA19300 for ; Tue, 29 Jan 2002 11:37:02 -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 MAA14752 for ; Tue, 29 Jan 2002 12:37:01 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA23826; Tue, 29 Jan 2002 11:37:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0TJaxq20859; Tue, 29 Jan 2002 11:36:59 -0800 X-mProtect: Tue, 29 Jan 2002 11:36:59 -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 smtpdZvMdGT; Tue, 29 Jan 2002 11:36:58 PST Message-ID: <3C56F9DB.A79E2A78@iprg.nokia.com> Date: Tue, 29 Jan 2002 11:36:59 -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: Pekka Savola CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) 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: > Another note: make sure that old RH (for traffic engineering) and new RH > (CoA, HA mapping): that is, new RH must be after old RH in the header > chain. This would break applications where the mobile node is only one intermediate point in the source routing list. In fact, whatever solution you would pick, you have to make it work exactly like source routing in all circumstances. But I don't claim that fact should NECESSARILY indicate staying with the existing routing header. We can obviously have redundant features. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 15:23: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 PAA19764 for ; Tue, 29 Jan 2002 15:23: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 NAA17748; Tue, 29 Jan 2002 13:23: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 MAA03863; Tue, 29 Jan 2002 12:23: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 g0TKLq2Q009248 for ; Tue, 29 Jan 2002 12:21:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TKLpSG009247 for mobile-ip-dist; Tue, 29 Jan 2002 12:21:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TKLm2Q009240 for ; Tue, 29 Jan 2002 12:21:48 -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 MAA01085 for ; Tue, 29 Jan 2002 12:22:03 -0800 (PST) From: Basavaraj.Patil@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17937 for ; Tue, 29 Jan 2002 13:22:03 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TKNiQ13291 for ; Tue, 29 Jan 2002 14:23:44 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 29 Jan 2002 14:22:00 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 29 Jan 2002 14:20:47 -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] LMM requirements - last call ? Date: Tue, 29 Jan 2002 14:20:47 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD5DE@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] LMM requirements - last call ? Thread-Index: AcGo7fraH6g+ONkGQCSYXZBvmgQL6wAFBohg To: X-OriginalArrivalTime: 29 Jan 2002 20:20:47.0937 (UTC) FILETIME=[7021B310:01C1A902] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g0TKLn2Q009241 Sender: owner-mobile-ip@sunroof.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 know this is off-track right now but > > > are we going for last call with the LMM > > > requirements draft ? As far as I remember > > > all comments were addressed by Carl. > > > > > > I don't think this is dependant on any > > > MIPv6 security discussions, is it ? > > > > The LMM I-D does have a normative dependence > > on Mobile IPv6. Compleitng WG last call will not > > necessarily cause this I-D to progress unless we > > get MIPv6 done first. > > => Sure but I assume this is an informational > RFC. You can reference a draft in an informational > RFC then update it later. I'm just > trying to parallelise things a bit. > > Hesham > True. But I would prefer to have the MIPv6 spec settle down, so that any LMM solutions (and requirements) for IPv6 mobility can taken into consideration the base MIPv6 protocol. If the momentum we have now on the MIPv6 spec is continued, we should be done with this by Minneapolis. At which time we can start work on all the other issues related to IP mobility. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 15:26: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 PAA19831 for ; Tue, 29 Jan 2002 15:26: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 NAA19663; Tue, 29 Jan 2002 13:26: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 MAA05072; Tue, 29 Jan 2002 12:26: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 g0TKPE2Q009384 for ; Tue, 29 Jan 2002 12:25:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TKPE92009383 for mobile-ip-dist; Tue, 29 Jan 2002 12:25:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TKPA2Q009376 for ; Tue, 29 Jan 2002 12:25:11 -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 MAA02921 for ; Tue, 29 Jan 2002 12:25:21 -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 NAA27743 for ; Tue, 29 Jan 2002 13:25:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA27589; Tue, 29 Jan 2002 12:25:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0TKPJ926645; Tue, 29 Jan 2002 12:25:19 -0800 X-mProtect: Tue, 29 Jan 2002 12:25:19 -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 smtpdyCsx1X; Tue, 29 Jan 2002 12:25:17 PST Message-ID: <3C57052E.8DAF9C28@iprg.nokia.com> Date: Tue, 29 Jan 2002 12:25:18 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) References: <200201291748.g0THmng34527@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Francis, You wrote: > => IMHO the "end node" property is far more important (in the down side) > than the history property (where RH is better than DO because RH type 0 > was designed to be reversible). Routing headers should not be reversed unless there is a good reason to do so. But I think you would also agree with this; I just wanted to make it clear. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 15:42:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20362 for ; Tue, 29 Jan 2002 15:42:23 -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 NAA00104; Tue, 29 Jan 2002 13:42:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14144; Tue, 29 Jan 2002 12:42: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 g0TKeu2Q009576 for ; Tue, 29 Jan 2002 12:40:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TKeuD3009575 for mobile-ip-dist; Tue, 29 Jan 2002 12:40:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TKep2Q009568 for ; Tue, 29 Jan 2002 12:40:53 -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 MAA07709 for ; Tue, 29 Jan 2002 12:41:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29187 for ; Tue, 29 Jan 2002 13:41:06 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TKf5830884 for ; Tue, 29 Jan 2002 22:41:05 +0200 Date: Tue, 29 Jan 2002 22:41:04 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) In-Reply-To: <3C56F9DB.A79E2A78@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 29 Jan 2002, Charles E. Perkins wrote: > > Another note: make sure that old RH (for traffic engineering) and new RH > > (CoA, HA mapping): that is, new RH must be after old RH in the header > > chain. > > This would break applications where the mobile node is only one > intermediate point in the source routing list. You mean applications where MN forwards the packet out of the node, or something else? > In fact, whatever solution you would pick, you have to make > it work exactly like source routing in all circumstances. > > But I don't claim that fact should NECESSARILY indicate staying > with the existing routing header. We can obviously have redundant > features. In case I wasn't being explicit enough, let me clarify. When sending at the source: src=some_node dst=intermediate_te_router classic routing header=MN CoA, segments left=1 new routing header=MN Home Address, segments left=1 [payload] (Note: we would need to define that not both are processed on the same node) after being processed at intermediate_te_router, the packet would look like: src=some_node dst=MN CoA classic routing header=intermediate_te_router, segments left=0 new routing header=MN Home Address, segments left=1 [payload] when MN receives the packet, it skips over the classic routing header (because segments left == 0), and processes the second one normally. Did I misunderstand what you meant? -- 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 Jan 29 16:34:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21619 for ; Tue, 29 Jan 2002 16:34:47 -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 OAA03151; Tue, 29 Jan 2002 14:34:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15532; Tue, 29 Jan 2002 13: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 g0TLWh2Q009691 for ; Tue, 29 Jan 2002 13:32:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TLWhv0009690 for mobile-ip-dist; Tue, 29 Jan 2002 13: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TLWe2Q009683 for ; Tue, 29 Jan 2002 13:32:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24926 for ; Tue, 29 Jan 2002 13:32:56 -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 OAA02183 for ; Tue, 29 Jan 2002 14:32:55 -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 NAA02171; Tue, 29 Jan 2002 13:32:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0TLWtv23907; Tue, 29 Jan 2002 13:32:55 -0800 X-mProtect: Tue, 29 Jan 2002 13:32:55 -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 smtpdZsAZJy; Tue, 29 Jan 2002 13:32:53 PST Message-ID: <3C571505.9590D8C0@iprg.nokia.com> Date: Tue, 29 Jan 2002 13:32:53 -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: Pekka Savola CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) 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 Pekka Savola wrote: >>> Another note: make sure that old RH (for traffic engineering) and new RH >>> (CoA, HA mapping): that is, new RH must be after old RH in the header >>> chain. >> >> This would break applications where the mobile node is only one >> intermediate point in the source routing list. > > You mean applications where MN forwards the packet out of the node, or > something else? I meant the former -- but anyway, where the mobile node is supposed to forward the packet to another subsequent routing point. Nevertheless, the point remains the same if the mobile node is itself the last of multiple other routing points in a list, and the care-of address needs to be injected into the list. > In case I wasn't being explicit enough, let me clarify. > > When sending at the source: > > src=some_node > dst=intermediate_te_router > classic routing header=MN CoA, segments left=1 > new routing header=MN Home Address, segments left=1 > [payload] Again, I reckon this would work. > (Note: we would need to define that not both are processed on the same > node) This is equally necessary or unnecessary as making the same restriction with "classic" routing header. > after being processed at intermediate_te_router, the packet would look > like: > > src=some_node > dst=MN CoA > classic routing header=intermediate_te_router, segments left=0 > new routing header=MN Home Address, segments left=1 > [payload] Right. > when MN receives the packet, it skips over the classic routing header > (because segments left == 0), and processes the second one normally. Here, "normally" means according to exactly the same semantics as routing header type 0? > Did I misunderstand what you meant? I can't tell about that, but it seems to me that the existing routing header can do everything you want, already. But that shouldn't be taken to mean that I am opposed to having a new routing header. Indeed, if that's the magic wand that will mysteriously make the aforementioned firewall vendors suddenly feel better, then it must be pretty good, and so it's just fine with me. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 16:40: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 QAA21689 for ; Tue, 29 Jan 2002 16:40:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06558; Tue, 29 Jan 2002 14:40: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 NAA19186; Tue, 29 Jan 2002 13:40: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 g0TLd12Q009821 for ; Tue, 29 Jan 2002 13:39:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TLd19I009820 for mobile-ip-dist; Tue, 29 Jan 2002 13:39:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TLcw2Q009813 for ; Tue, 29 Jan 2002 13:38: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 NAA24656 for ; Tue, 29 Jan 2002 13:39:14 -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 OAA17754 for ; Tue, 29 Jan 2002 14:39:13 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TLd4N31270; Tue, 29 Jan 2002 23:39:04 +0200 Date: Tue, 29 Jan 2002 23:39:04 +0200 (EET) From: Pekka Savola To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) In-Reply-To: <3C571505.9590D8C0@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 29 Jan 2002, Charles E. Perkins wrote: > > (Note: we would need to define that not both are processed on the same > > node) > > This is equally necessary or unnecessary as making the same restriction > with "classic" routing header. True.. I think it's currently unspecified (but unused).. > > when MN receives the packet, it skips over the classic routing header > > (because segments left == 0), and processes the second one normally. > > Here, "normally" means according to exactly the same semantics > as routing header type 0? No (IMO) -- there would be little point in defining new type if it was solely like this. Additional requirements could be placed, and should be placed. (below) > > Did I misunderstand what you meant? > > I can't tell about that, but it seems to me that the existing routing > header can do everything you want, already. But that shouldn't be > taken to mean that I am opposed to having a new routing header. Indeed, > if that's the magic wand that will mysteriously make the aforementioned > firewall vendors suddenly feel better, then it must be pretty good, and > so it's just fine with me. The significant difference here would be that we could define that with routing header type=2, the final destination MUST be Home Address or else the packet is discarded (or dealt with somehow). Additional requirements could also be placed, those that could not be added for type=0 (e.g. segments left must be 1). This makes the behaviour much more controlled, and easier for the administrators to handle. -- 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 Jan 29 17:00: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 RAA22168 for ; Tue, 29 Jan 2002 17:00: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 NAA19935; Tue, 29 Jan 2002 13:59: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 NAA00313; Tue, 29 Jan 2002 13:58: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 g0TLvd2Q009999 for ; Tue, 29 Jan 2002 13:57:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TLvdti009998 for mobile-ip-dist; Tue, 29 Jan 2002 13:57: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TLvY2Q009991 for ; Tue, 29 Jan 2002 13:57:35 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TLviF15985; Tue, 29 Jan 2002 22:57:45 +0100 (MET) Date: Tue, 29 Jan 2002 22:54:07 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-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 understand that this discussion is a bit out of scope, yet it would be > beneficial if Mobile Nodes and Mobile Routers could as much as possible > behave consistently. I agree that mobile Router may want to hide the > mobility to Static Nodes. But the point here seems more that a Mobile Router > may attach to a Mobile Network of another MR in a nested configuration. This > recursively builds a graph of Mobile Routers. A solution which finally > builds allows the CN/HA to send a RH with all the VIA MRs of the nested > networks would be best from the MR standpoint... Yes, I think this is MONET material. And the issue whether and how stationary hosts "riding" in a mobile network are kept unaware of the movement of the monet while mobile nodes attached in the same place can be made aware of it seems challenging - but for MONET to figure out. But your point about nesting might be worth-while thinking about. I don't think routing headers are ideal for nesting - the receiving host would end up with a packet that contains N routing header with each of them having segments_left=0. It would seem cleaner if the (nested) mobile routers could in fact remove this information - which would argue for something that looks more like IPV6_NO_SRC tunneling. But I have a hard time understanding how we can take arguments like this into account given that we don't yet know much about the assumptions and requirements for the monet set of problems. Can a credible argument be made that one of the ways to carry the address is more flexible i.e. might be more malleable once we know more about monets? Or is there some other way we can take the monet factor into account? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 17:02:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22307 for ; Tue, 29 Jan 2002 17:02: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 PAA21924; Tue, 29 Jan 2002 15:02:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02746; Tue, 29 Jan 2002 14:02: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 g0TM1G2Q010070 for ; Tue, 29 Jan 2002 14:01:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TM1Gof010069 for mobile-ip-dist; Tue, 29 Jan 2002 14:01: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TM1C2Q010062 for ; Tue, 29 Jan 2002 14:01:13 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TM1HF16322; Tue, 29 Jan 2002 23:01:19 +0100 (MET) Date: Tue, 29 Jan 2002 22:57:40 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: charliep@iprg.nokia.com Cc: Pekka Savola , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C56F9DB.A79E2A78@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, > This would break applications where the mobile node is only one > intermediate point in the source routing list. Do you have examples of such applications or such use of source routing? > In fact, whatever solution you would pick, you have to make > it work exactly like source routing in all circumstances. That statement must be based on some unstated assumptions about the applications you refer to above. Erik > But I don't claim that fact should NECESSARILY indicate staying > with the existing routing header. We can obviously have redundant > features. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 17:06:51 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22434 for ; Tue, 29 Jan 2002 17:06:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16444; Tue, 29 Jan 2002 13:51:27 -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 NAA25908; Tue, 29 Jan 2002 13:51: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 g0TLo02Q009923 for ; Tue, 29 Jan 2002 13:50:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TLo0N8009922 for mobile-ip-dist; Tue, 29 Jan 2002 13:50:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TLnu2Q009915 for ; Tue, 29 Jan 2002 13:49:57 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25347 for ; Tue, 29 Jan 2002 13:50:12 -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 NAA24248 for ; Tue, 29 Jan 2002 13:50:12 -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 NAA03156; Tue, 29 Jan 2002 13:50:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0TLoBX17172; Tue, 29 Jan 2002 13:50:11 -0800 X-mProtect: Tue, 29 Jan 2002 13:50:11 -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 smtpd3Q5WQJ; Tue, 29 Jan 2002 13:50:09 PST Message-ID: <3C571911.3CE06DAA@iprg.nokia.com> Date: Tue, 29 Jan 2002 13:50:09 -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: Pekka Savola CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) 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: > The significant difference here would be that we could define that with > routing header type=2, the final destination MUST be Home Address or else > the packet is discarded (or dealt with somehow). Additional requirements > could also be placed, those that could not be added for type=0 (e.g. > segments left must be 1). This makes the behaviour much more controlled, > and easier for the administrators to handle. But then we have to make another Routing Header which does exactly the same thing, but without this restriction, when the mobile node is itself an intermediate node, like a mobile router. Furthermore, I don't see why a firewall vendor would trust a device to do the right thing just because it's another routing header type. Already, IPv6 nodes are "supposed" to do the right thing with routing headers, and not blindly forward them. If we make new laws, they can be equally well mistrusted by firewall vendors. If we enforce the existing laws, they can be equally well trusted by firewall vendors. I think you're trying to compensate for bugs, and the bug space is so huge that we would never get done, and never have a consistent set of design guidelines. And yet I am in favor of any not totally broken solution that will get us done, even if it is only because of having been endowed with that certain magic that makes firewall vendors happy. Not that I would be able to make predictions about how to do that, so I will have to trust the convictions of others. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 17:13: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 RAA22547 for ; Tue, 29 Jan 2002 17:13: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 PAA28416; Tue, 29 Jan 2002 15:12:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08666; Tue, 29 Jan 2002 14:12: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 g0TMBk2Q010178 for ; Tue, 29 Jan 2002 14:11:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TMBkbx010177 for mobile-ip-dist; Tue, 29 Jan 2002 14:11:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0TMBf2Q010170 for ; Tue, 29 Jan 2002 14:11:42 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TMBjF16957; Tue, 29 Jan 2002 23:11:46 +0100 (MET) Date: Tue, 29 Jan 2002 23:08:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: charliep@iprg.nokia.com Cc: Pekka Savola , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C571505.9590D8C0@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, > > You mean applications where MN forwards the packet out of the node, or > > something else? > > I meant the former -- but anyway, where the mobile node is supposed to > forward the packet to another subsequent routing point. Nevertheless, > the point remains the same if the mobile node is itself the last of > multiple other routing points in a list, and the care-of address needs > to be injected into the list. I'm having a hard time understanding a specific use of this type of routing header. One use of routing header that has been discussed is for some level of policy control. For example A is sending packets to B and A has three ISPs to choose between. If each ISP has an anycast address for their border routers then A can source route via that anycast address to reach B. Combining this with mobile-ip route optimization might make sense when B is a MN moving out on the Internet. But B would not forward the packets onward. But when the MN comes to visit A's site the optimized routing isn't very optimal any more - the routing header makes the packets leave A's site since they are source routed through one of A's ISPs. Should A be a MN in the above case things make even less sense - once A has travelled to a different part of the Internet it doesn't make sense to source route packets back through one of A's ISPs. So it seems like in general the combination of the more explicit routing possible using routing headers with MIP route optization is a bit at odds. And in any case it doesn't require a MN to be in the middle of a source route. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 18:36: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 SAA24461 for ; Tue, 29 Jan 2002 18:36:14 -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 QAA21280; Tue, 29 Jan 2002 16:36:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01084; Tue, 29 Jan 2002 15:36: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 g0TNYk2Q010413 for ; Tue, 29 Jan 2002 15:34:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0TNYkNI010412 for mobile-ip-dist; Tue, 29 Jan 2002 15:34: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 g0TNYg2Q010405 for ; Tue, 29 Jan 2002 15:34:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22902; Tue, 29 Jan 2002 15:34:56 -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 QAA09656; Tue, 29 Jan 2002 16:34:56 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA11268; Tue, 29 Jan 2002 15:34:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0TNYsx27657; Tue, 29 Jan 2002 15:34:54 -0800 X-mProtect: Tue, 29 Jan 2002 15:34:54 -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 smtpdLesTSn; Tue, 29 Jan 2002 15:34:52 PST Message-ID: <3C573140.19215C74@iprg.nokia.com> Date: Tue, 29 Jan 2002 15:33:20 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) 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: > > > You mean applications where MN forwards the packet out of the node, or > > > something else? > > > > I meant the former -- but anyway, where the mobile node is supposed to > > forward the packet to another subsequent routing point. Nevertheless, > > the point remains the same if the mobile node is itself the last of > > multiple other routing points in a list, and the care-of address needs > > to be injected into the list. > > I'm having a hard time understanding a specific use of this type of > routing header. I guess you mean "any specific use". However, I didn't think we were supposed to be working on particular specific uses. I pretty much understand what function the routing header is supposed to perform, and I think that it is valid (or even highly recommended) to ensure that those functions remain workable even when the intermediate routing points are themselves mobile. > One use of routing header that has been discussed is for some level of > policy control. If we define policy control sufficiently generally, I think that all uses would be for some level of policy control. > For example A is sending packets to B and A has three ISPs to choose between. > If each ISP has an anycast address for their border routers then A can > source route via that anycast address to reach B. True, and I expect you are NOT meaning to imply that only anycast addresses should be present in a Routing Header. > Combining this with mobile-ip route optimization might make sense > when B is a MN moving out on the Internet. But B would not forward > the packets onward. > But when the MN comes to visit A's site the optimized routing isn't very > optimal any more - the routing header makes the packets leave A's site since > they are source routed through one of A's ISPs. Identifying the correct algorithms for route optimization in the presence of multi-hop Routing Headers inserted for _other_ policy reasons is so far beyond the current state of discussion, that I can't imagine it's the right arena for making progress with the current discussion. > Should A be a MN in the above case things make even less sense - once A > has travelled to a different part of the Internet it doesn't make sense > to source route packets back through one of A's ISPs. It could make sense for a lot of reasons, and nobody can know all of them. Maybe there is some bizarre packet monitoring function that depends on some special feature we don't know about. But I didn't think the task was to outline all possible uses of routing headers! That would take a long time. I thought our task was to solve whatever problems had been identified for use of the existing routing header. Neither making another routing header that does exactly the same thing, nor aborting future use of the existing routing header, seems to me to be good engineering practice. Nevertheless, I'm totally happy to take whatever it is that pleases the mystical firewall gods. Or whatever other powers that be relevant in the pantheon I don't understand. > So it seems like in general the combination of the more explicit > routing possible using routing headers with MIP route optization is > a bit at odds. > And in any case it doesn't require a MN to be in the middle of a source route. Nobody requires this. I only suggested that we not disable it. And I also suggest that mobile nodes are likely to turn up in the most unusual places, well within the lifetime of Mobile IPv6, unless we intentionally make the protocol short-sighted. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 19:02: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 TAA25018 for ; Tue, 29 Jan 2002 19:02:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA11021; Tue, 29 Jan 2002 16:02:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09666; Tue, 29 Jan 2002 16:02: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 g0U0182Q010584 for ; Tue, 29 Jan 2002 16:01:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0U017sf010583 for mobile-ip-dist; Tue, 29 Jan 2002 16:01: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 g0U0132Q010576 for ; Tue, 29 Jan 2002 16:01:04 -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 QAA12153 for ; Tue, 29 Jan 2002 16:01:19 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25852 for ; Tue, 29 Jan 2002 17:01:18 -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 g0U01Ie04165 for ; Tue, 29 Jan 2002 16:01:18 -0800 (PST) Message-ID: <007b01c1a921$7d15a530$686015ac@docomocarl> From: "Carl Williams" To: References: <4DA6EA82906FD511BE2F00508BCF053802C6A976@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] LMM requirements - last call ? Date: Tue, 29 Jan 2002 16:03: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.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 Hi Hesham, I made a request to the co-chairs that we have last-call in Utah. I was told by Phil that he needs to talk with Basavaraj. From my work on LMM requirements a few of us have prepared a problem statement draft - something I feel that we need to put everyone on the same page. It is will be called " Micro-mobility problem statement for Mobile IPv6". We'll submit it in a few weeks. Carl ----- Original Message ----- From: "Hesham Soliman (ERA)" To: Sent: Tuesday, January 29, 2002 7:58 AM Subject: [mobile-ip] LMM requirements - last call ? > Hi, > > I know this is off-track right now but > are we going for last call with the LMM > requirements draft ? As far as I remember > all comments were addressed by Carl. > > I don't think this is dependant on any > MIPv6 security discussions, is it ? > > Cheers, > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 19:03: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 TAA25033 for ; Tue, 29 Jan 2002 19:03:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAB08345; Tue, 29 Jan 2002 17:02: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 QAA09819; Tue, 29 Jan 2002 16:02:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0U01i2Q010594 for ; Tue, 29 Jan 2002 16:01:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0U01i22010593 for mobile-ip-dist; Tue, 29 Jan 2002 16:01:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0U01d2Q010586 for ; Tue, 29 Jan 2002 16:01:40 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0U01iF27019; Wed, 30 Jan 2002 01:01:45 +0100 (MET) Date: Wed, 30 Jan 2002 00:58:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: Charlie Perkins Cc: Erik Nordmark , Pekka Savola , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C573140.19215C74@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 guess you mean "any specific use". However, I didn't think we were > supposed to be working on particular specific uses. I pretty much > understand what function the routing header is supposed to perform, > and I think that it is valid (or even highly recommended) to ensure that > those functions remain workable even when the intermediate routing > points are themselves mobile. Charlie, You are arguing that there needs to be the capability to construct something that has - zero or more source routing hops, - followed by a CoA hop - followed by one or more source routing hops - and then reaching the HoA My question is merely trying to understand what problem this is solving. All I need is one credible example of real usage. If you have an actual example with source routing through routers that are themselves mobile that would satisfy my curiosity. > > One use of routing header that has been discussed is for some level of > > policy control. > > If we define policy control sufficiently generally, I think that all > uses would be for some level of policy control. > > > For example A is sending packets to B and A has three ISPs to choose between. > > If each ISP has an anycast address for their border routers then A can > > source route via that anycast address to reach B. > > True, and I expect you are NOT meaning to imply that only anycast > addresses should be present in a Routing Header. "One use .." and "For example ..." presumably make this clear already. > Identifying the correct algorithms for route optimization in the presence > of multi-hop Routing Headers inserted for _other_ policy reasons is so > far beyond the current state of discussion, that I can't imagine it's the > right arena for making progress with the current discussion. Correct. But since you didn't provide concrete examples I thought I'd try to be imaginative. But use of my imagination didn't result in coming up with a useful case where source routing and mobile must be combined in the way you claim is a requirement. > Nobody requires this. I only suggested that we not disable it. And I > also suggest that mobile nodes are likely to turn up in the most unusual > places, well within the lifetime of Mobile IPv6, unless we intentionally > make the protocol short-sighted. In a previous email you said: > This would break applications where the mobile node is only one > intermediate point in the source routing list. > > In fact, whatever solution you would pick, you have to make > it work exactly like source routing in all circumstances. That sure reads like you are stating a requirement. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Jan 29 19:22: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 TAA25385 for ; Tue, 29 Jan 2002 19:22:22 -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 RAA19464; Tue, 29 Jan 2002 17:22: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 QAA15562; Tue, 29 Jan 2002 16:22: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 g0U0L62Q010716 for ; Tue, 29 Jan 2002 16:21:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0U0L69Z010715 for mobile-ip-dist; Tue, 29 Jan 2002 16:21: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 g0U0L12Q010708 for ; Tue, 29 Jan 2002 16:21:02 -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 QAA02340 for ; Tue, 29 Jan 2002 16:21:17 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16016 for ; Tue, 29 Jan 2002 17:21:15 -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 QAA14468; Tue, 29 Jan 2002 16:21:14 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0U0LDr30746; Tue, 29 Jan 2002 16:21:13 -0800 X-mProtect: Tue, 29 Jan 2002 16:21:13 -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 smtpdzWBQvb; Tue, 29 Jan 2002 16:21:11 PST Message-ID: <3C573C20.6D8E76C3@iprg.nokia.com> Date: Tue, 29 Jan 2002 16:19:44 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) 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: > > I guess you mean "any specific use". However, I didn't think we were > > supposed to be working on particular specific uses. I pretty much > > understand what function the routing header is supposed to perform, > > and I think that it is valid (or even highly recommended) to ensure that > > those functions remain workable even when the intermediate routing > > points are themselves mobile. > > Charlie, > > You are arguing that there needs to be the capability to construct something > that has > - zero or more source routing hops, > - followed by a CoA hop > - followed by one or more source routing hops > - and then reaching the HoA No, I didn't say that. I would suggest the following: - zero or more source routing hops, - followed by a CoA hop - immediately followed by the HoA - followed by zero or more source routing hops I'm happy to stipulate that Mobile IPv6 policy requires that the home address MUST immediately follow the care-of address. In fact, I think such a statement is already in there. > All I need is one credible example of real usage. Do you still require it for my actual formulation? Anyway, I'm not trying to make requirements. I've already stated multiple times that I'm happy to do whatever y'all say for retyping the routing header. I think the reasons do not bear up under serious discussion, but that doesn't mean I would oppose the action anyway. > > True, and I expect you are NOT meaning to imply that only anycast > > addresses should be present in a Routing Header. > > "One use .." and "For example ..." presumably make this clear already. Perhaps that formed the underlying basis of my expectation. My reason for overtly stating it was just to make sure that I understood what I thought was your obvious intention. > > Nobody requires this. I only suggested that we not disable it. And I > > also suggest that mobile nodes are likely to turn up in the most unusual > > places, well within the lifetime of Mobile IPv6, unless we intentionally > > make the protocol short-sighted. > > In a previous email you said: > > This would break applications where the mobile node is only one > > intermediate point in the source routing list. > > > > In fact, whatever solution you would pick, you have to make > > it work exactly like source routing in all circumstances. > > That sure reads like you are stating a requirement. O.K. It's not a requirement except if we wanted to enable what I thought was the well-understood meaning of source routing. Or perhaps to be more explicit: a - b - c - ... - i - k - ... - x - y - z Suppose that is the source route, and k is mobile. Suppose k moves to care-of address 'j'. Then the new source route should be: a - b - c - ... - i - j - k - ... - x - y - z That seems so obvious, that I didn't think there was a need for some specific application. The further points that I also thought were obvious are: 1. The first source route was built using signaling that we don't know about, but that we can surmise provided sufficient assurance that the routing operations were authorized, and 2. The recipient of the revised source route, since it owns IP address 'j', will assuredly follow the policy by which it authorized the other endpoint to amend the source route -- namely, that 'j' MUST be followed by 'k' (here, the node's home address). That's the Mobile IPv6 policy for source routing, and it's a mobile node that will enforce it. But none of this discussion should be interpreted as opposition to a new routing header type. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 03:49: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 DAA12643 for ; Wed, 30 Jan 2002 03:49:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08007; Wed, 30 Jan 2002 01:49:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29289; Wed, 30 Jan 2002 00:49: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 g0U8lL2Q011404 for ; Wed, 30 Jan 2002 00:47:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0U8lL7w011403 for mobile-ip-dist; Wed, 30 Jan 2002 00:47: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 g0U8lG2Q011396 for ; Wed, 30 Jan 2002 00:47:18 -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 AAA29014 for ; Wed, 30 Jan 2002 00:47:34 -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 BAA07170 for ; Wed, 30 Jan 2002 01:47:33 -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 g0U8lV325580 for ; Wed, 30 Jan 2002 09:47:32 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA17701 for ; Wed, 30 Jan 2002 09:47:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0U8lVg37079 for ; Wed, 30 Jan 2002 09:47:31 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201300847.g0U8lVg37079@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 28 Jan 2002 18:45:09 +0100. Date: Wed, 30 Jan 2002 09:47:31 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-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 one question : are there others cases (eg. protocols) where RH are used ? => two examples: - (theory) the selection of an intermediate ISP, i.e. to go from the West coast to the East coast you choose to go through Chicago, Saint-Louis, Memphis or New Orleans by a RH with the subnet anycast address of the selected ISP. - (practice) traceroute6 -g (there are two (not three :-) standard applications with IPv6 RH support: traceroute6 and telnet (in order to understand the syntax for telnet, you have to read (and sometimes to fix) the source. Regards Francis.Dupont@enst-bretagne.fr PS: the first usage is potentially critical (BTW is this kind of features mandatory in the USA since ISPs are regulated as telecom operators?) From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 05:02: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 FAA13608 for ; Wed, 30 Jan 2002 05:02: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 CAA11452; Wed, 30 Jan 2002 02:02:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12615; Wed, 30 Jan 2002 02:02:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UA182Q011636 for ; Wed, 30 Jan 2002 02:01:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UA18Pw011635 for mobile-ip-dist; Wed, 30 Jan 2002 02:01: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 g0UA152Q011628 for ; Wed, 30 Jan 2002 02:01:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11273 for ; Wed, 30 Jan 2002 02:01:24 -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 CAA22965 for ; Wed, 30 Jan 2002 02:01: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 g0UA1L302627 for ; Wed, 30 Jan 2002 11:01: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 LAA19136 for ; Wed, 30 Jan 2002 11:01:21 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g0UA1Lg37756 for ; Wed, 30 Jan 2002 11:01:21 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201301001.g0UA1Lg37756@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 28 Jan 2002 10:21:01 PST. <3C55968D.3180DEC@iprg.nokia.com> Date: Wed, 30 Jan 2002 11:01:21 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-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 thought it was pretty obvious. the new destination option has to be before the fragment header and after the routing header. it makes no sense having it after the fragment header (if ever fragmentation is done for a packet). => I agree but this means there is no difference from the IPsec point of view between a new DO and a new RH type (i.e. this withdraws a possible argument in favour of a new DO). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 05:04: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 FAA13648 for ; Wed, 30 Jan 2002 05:04: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 DAA14075; Wed, 30 Jan 2002 03:04: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 CAA13196; Wed, 30 Jan 2002 02:04: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 g0UA3e2Q011730 for ; Wed, 30 Jan 2002 02:03:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UA3evt011729 for mobile-ip-dist; Wed, 30 Jan 2002 02:03: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 g0UA3b2Q011722 for ; Wed, 30 Jan 2002 02:03: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 CAA13035 for ; Wed, 30 Jan 2002 02:03:56 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02723 for ; Wed, 30 Jan 2002 03:03:56 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id DAA02204 for ; Wed, 30 Jan 2002 03:03:55 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id DAA18516 for ; Wed, 30 Jan 2002 03:03:55 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 30 Jan 2002 04:03:44 -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 A92892EC85 for ; Wed, 30 Jan 2002 10:59:38 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] A threat RR doesn't solve and that doesn't seem t o exist in IPv4 References: <4DA6EA82906FD511BE2F00508BCF053802C6A973@Esealnt861.al.sw.ericsson.se> From: Alexandru Petrescu Date: 29 Jan 2002 22:04:15 +0100 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6A973@Esealnt861.al.sw.ericsson.se> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 14 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: "Hesham Soliman (ERA)" writes: > or by core network routing according to keys (in addresses). > > => Routing in the core network is never done > on the interface id anyway. Thanks Hesham for bringing this up. I'm wondering if the 64bit boundary for Interface ID is fixed. It seems to me that 000-prefixed addresses are about to be reserved exactly in order to allow prefix lengths longer than 64 (draft-ietf-ipngwg-addr-arch). I might be wrong, though. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 05:25: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 FAA13999 for ; Wed, 30 Jan 2002 05:25:14 -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 DAA23398; Wed, 30 Jan 2002 03:23: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 CAA16989; Wed, 30 Jan 2002 02: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 g0UAMd2Q011906 for ; Wed, 30 Jan 2002 02:22:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UAMddA011905 for mobile-ip-dist; Wed, 30 Jan 2002 02:22: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UAMZ2Q011898 for ; Wed, 30 Jan 2002 02:22:36 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0UAMkF13532; Wed, 30 Jan 2002 11:22:46 +0100 (MET) Date: Wed, 30 Jan 2002 11:19:10 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: Charlie Perkins Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C573C20.6D8E76C3@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: > O.K. It's not a requirement except if we wanted to enable what > I thought was the well-understood meaning of source routing. Yes, but we are talking about the meaning of source routing combined with mobile-ip, and I don't think there is a well-understood idea of what that could be used for hence it isn't clear whether it is needed or not. > Or perhaps to be more explicit: > > a - b - c - ... - i - k - ... - x - y - z > > Suppose that is the source route, and k is mobile. Suppose k > moves to care-of address 'j'. Then the new source route should be: > > a - b - c - ... - i - j - k - ... - x - y - z > > That seems so obvious, that I didn't think there was a need for > some specific application. Let me try to restate the above. 1. Assume that the delivery of packets on the CoA to HoA "hop" should work like source routing. 2. Show that the delivery of packets on this "hop" must work like source routing. I agree it's obvious because it is a circular argument. The above example shows a node forwarding packets with an explicit route (what many would consider a router) where the explicit route is constructed using a routing header. Then the node in the middle of the explicit route moves. My question is what would this be used for? Even if explicit routing is used, the above doesn't make any sense to me - why would a router in an explicit route move (using mobile-ip) and expect the explicit route to follow its movement? It sounds completely esoteric doing something like that. So a non-circular argument is needed. > The further points that I also thought > were obvious are: > 1. The first source route was built using signaling that we don't > know about, but that we can surmise provided sufficient assurance > that the routing operations were authorized, and > > 2. The recipient of the revised source route, since it owns IP address 'j', > will assuredly follow the policy by which it authorized the other > endpoint to amend the source route -- namely, that 'j' MUST be > followed by 'k' (here, the node's home address). That's the Mobile IPv6 > policy for source routing, and it's a mobile node that will enforce it. Yes, but this follows the assumption that the CoA to HoA "hop" is constructed using source routing and why that's needed/useful/good is the piece I'm trying to understand. > But none of this discussion should be interpreted as opposition to > a new routing header type. Understood. What is your opinion of the other different ways of "encoding" things ? (new destination option, IPV6_NO_SRC tunneling, new extension header, ...) Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 05:39: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 FAA14249 for ; Wed, 30 Jan 2002 05:39:55 -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 DAA00956; Wed, 30 Jan 2002 03:39: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 CAA19608; Wed, 30 Jan 2002 02:39: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 g0UAcX2Q012019 for ; Wed, 30 Jan 2002 02:38:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UAcXeZ012018 for mobile-ip-dist; Wed, 30 Jan 2002 02:38: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UAcR2Q012011 for ; Wed, 30 Jan 2002 02:38:29 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0UAchF14940; Wed, 30 Jan 2002 11:38:43 +0100 (MET) Date: Wed, 30 Jan 2002 11:35:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routes beyond /64 (Was: A threat RR doesn't solve ...) To: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > "Hesham Soliman (ERA)" writes: > > or by core network routing according to keys (in addresses). > > > > => Routing in the core network is never done > > on the interface id anyway. > > Thanks Hesham for bringing this up. > > I'm wondering if the 64bit boundary for Interface ID is fixed. It > seems to me that 000-prefixed addresses are about to be reserved > exactly in order to allow prefix lengths longer than 64 > (draft-ietf-ipngwg-addr-arch). I might be wrong, though. I think practical use of address in 0::/8 (such as the ipv4-mapped, ipv4-compatible, ipv4-translatable, loopback, unspecified) are not likely to cause routes to be advertised in the network for longer than a /96 (and that would be for the ipv4-mapped prefix when using a SIIT translator). So implementors *could* get away with /64 in many places - but DOOOOONT!!! While today /64 is used to do stateless address autoconfiguration it would be short-sighted to assume that this will always be the case. Twenty or fourty years from now we might need something different. Thus IMHO a prudent implementation would limit the places where the /64 boundary is known to a minimum. The best would be to only have this be known by the device driver for IP-over-foo. For instance, an Ethernet device driver would need to know that it should create a 64 bit Interface ID from the MAC address. Then it could pass this up to whatever entity implements RFC 2462 but that entity only needs to verify that the prefixes advertised by the routers plus the interface ID makes a total of 128 bits. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 05:52:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14346 for ; Wed, 30 Jan 2002 05:52:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03264; Wed, 30 Jan 2002 00:26: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 XAA22906; Tue, 29 Jan 2002 23:25: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 g0U7Ok2Q011249 for ; Tue, 29 Jan 2002 23:24:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0U7Ok5u011248 for mobile-ip-dist; Tue, 29 Jan 2002 23:24: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 g0U7Og2Q011241 for ; Tue, 29 Jan 2002 23:24:43 -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 XAA22318 for ; Tue, 29 Jan 2002 23:24:57 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA14303 for ; Wed, 30 Jan 2002 00:24:54 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0U7N4v03278; Wed, 30 Jan 2002 09:23:04 +0200 Date: Wed, 30 Jan 2002 09:23:03 +0200 (EET) From: Pekka Savola To: mobile-ip@sunroof.eng.sun.com cc: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) In-Reply-To: <3C573C20.6D8E76C3@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 29 Jan 2002, Charlie Perkins wrote: > No, I didn't say that. I would suggest the following: > - zero or more source routing hops, > - followed by a CoA hop > - immediately followed by the HoA > - followed by zero or more source routing hops In the case that finally there are more than zero source routing hops, "MN" is a router, and for routers, different policies might apply. Note that in this kind of scenario, the sender which is creating the packet with extra hops after HoA must know the type of destination topology .. and could very well use the "normal" routing header too. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 05:52: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 FAA14358 for ; Wed, 30 Jan 2002 05:52:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26213; Wed, 30 Jan 2002 02:52:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21844; Wed, 30 Jan 2002 02:52: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 g0UApB2Q012089 for ; Wed, 30 Jan 2002 02:51:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UApBLD012088 for mobile-ip-dist; Wed, 30 Jan 2002 02:51:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UAp72Q012081 for ; Wed, 30 Jan 2002 02:51:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25490 for ; Wed, 30 Jan 2002 02:51:26 -0800 (PST) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02307 for ; Wed, 30 Jan 2002 03:51:25 -0700 (MST) Received: from pthubertw2k (dhcp-nic-val-26-243.cisco.com [64.103.26.243]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id LAA18184 for ; Wed, 30 Jan 2002 11:51:24 +0100 (MET) From: "Pascal Thubert" To: Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) Date: Wed, 30 Jan 2002 11:51:24 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit And the issue whether and how stationary hosts "riding" in a mobile network are kept unaware of the movement of the monet while mobile nodes attached in the same place can be made aware of it seems challenging - but for MONET to figure out. The thing is that a Mobile Node may ride a Mobile Network. You'll get a hard time optimising the path if the models diverge. But your point about nesting might be worth-while thinking about. I don't think routing headers are ideal for nesting - the receiving host would end up with a packet that contains N routing header with each of them having segments left=0. I did not mean that the nested Mobile Networks would necessarily lead us to several RHs one after the other. I meant we want a single RH with as many segments as nested networks, for the CoAs of the Mobile Routers and the CoA of the final CN if any. Say that all the intermediate MRs exchange BUs with the CN, for example using T. Ernst's proposal (draft-ernst-mobileip-v6-network). The CN could recursively realizes that the Mobile Networks are nested, and builds a RH accordingly. I do not necessarily favour that idea because of the burden on the CN, the BU traffic involved, and the time to converge, but at least it's possible. What do you think? Pascal Thubert From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 06:10: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 GAA14597 for ; Wed, 30 Jan 2002 06:10:17 -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 DAA02592; Wed, 30 Jan 2002 03:10:04 -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 DAA25392; Wed, 30 Jan 2002 03:09: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 g0UB8j2Q012271 for ; Wed, 30 Jan 2002 03:08:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UB8iqF012270 for mobile-ip-dist; Wed, 30 Jan 2002 03:08:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UB8e2Q012263 for ; Wed, 30 Jan 2002 03:08: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 DAA20238 for ; Wed, 30 Jan 2002 03:08:58 -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 EAA05887 for ; Wed, 30 Jan 2002 04:08:58 -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 g0UB8t313912 for ; Wed, 30 Jan 2002 12:08: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 MAA20561 for ; Wed, 30 Jan 2002 12:08: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 g0UB8tg37938 for ; Wed, 30 Jan 2002 12:08:55 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201301108.g0UB8tg37938@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Mon, 28 Jan 2002 19:47:53 +0100. Date: Wed, 30 Jan 2002 12:08:55 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-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: Excuse me but I think I missed an episode : 1. at first, RH is said to be dangerous [Why not ...] => not exactly, RH is said to need a careful usage so MIPv6 use and other uses interfere in careful usage requirements (i.e. if we fix it for MIPv6 we impede other uses). 2. after, one idea to replace RH functionality is to create a new DO [Why not ...] => there are 4 propositions, one is a new DO. 3. and now, it is proposed to place this new DO between the fragment header and the ... RH [!?!] => there is an issue about the position of the DO header with the DO... This shows a new RH type is a good alternative to a new DO. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 06:15: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 GAA14735 for ; Wed, 30 Jan 2002 06:15:00 -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 DAA04201; Wed, 30 Jan 2002 03:14: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 DAA26195; Wed, 30 Jan 2002 03:14: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 g0UBDs2Q012354 for ; Wed, 30 Jan 2002 03:13:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UBDsnP012353 for mobile-ip-dist; Wed, 30 Jan 2002 03:13: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 g0UBDn2Q012346 for ; Wed, 30 Jan 2002 03:13:51 -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 DAA07242 for ; Wed, 30 Jan 2002 03:14:08 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17379 for ; Wed, 30 Jan 2002 03:14:06 -0800 (PST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id EAA09372 for ; Wed, 30 Jan 2002 04:14:04 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA21997 for ; Wed, 30 Jan 2002 04:02:57 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 30 Jan 2002 05:13:52 -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 4433A2EC83 for ; Wed, 30 Jan 2002 12:09:48 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 64bit interface ids and CGA's (Was: A threat RR doesn't solve ...) References: From: Alexandru Petrescu Date: 30 Jan 2002 12:13:59 +0100 In-Reply-To: Message-Id: Lines: 27 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: > I think practical use of address in 0::/8 (such as the ipv4-mapped, > ipv4-compatible, ipv4-translatable, loopback, unspecified) > are not likely to cause routes to be advertised in the network for longer > than a /96 (and that would be for the ipv4-mapped prefix when using a SIIT > translator). Sure. Except of course for smaller domains and "less core" routers. But this was only a side effect of my argument. I was mainly trying to say that, that CGA's assume 64bit and other types of addresses potentially have other interface id lengths. This may turn into CGA-with-Ethernet, or CGA-with-LocalTalk, CGA-with-IPv4compatible. CGA's probably have a minimum length of Interface ID for which it keeps its crypto properties, assuming a population of 2^128. > Thus IMHO a prudent implementation would limit the places where the > /64 boundary is known to a minimum. > The best would be to only have this be known by the device driver for > IP-over-foo. For instance, an Ethernet device driver would need to > know that it should create a 64 bit Interface ID from the MAC address. > Then it could pass this up to whatever entity implements RFC 2462 but > that entity only needs to verify that the prefixes advertised by the routers > plus the interface ID makes a total of 128 bits. Thanks for this advice, I didn't think about the last check. Alex From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 08:08: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 IAA17045 for ; Wed, 30 Jan 2002 08:08: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 GAA10254; Wed, 30 Jan 2002 06:08: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 FAA16228; Wed, 30 Jan 2002 05:08: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 g0UD7Q2Q012751 for ; Wed, 30 Jan 2002 05:07:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UD7QV1012750 for mobile-ip-dist; Wed, 30 Jan 2002 05:07:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UD7L2Q012743 for ; Wed, 30 Jan 2002 05:07:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0UD7KF26610; Wed, 30 Jan 2002 14:07:20 +0100 (MET) Date: Wed, 30 Jan 2002 14:03:45 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: pthubert@cisco.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I did not mean that the nested Mobile Networks would necessarily lead us to > several RHs one after the other. I meant we want a single RH with as many > segments as nested networks, for the CoAs of the Mobile Routers and the CoA > of the final CN if any. > > Say that all the intermediate MRs exchange BUs with the CN, for example > using T. Ernst's proposal (draft-ernst-mobileip-v6-network). The CN could > recursively realizes that the Mobile Networks are nested, and builds a RH > accordingly. I do not necessarily favour that idea because of the burden on > the CN, the BU traffic involved, and the time to converge, but at least it's > possible. What do you think? We're deep in Monet land at the moment but I'll respond in any case. For the case when the whole path is route optimized you are right that the CN could construct a RH listing all the CoAs. But when only part of the path is optimized e.g. the CN knows what train the MN is in (the HoA of the MR) but it doesn't know the current location of the train (the CoA of the MR) then the CN can only construct something that goes to the HoA of the MR and the MR's HA will need to nest by including something which carries the CoA of the MR. If RH is used for all of this it seems like there might be multiple RH headers - but perhaps RH can't be used in this way because of path MTU issues and instead encapsulation must be used from the HA(MR) to the MR. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 08:12: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 IAA17211 for ; Wed, 30 Jan 2002 08: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 FAA08954; Wed, 30 Jan 2002 05:12:46 -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 FAA17360; Wed, 30 Jan 2002 05:12: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 g0UDBm2Q012821 for ; Wed, 30 Jan 2002 05:11:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UDBmRw012820 for mobile-ip-dist; Wed, 30 Jan 2002 05:11:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UDBh2Q012813 for ; Wed, 30 Jan 2002 05:11:44 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0UDC0F27165; Wed, 30 Jan 2002 14:12:00 +0100 (MET) Date: Wed, 30 Jan 2002 14:08:25 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] 64bit interface ids and CGA's (Was: A threat RR doesn't solve ...) To: petrescu@crm.mot.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-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. Except of course for smaller domains and "less core" routers. > But this was only a side effect of my argument. I was mainly trying > to say that, that CGA's assume 64bit and other types of addresses > potentially have other interface id lengths. This may turn into > CGA-with-Ethernet, or CGA-with-LocalTalk, CGA-with-IPv4compatible. > CGA's probably have a minimum length of Interface ID for which it > keeps its crypto properties, assuming a population of 2^128. Ah - got it. I've heard statements that less than about 60-64 bits probably doesn't make sense. So CGA with ipv4-compatible doesn't make sense for this reason. And it also doesn't make sense since in that case the bottom 32 bits of the address is an IPv4 address assigned e.g. using DHCP with no knowledge of IPv6 or CGA. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 09:41: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 JAA20567 for ; Wed, 30 Jan 2002 09:41: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 GAA18003; Wed, 30 Jan 2002 06:41:11 -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 GAA12923; Wed, 30 Jan 2002 06:40: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 g0UEdJ2Q012997 for ; Wed, 30 Jan 2002 06:39:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UEdJlx012996 for mobile-ip-dist; Wed, 30 Jan 2002 06:39:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UEdF2Q012989 for ; Wed, 30 Jan 2002 06:39:16 -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 GAA10645 for ; Wed, 30 Jan 2002 06:39:35 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [193.49.124.32]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA25377 for ; Wed, 30 Jan 2002 07:39:29 -0700 (MST) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 15:39:13 +0100 Received: from pdico (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id C1QZY2Z0; Wed, 30 Jan 2002 15:39:10 +0100 From: "Jean-Michel COMBES" To: Subject: RE: [mobile-ip] Routing headers: design team recommendation Date: Wed, 30 Jan 2002 15:39:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Comments concerning #2 (ie. about firewall and RH). IMO, there could be two FW policies : 1. Policy based on MIPv6-H@ This case, IMHO ,is the simplest policy but the most complex to administrate: the FW checks the last @ in the RH 2. Policy based on MIPv6-Co@ In this case, the FW checks the last address in the RH (ie. RH-@[Segments Left]). If this is a MIPv6-H@ (ie. not topologically correct), then it checks the RH-H@[SL-1] and then resolves the case regarding its policy. Comments are welcome :-) PS : I am not a FW vendor, so I think it would be better if some FW guys could give their opinions. Regards. JMC. France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > -----Message d'origine----- > De : owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]De la part de Erik Nordmark > Envoye : mercredi 23 janvier 2002 21:35 > A : mobile-ip@sunroof.eng.sun.com > Objet : [mobile-ip] Routing headers: design team recommendation > > > The MIPv6 security design team is trying to resolve the issues > around routing headers as used by MIPv6. > > This note specifies the design teams' motivation and current position. > In order to move forward in an efficient manner it would be beneficial if > responses could make it clear whether it is > - a clarification (by putting CLARIFICATION: in the subject field), > - an issue with a particular point (by putting ISSUE: in the > subject field), > - disagreement with the conclusion (by putting CONCLUSION: in > the subject > field) > > INTRODUCTION > ============ > > There is background information on the security issues around > MIPv6's use of the routing header in > draft-savola-ipv6-rh-ha-security-01.txt. > This note explores how to move forward on the routing header issue. > > Today in IPv4, firewalls block IPv4 source routes by default. > The original motivation for this was that the TCP/IPv4 > implementations reverse > the source route received in a SYN and use it for the connection. > This means > that if source routes are allowed and hosts do any form of access control > based on the source IP address (such as UNIX r* commands) they could be > trivially spoofed. > > In an IPv6 world the situation is different. > IPv6 nodes MUST NOT reverse an unauthenticated (with IPsec) > routing header. > Thus routing headers can't be used to spoof IP address based > access control. > (Of course, this doesn't mean that IP address based > access control is good security - it is still a bad and grossly > insufficient > form of security - but folks might end up doing it when porting > applications > from IPv4 to IPv6). > > When there is an IPv6 firewall in place and it wants to prevent > inside node A > from communication externally (for a subset or all protocols/port > numbers) > while allowing inside node B to communicate externally (for those > protocols/ports) it needs to ensure that a routing header can't > be used to > reach node A via node B (where B might be a host or a router). > > ALTERNATIVES > ============ > > There seem to be three fundamentally different ways to approach this: > 1. Make the inside nodes (hosts and routers) be "safe" enough in their > handling of routing headers that the firewall can avoid > specific checks > on the presence of the routing header as well as the IP > addresses contained > in the RH. > > 2. Make the firewall understand the routing headers and filter based on > their content. > > 3. Try to simplify things by not using Routing Headers for MIPv6 > > Make RH "safe enough" > --------------------- > > The implications of approach #1 seem to be draconian for other use of > the routing header. > Not only can hosts not process routing headers and send the > packet out (the > same or a different interface), but internal routers cannot > process routing > headers either. > If a router processes the routing headers then the above A/B > scenario can be > used to bypass the firewall policy for host A by source routing > packets via > the router B to A. > > Thus the implications of #1 are likely to be that all hosts and > routers must > not process any routing headers and forward the packet. The only routing > header processing that would be allowed would be for a MN to > process a RH > where the packet doesn't leave the MN. > > Thus in effect routing headers would not be very useful for the initially > intended purpose; they would only be useful for the MIPv6 usage. > > > Make the firewall RH aware > -------------------------- > > When looking at #2 we need to understand what type of filtering a > firewall would need to have to prevent the A/B bypass while still allowing > MIPv6 to function. > > There are several things needed for MIPv6 to function. > We need to be able to allow: > A. CNs inside the firewall need to be able to use RH to send to > MNs outside > the firewall. > B. "visiting" MNs i.e. MNs who have a Home Address outside the firewall > and a CoA inside the firewall. > C. "local" MNs i.e. MNs where both the HoA and CoA are inside the > firewall. > > [Note that in general allowing A, B, and/or C might be subject to site's > firewall policy in general. Hence the use of "need to be able to > allow" above.] > A above doesn't cause any problems since allowing outbound RH through > the firewall doesn't cause problems with the simple rules that A can't > communicate externally. > However, if the firewall rules are more complex as in A only being able > to communicate with a specified external IP address then there are issues > if that external node is a MN and A would use a routing header > when sending > to the MN. > > The case B looks like an external entity sending a packet with a > destination > being inside the firewall with the subsequent hop (in the RH) > being outside > of the firewall. > > Possible rules for a firewall to apply in approach #2 for packets > inbound to the site would be: > 1. If the destination address is not inside the firewall then > the firewall would presumably drop it > 2. If there is no RH or an RH with zero elements then > follow non-MIPv6 firewall policy > 3. If the RH has more then one element then > treat it as a non-MIPv6 routing header (whatever policy > that is subject > to) > 4. If one element RH with the address in the RH being external to the site > allow it (assuming "visiting" MNs are allowed) > 5. If one element RH with the address in the RH being internal verify > that the address in the RH is allowed to communicate externally with > the protocol/port number. If so allow the packet with the RH. > > The above firewall rules are somewhat complex and they can't, by the > very nature of the routing header, prevent source routing. > For instance, rule #4 means that packets can be source routed through > the site and back out again, and rule #5 allows some internal > source routing. > Thus this approach assumes that there isn't a perception that > IPv6 firewalls > need to block actual source routing while allowing the MIPv6 use > of routing > headers. There is also a concern that the existing IPv4 firewall behavior > of blocking source routing might be carried forth into IPv6 firewalls. > Should this happen there is a failure case where route optimization > is established through a Binding Update but the data packets, with the RH, > are dropped. If the CN somehow decides to discard the binding cache entry > and send through the HA, it is likely that this would anew result in a > Binding Update. > Thus if this approach is taken it would seem prudent to make MIPv6 robust > against packets with RH being discarded. > > Define a MIPv6 specific thing instead of using RH > ------------------------------------------------- > > An open question is to what extent approach #3 would make things > significantly > simpler. The non-RH packet format could be to e.g. define a new > destination > option, define a new extension header, define a new routing header type, > or use IPv6_NO_SRC as specified in > draft-deering-ipv6-encap-addr-deletion-00.txt. > The following discussion doesn't assume any particular of the above > encodings - it just assumes that it is a different encoding than the > current routing header so that the firewall can have different policies > for source routing and MIPv6. > > For all the encodings it is assumed that the rules are that > 1) only a single address is contained in the encoding (just like a single > element routing header), and > 2) the receiving node never forwards the packet after processing it. > > The encoding that is most consistent with the Home Address Option would > be to define a destination option carrying the Home Address for the > destination. This could be name the alternate (or "outer"? > "upper layer"?) destination address option. > If this approach is taken it might make sense to rename the Home > Address Option to have a similar name e.g. the Alternate Source > Address Option. > RECOMMENDATION > ============== > > The design team is leaning towards #3 at the moment. One > reason for this is that this would remove any suspicion that firewall > administrators have for the use of the Routing Header and > which might consequently lead to disabling MIPv6 because of these > fears. Also, the firewall rules necessary to process the Routing > Header are complex and accidental disabling of MIPv6 might also > occur. The use of the Routing Header for other purposes would > also not be affected. There are also drawbacks in alternative #3. > One such issue is that existing MIPv6 implementations have to > be changed. We feel that this drawback is offset by the expected > wider usability of MIPv6 as a result. This change will also imply > a substantial document modification for the MIPv6 I-D. This > does not appear to be a structural change, however, and in > general we feel that direct procedure is easier to describe than > attempting to describe some additional rules to constrain the use > of the Routing Header. Finally, alternative #3 might lead us to > depend on the external work such as the new tunnel encapsulation > work at IPNG. The design team feels that we should stay away > from these non-MIPv6 solutions due schedule issues as well > as in the interests of making a self-contained RFC. > > --- From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 10:39:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22761 for ; Wed, 30 Jan 2002 10:39: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 IAA20366; Wed, 30 Jan 2002 08:39:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16444; Wed, 30 Jan 2002 07:39: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 g0UFc62Q013111 for ; Wed, 30 Jan 2002 07:38:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UFc5s7013110 for mobile-ip-dist; Wed, 30 Jan 2002 07:38: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 g0UFc12Q013101 for ; Wed, 30 Jan 2002 07:38:02 -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 HAA15887 for ; Wed, 30 Jan 2002 07:38:20 -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 HAA19764 for ; Wed, 30 Jan 2002 07:38:19 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g0UFcH320442 for ; Wed, 30 Jan 2002 16:38: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 QAA27227 for ; Wed, 30 Jan 2002 16:38: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 g0UFcHg39611 for ; Wed, 30 Jan 2002 16:38:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201301538.g0UFcHg39611@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONC LUSION) In-reply-to: Your message of Tue, 29 Jan 2002 16:47:23 +0200. Date: Wed, 30 Jan 2002 16:38: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: A note on new RH type: if we go this direction, I think the best semantic to specify is that it must be Home Address of the node. Simple and elegant. => there is no reason to do another thing (:-)! Another note: make sure that old RH (for traffic engineering) and new RH (CoA, HA mapping): that is, new RH must be after old RH in the header chain. => multiple RHs have a very simple semantic: they are processed in order, i.e. a RH can be processed only when all previous RHs have zero left segments (this is why the "segments left" field is common to all types). Regards Francis.Dupont@enst-bretagne.fr PS; we are smashing in open doors (:-). From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 11:26: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 LAA24107 for ; Wed, 30 Jan 2002 11:26: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 JAA25692; Wed, 30 Jan 2002 09:26:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11259; Wed, 30 Jan 2002 08: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 g0UGPY2Q013262 for ; Wed, 30 Jan 2002 08:25:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UGPYRR013261 for mobile-ip-dist; Wed, 30 Jan 2002 08:25: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 g0UGPV2Q013254 for ; Wed, 30 Jan 2002 08:25:31 -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 IAA28865 for ; Wed, 30 Jan 2002 08:25:50 -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 IAA08800 for ; Wed, 30 Jan 2002 08:25:50 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA21242; Wed, 30 Jan 2002 08:25:49 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0UGPnB02902; Wed, 30 Jan 2002 08:25:49 -0800 X-mProtect: Wed, 30 Jan 2002 08:25:49 -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 smtpdXASTeM; Wed, 30 Jan 2002 08:25:47 PST Message-ID: <3C581E8B.FF4D7D3@iprg.nokia.com> Date: Wed, 30 Jan 2002 08:25:47 -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] Routing headers: design team recommendation (CONCLUSION) 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: >> O.K. It's not a requirement except if we wanted to enable what >> I thought was the well-understood meaning of source routing. > > Yes, but we are talking about the meaning of source routing combined > with mobile-ip, and I don't think there is a well-understood idea > of what that could be used for hence it isn't clear whether it is needed > or not. There is a well-understood meaning of what it means to provide a "next" intermediate routing address, and that's what source routing can do. It's also clear that this can be used perfectly in the case of Mobile IP. On the other hand, we obviously do not know ALL uses of source routing. I claim that does not matter here. And, of course, it is not NEEDED in any strict sense of the word. Neither is IPv6. The human race existed for a long time before RFC 1881. It's a tool. And that's the strange thing about this discussion. I think almost everyone can see that source routing is a tool which can be used to do this job. You point out that it can be used to do other jobs. You question whether the uses are compatible. I claim they are, and have tried to demonstrate it. It seems to be devolving to navel gazing, and the esoterics of tool usage. Any of a dozen other tools can be shaped to work also. So I do not object! I just think it's a waste of time and effort, but if we are already doomed to spend the time and effort, then go for it. > Let me try to restate the above. > 1. Assume that the delivery of packets on the CoA to HoA "hop" should work > like source routing. > 2. Show that the delivery of packets on this "hop" must work like source > routing. > I agree it's obvious because it is a circular argument. Ah, but I didn't make this argument. I made the following _different_ argument: 1. The delivery of packets on the CoA to HoA "hop" --> CAN! <-- work like source routing. 2. The delivery of packets on this "hop" must not interfere with the other uses of source routing. I do NOT claim that only source routing can be used for this (see above). > The above example shows a node forwarding packets with an explicit route > (what many would consider a router) where the explicit route is constructed > using a routing header. Then the node in the middle of the explicit route > moves. My question is what would this be used for? Eventually (and -- the point -- within the lifetime of IPv6), we will get used to nodes moving. Even routers. We can make Mobile IPv6 work (most likely!) in those future scenarios. I don't claim to have perfect vision here! But at least it is very, very cheap to make the effort. We just have to do the "obvious" thing -- which, I think you agreed, was already obvious mechanically. Policy, on the other hand, is never obvious. That's why I can't go there with you. I can only offer you my conviction (perhaps meaningless to you) that it will work as designed. But other designs can also be made to work. I agree! > Even if explicit routing is used, the above doesn't make any sense to me - why > would a router in an explicit route move (using mobile-ip) and expect the > explicit route to follow its movement? An explicit route, let's say, is a route through an explicit node. That node could be made explicit for any of a thousand reasons. I don't have time to design more than one of them to perfection. It could be monitoring. It could be a security gateway. It could be transformation into pi-mesons in a way not amenable to aggregation into a routing table. I do not know. I didn't spend a lot of time figuring out why, so this is a necessarily "silly" set of reasons. I have only concentrated on the single case of Mobile IPv6. If you don't like this tool, or if it makes you uncomfortable, then you will make another tool. That's the breaks. I can only speculate (but still without much time to do so) about why. > It sounds completely esoteric doing something like that. > So a non-circular argument is needed. The tool is not circular, nor is my reasoning. However, a lot of round straw men can be set up as targets. > Yes, but this follows the assumption that the CoA to HoA "hop" is > constructed using source routing and why that's needed/useful/good > is the piece I'm trying to understand. It's only useful/good because it works perfectly. It is not needed! Other ways can be made to work perfectly, at the evident cost of time and effort. > What is your opinion of the other different ways of "encoding" things ? > (new destination option, IPV6_NO_SRC tunneling, new extension header, ...) By now you can predict! They will all work, no problem, and it will be a lot of fun and engineering effort to get the bugs out. Then we can have more interoperability testing. Maybe someone else will find a reason why the new tool has a rough edge. That will also provide many hours of discussion and further elucidation on the nature of the tool building and utilization. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 12:22:46 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25994 for ; Wed, 30 Jan 2002 12:22:45 -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 JAA00172; Wed, 30 Jan 2002 09:22:38 -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 JAA12252; Wed, 30 Jan 2002 09:22: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 g0UHL12Q013481 for ; Wed, 30 Jan 2002 09:21:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UHL1SY013480 for mobile-ip-dist; Wed, 30 Jan 2002 09:21: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UHKu2Q013473 for ; Wed, 30 Jan 2002 09:20:57 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0UHLBF19124; Wed, 30 Jan 2002 18:21:11 +0100 (MET) Date: Wed, 30 Jan 2002 18:17:35 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: "Charles E. Perkins" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C581E8B.FF4D7D3@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: > There is a well-understood meaning of what it means to provide > a "next" intermediate routing address, and that's what source > routing can do. It's also clear that this can be used perfectly > in the case of Mobile IP. On the other hand, we obviously do not > know ALL uses of source routing. I claim that does not matter > here. And, of course, it is not NEEDED in any strict sense of the > word. Neither is IPv6. The human race existed for a long time > before RFC 1881. It's a tool. We are obviously failing to communicate. You seem to be arguing that because there is a desire to do IPv6 source routing and there is a need to carry both a CoA and a HoA that it is natural/desirable/whatever for them to use the same mechanism. This seems to be like saying because we need to put in screws as well as nails we need an underlying mechanism that is a combination of a hammer and a screw driver. I'm trying to make the point that let's first see if there is a case where it makes sense either - hitting the screw with the hammer while at the same time turning it Hence my question for an indication that combining source routing and HoA/CoA in the packet the way to describe would solve some problem or at least be useful. > Any of a dozen other tools can be shaped to work also. So I do > not object! I just think it's a waste of time and effort, but > if we are already doomed to spend the time and effort, then go for it. The reason I haven't stopped arguing is that your emails are basically saying - source routing makes the most sense - I don't understand why Erik doesn't see that - but you'll (grudgingly?) accept another solution I think we should have a technical discussion (and perhaps agree that we disagree) and get away from the 3rd bullet above. > 1. The delivery of packets on the CoA to HoA "hop" --> CAN! <-- work > like source routing. > 2. The delivery of packets on this "hop" must not interfere with the > other uses of source routing. > > I do NOT claim that only source routing can be used for this (see above). In an earlier email you said: > In fact, whatever solution you would pick, you have to make > it work exactly like source routing in all circumstances. That is the part I disagree with - I don't see any need for such a requirement or desire. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 12:39:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26706 for ; Wed, 30 Jan 2002 12:39:08 -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 KAA00801; Wed, 30 Jan 2002 10:39:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16372; Wed, 30 Jan 2002 09:38: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 g0UHbQ2Q013545 for ; Wed, 30 Jan 2002 09:37:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UHbQ4F013544 for mobile-ip-dist; Wed, 30 Jan 2002 09:37: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 g0UHbM2Q013537 for ; Wed, 30 Jan 2002 09:37:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16185; Wed, 30 Jan 2002 09:37:41 -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 KAA16807; Wed, 30 Jan 2002 10:37:40 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA25799; Wed, 30 Jan 2002 09:37:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0UHbdn07049; Wed, 30 Jan 2002 09:37:39 -0800 X-mProtect: Wed, 30 Jan 2002 09:37:39 -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 smtpdlm2rLl; Wed, 30 Jan 2002 09:37:37 PST Message-ID: <3C582F60.24084494@iprg.nokia.com> Date: Wed, 30 Jan 2002 09:37:36 -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] Routing headers: design team recommendation (CONCLUSION) 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: > We are obviously failing to communicate. That's a problem that we can fix. > You seem to be arguing that because there is a desire to do > IPv6 source routing and there is a need to carry both a CoA and a HoA > that it is natural/desirable/whatever for them to use the same mechanism. No, I am not arguing that. I am arguing that we have source routing, and that it works for the job that is needed. And that we've already done the design. And that it works. And it's not because of a "desire" to do IPv6 source routing. Just because it works. I'll leave natural/desirable/whatever for someone else. > This seems to be like saying because we need to put in screws as well as nails > we need an underlying mechanism that is a combination of a hammer > and a screw driver. I hope that by now you will agree that I am not saying any such thing. > I'm trying to make the point that let's first see if there is a case where > it makes sense either > - hitting the screw with the hammer while at the same time turning it Do you mean to suggest that we need to do the compatibility analysis? > Hence my question for an indication that combining source routing and HoA/CoA > in the packet the way to describe would solve some problem or at least > be useful. That's an additional design question. I personally do not see the need, but you do. I don't think it's useful in the case of Mobile IPv6, because the mobile node "obviously" knows what to do already. >> Any of a dozen other tools can be shaped to work also. So I do >> not object! I just think it's a waste of time and effort, but >> if we are already doomed to spend the time and effort, then go for it. > > The reason I haven't stopped arguing is that your emails are basically saying > - source routing makes the most sense > - I don't understand why Erik doesn't see that > - but you'll (grudgingly?) accept another solution I'm not trying to be "grudging"(*). And I don't say that source routing makes the "most" sense! I only say that: - it DOES make sense - it DOES work - it HAS been tested. I don't even ask why you don't understand my point of view. > I think we should have a technical discussion (and perhaps agree that we > disagree) and get away from the 3rd bullet above. I'm already away from it. But what do you want me to do? NOT agree to an alternative solution? I think it would be better for me to agree to accept whatever workable solution you devise, even if I may bemoan the additional time and effort required to devise it. Or maybe you just meant that I should stop saying that I would be agreeable? >> 1. The delivery of packets on the CoA to HoA "hop" --> CAN! <-- work >> like source routing. >> 2. The delivery of packets on this "hop" must not interfere with the >> other uses of source routing. >> >> I do NOT claim that only source routing can be used for this (see above). > > In an earlier email you said: > > In fact, whatever solution you would pick, you have to make > > it work exactly like source routing in all circumstances. Well, as far as I can see, it does already work like source routing. And, either you have to cause the IPv6 source routing header to suddenly become illegal, or you have to make this whatever new thing work with it. And I claim that in doing so, you will have to make it work exactly like source routing works, but only with one additional policy implication that's already obvious at the receiving end. > That is the part I disagree with - I don't see any need for > such a requirement or desire. Which part of my last paragraph do you disagree with? Regards, Charlie P. (*) Why do I need to make such disclaimers? It doesn't seem very fair. From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 14:32:17 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00274 for ; Wed, 30 Jan 2002 14:32: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 MAA26217; Wed, 30 Jan 2002 12:32:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01684; Wed, 30 Jan 2002 11:31: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 g0UJUY2Q013827 for ; Wed, 30 Jan 2002 11:30:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UJUYlf013826 for mobile-ip-dist; Wed, 30 Jan 2002 11:30: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 g0UJUV2Q013819 for ; Wed, 30 Jan 2002 11:30:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18483; Wed, 30 Jan 2002 11:30:50 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08735; Wed, 30 Jan 2002 11:30:49 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UJUlM02093; Wed, 30 Jan 2002 13:30:47 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 13:30:47 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01BF192C@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Wed, 30 Jan 2002 13:30:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A9C4.996594E0" Sender: owner-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_01C1A9C4.996594E0 Content-Type: text/plain; charset="iso-8859-1" Erik, In the previous thread we were discussing whether or not the overhead of tunneled addresses, routing headers and HOA options were needed in every packet between the MN and CN. You suggested that an ID might be in order and so I tried to write down the basic semantics of some proposals. It also seems to me that all of this discussion about firewalls dealing with routing headers and destination options may be mute if people can agree that we do not need to include the home address in every packet on the route optimized paths between the MN and CN. Though the names were chosen to be somewhat humerous, it does work and it does avoid the recently discussed issues with firewalls, routing headers and tunneling in general. I hope it also answers the questions you had raised related to the handling of security and stale entries. I am also interested in others' opinions (even the critical ones) on these proposals. It was written to show what could be possible given a set of choices and then asks for opinions on what choices make the best sense to the group as a whole. Here is a link to the ID: http://search.ietf.org/internet-drafts/draft-morrow-mipv6-zod-00.txt Comments would be appreciated. I am not fishing for a presentation slot on this. The mail list and ID should be sufficient to convey the proposals. Thank You, Glenn Eric wrote: > BTW: I think it would be useful for you to work out the > details perhaps > as a short I-D. GM2] It is on the way but I think some people understand this already. If someone can find a way to do the reflector check in a stateless manner, then my point becomes invalid; however, I don't know if this is possible. I certainly have an open mind, though. ------_=_NextPart_001_01C1A9C4.996594E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Erik,

In the previous thread we were discussing whether or = not the overhead of tunneled addresses, routing headers and HOA options = were needed in every packet between the MN and CN. You suggested that = an ID might be in order and so I tried to write down the basic = semantics of some proposals.

It also seems to me that all of this discussion about = firewalls dealing with routing headers and destination options may be = mute if people can agree that we do not need to include the home = address in every packet on the route optimized paths between the MN and = CN.

Though the names were chosen to be somewhat humerous, = it does work and it does avoid the recently discussed issues with = firewalls, routing headers and tunneling in general. I hope it also = answers the questions you had raised related to the handling of = security and stale entries.

I am also interested in others' opinions (even the = critical ones) on these proposals. It was written to show what could be = possible given a set of choices and then asks for opinions on what = choices make the best sense to the group as a whole.

Here is a link to the ID:
http://search.ietf.org/internet-drafts/draft-morrow-mi= pv6-zod-00.txt

Comments would be appreciated. I am not fishing for a = presentation slot on this. The mail list and ID should be sufficient to = convey the proposals.

Thank You,

Glenn



 Eric wrote:

> BTW: I think it would be useful for you to work = out the
> details perhaps
> as a short I-D.
GM2] It is on the way but I think some people = understand this already. If someone can find a way to do the reflector = check in a stateless manner, then my point becomes invalid; however, I = don't know if this is possible. I certainly have an open mind, though. =

------_=_NextPart_001_01C1A9C4.996594E0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 17:57: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 RAA04230 for ; Wed, 30 Jan 2002 17:57:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00234; Wed, 30 Jan 2002 14:57: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 OAA08153; Wed, 30 Jan 2002 14:57: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 g0UMuE2Q014278 for ; Wed, 30 Jan 2002 14:56:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UMuEg1014277 for mobile-ip-dist; Wed, 30 Jan 2002 14:56: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 g0UMuA2Q014270 for ; Wed, 30 Jan 2002 14:56:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07494 for ; Wed, 30 Jan 2002 14:56:27 -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 PAA09994 for ; Wed, 30 Jan 2002 15:56:27 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA29305 for ; Wed, 30 Jan 2002 15:56:25 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA00263 for ; Wed, 30 Jan 2002 15:45:17 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 30 Jan 2002 16:56:23 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B411FF7@IL27EXM10.cig.mot.com> From: Bhatla Mukesh-MBHATLA1 To: mobile-ip@sunroof.eng.sun.com Cc: "'mchandra@cisco.com'" Subject: [mobile-ip] Registration Revocation Draft Date: Wed, 30 Jan 2002 16:56:18 -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: Hi, I was wondering about the status about this draft ? Is it still being pursued ? Thanks, Mukesh. From owner-mobile-ip@sunroof.eng.sun.com Wed Jan 30 18: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 SAA04655 for ; Wed, 30 Jan 2002 18:21:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00053; Wed, 30 Jan 2002 16:21: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 PAA21954; Wed, 30 Jan 2002 15:21:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0UNJk2Q014454 for ; Wed, 30 Jan 2002 15:19:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0UNJkIr014453 for mobile-ip-dist; Wed, 30 Jan 2002 15:19: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 g0UNJh2Q014446 for ; Wed, 30 Jan 2002 15:19:43 -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 PAA15280 for ; Wed, 30 Jan 2002 15:20:02 -0800 (PST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29295 for ; Wed, 30 Jan 2002 16:20:02 -0700 (MST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.49 2002/01/25 02:16:58 root Exp $) with SMTP id XAA03713 for ; Wed, 30 Jan 2002 23:19:57 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002013015222124769 for ; Wed, 30 Jan 2002 15:22:21 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 15:19:57 -0800 Message-ID: From: "Adrangi, Farid" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mobile-IPv4 NAT-VPN traversal Date: Wed, 30 Jan 2002 15:19:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello: In order to move forward on the mobile-ip nat&vpn traversal problem, I will be posting a problem-statement/requirements draft to the mobile-ip-nat-vpn mailing list shortly (special thanks to Henrik Levkowetz for setting this up). This hopefully will help us agree on the scope and the requirements of this problem, and start making progress on the solution space. The subscribing instructions (that I got from Henrik) are: To subscribe, you send a mail with 'subscribe' in the subject line or in the message body, to 'mobileip-nat-vpn-request@ipunplugged.com': mailto:mobileip-nat-vpn-request@ipunplugged.com?subject=subscribe Please let me know if you have any questions. Best regards, Farid From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 01:05: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 BAA11630 for ; Thu, 31 Jan 2002 01:05: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 WAA17119; Wed, 30 Jan 2002 22:04:55 -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 WAA14658; Wed, 30 Jan 2002 22:04: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 g0V63U2Q015004 for ; Wed, 30 Jan 2002 22:03:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V63U7X015003 for mobile-ip-dist; Wed, 30 Jan 2002 22:03:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V63Q2Q014996 for ; Wed, 30 Jan 2002 22:03:27 -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 WAA10809 for ; Wed, 30 Jan 2002 22:03:46 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26943 for ; Wed, 30 Jan 2002 22:03:46 -0800 (PST) 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 g0V63f605761; Wed, 30 Jan 2002 22:03:41 -0800 (PST) Received: from cisco.com (sjc-vpn3-194.cisco.com [10.21.64.194]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABO70397; Wed, 30 Jan 2002 22:03:21 -0800 (PST) Message-ID: <3C58DFE5.FDF9E2D@cisco.com> Date: Wed, 30 Jan 2002 22:10:45 -0800 From: "Alpesh S. Patel" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Registration Revocation Draft References: <35DBB8B7AC89D4118E98009027B1009B411FF7@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mukesh, Madhavi is on an extended leave. I will check with other members of my team to find the status. =a Bhatla Mukesh-MBHATLA1 wrote: > > Hi, > > I was wondering about the status about this draft ? Is it still being pursued ? > > Thanks, > Mukesh. From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 03:07: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 DAA21590 for ; Thu, 31 Jan 2002 03:07: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 AAA12415; Thu, 31 Jan 2002 00:07: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 AAA10755; Thu, 31 Jan 2002 00:06: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 g0V85o2Q015300 for ; Thu, 31 Jan 2002 00:05:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V85o0s015299 for mobile-ip-dist; Thu, 31 Jan 2002 00:05: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 g0V85k2Q015292 for ; Thu, 31 Jan 2002 00:05:46 -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 AAA11403 for ; Thu, 31 Jan 2002 00:06:00 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02970 for ; Thu, 31 Jan 2002 01:05:59 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0V85wC22742 for ; Thu, 31 Jan 2002 09:05:58 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jan 31 09:05:58 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 09:05:58 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D0E6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation Date: Thu, 31 Jan 2002 09:05:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, Late reply ! > > - if the end of the tunnel is a mobile router, the final > > destination is behind the router so a DO doesn't work (the > > missing thing is the capacity of a RH to advance from an > > intermediate destination to the next one). > > I agree here but want to mention that this applies only to a > route-optimized or triangle mobile router case, another > way of doing it without this affecting is discussed in a draft, > http://search.ietf.org/internet-drafts/draft-kniveton-mobrtr-00.txt > with the use of bidirectional tunneling. => This is getting into monet issues but I think it needs to be addressed here. I agree that it is relevant for route optimisation of monet. But I don't see a reason for not having the right tools to allow for route opt anyway since it doesn't cost anything extra. Both IPv6_NO_SRC and new type RH would allow for the routability nature in the receiver. So I think one of those 2 would be ideal. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 04:15: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 EAA22483 for ; Thu, 31 Jan 2002 04:15:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA00700; Thu, 31 Jan 2002 01:14:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25904; Thu, 31 Jan 2002 01:14: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 g0V9Ck2Q015584 for ; Thu, 31 Jan 2002 01:12:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V9CkVG015583 for mobile-ip-dist; Thu, 31 Jan 2002 01: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V9Cf2Q015576 for ; Thu, 31 Jan 2002 01:12:42 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0V9CoF19583; Thu, 31 Jan 2002 10:12:50 +0100 (MET) Date: Thu, 31 Jan 2002 10:09:13 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) To: charliep@iprg.nokia.com Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C582F60.24084494@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I am arguing that we have source routing, and that it works for the > job that is needed. And that we've already done the design. And that > it works. And it's not because of a "desire" to do IPv6 source routing. > Just because it works. Ah - got it. (You've made other points that added confusion to this.) I guess what would be helpful is to create a list with pros and cons for the different ways do separate MIPv6 from RH type 0 (and the above is definitely one of the pros for RH type 1). > I hope that by now you will agree that I am not saying any such thing. At least not so far in this most recent email :-) > > I'm trying to make the point that let's first see if there is a case where > > it makes sense either > > - hitting the screw with the hammer while at the same time turning it > > Do you mean to suggest that we need to do the compatibility analysis? This was in response to what I interpreted as you stating as desirable to be able to construct RH paths that include a CoA/HoA pair in the middle to create some combination of source routing and MIPv6. Since you are no longer claiming that this is desirable there is no need to do any further analysis of the need for such a combination. > I'm not trying to be "grudging"(*). And I don't say that source routing > makes the "most" sense! I only say that: > - it DOES make sense > - it DOES work > - it HAS been tested. > > I don't even ask why you don't understand my point of view. I think it's because of the other statements you've made in this email thread talking about the requirement and later desire that things work exactly like source routing. That didn't help to make your point clear. > > In an earlier email you said: > > > In fact, whatever solution you would pick, you have to make > > > it work exactly like source routing in all circumstances. > > Well, as far as I can see, it does already work like source routing. Here we go again ... :-) That could either be used as an artifact/side-effect of currently using RH as the mechansim. Or it could be viewed a fundamental part of MIPv6 architecture and/or a requirement for on whatever mechanism is used. I personally think it is just a side effect. I don't know what you think - side-effect or architecture? > And, either you have to cause the IPv6 source routing header to suddenly > become illegal, or you have to make this whatever new thing work with > it. And I claim that in doing so, you will have to make it work > exactly like source routing works, but only with one additional policy > implication that's already obvious at the receiving end. Why does it need to work "exactly like source routing"? The required thing needed for MIPv6 is that packets sent to a MN contain what is in essence two destination addresses: one that identifies the current toplogical location (the CoA) and one that identifies a stable location used to identify higher layer things like TCP conenctions (the HoA). We further have an existance proof that it doesn't need to have all the behavior of RH because the packets sent through the HA are tunneled (IP-in-IP encapsulation to the MN) which does not have the semantics and composability implicit in "work exactly like source routing". > Which part of my last paragraph do you disagree with? "work exactly like source routing" > (*) Why do I need to make such disclaimers? It doesn't seem very fair. Perhaps I was reading too much between your lines but it seemed like your emails had an undertone like that in "do whatever you please but it doesn't make sense to me". My apologies for jumping to that conclusion. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 04:36: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 EAA22633 for ; Thu, 31 Jan 2002 04:36: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 BAA08872; Thu, 31 Jan 2002 01:35: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 BAA29545; Thu, 31 Jan 2002 01: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 g0V9YV2Q015676 for ; Thu, 31 Jan 2002 01:34:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0V9YVQt015675 for mobile-ip-dist; Thu, 31 Jan 2002 01:34: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0V9YR2Q015668 for ; Thu, 31 Jan 2002 01:34:28 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0V9YeF21038 for ; Thu, 31 Jan 2002 10:34:40 +0100 (MET) Date: Thu, 31 Jan 2002 10:31:03 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] RH and path MTU discovery 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: Question for the list: I was thinking about "RH works for MIPv6" - have implementors tested the interaction of MIPv6/RH with Path MTU discovery and figured out how to make sure it works? The mipv6 draft doesn't say anything about this but it seems like there are similar path MTU issues RH insertion by the IP stack as there are with IPsec tunnel insertion by the IP stack thus this is something that we presumably need to make sure is well documented. The issues are: TCP when initiating a connection needs to know which MSS to use. The MSS will be different if the IP layer, e.g. based on a binding cache entry, inserts things in the packet. This is independent whether what is added is a RH, a HOA, or an extra IP header. It seems like some advise would be useful to point out this issue. If a TCP connection starts out without using RH and later route optimization has been setup (causing RH to be added by the IP layer) then a packet that previously fit in the MTU will no longer fit. Thus the IP layer needs to be able to notify the TCP layer that it is adding N bytes to the packets so that TCP can adjust its understanding of the effective path MTU. Finally, during the connection there could be changes in the routing path to the MN causing routers to send back ICMP packet too big messages. Such packets would need to be recognized by TCP as effecting the MTU for the connection even though the destination field in the "packet in error" in the ICMP packet is the CoA instead of the HoA. An explicit example: TCP generates a packet with src = CN dst = HoA (and TCP already knows that IP will add 24 bytes due to the RH so it doesn't send packets that are too big) This causes IP to send src = CN dst = CoA routing header with seg-left = 1, address = HoA If the packet is too big somewhere along the path an ICMP error will be sent back with src = some router dst = CN ICMP packet too big mtu = 1300 packet in error src = CN dst = CoA routing header with seg-left = 1, address = HoA The actual processing of this can be split between IP and TCP but the effect must be the same as TCP having received a too big packet reporting a smaller MTU and where the dst was the HoA i.e. src = some router dst = CN ICMP packet too big mtu = 1276 <=== NOTE packet in error src = CN dst = HoA <=== NOTE One possible way to implement this is to have the IP layer convert the ICMP error before passing it to TCP. Another possible way would be to have TCP be able to adjust the reported MTU and extract the destination address from the RH. Do implementations already solve this? Has it been widely tested? RFC 2473 describes the solution to this in the more general case of IP-in-IPv6 tunneling, thus that might be useful as background reading. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 09: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 JAA28055 for ; Thu, 31 Jan 2002 09:45:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21755; Thu, 31 Jan 2002 06:45:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15589; Thu, 31 Jan 2002 06:44: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 g0VB8G2Q016449 for ; Thu, 31 Jan 2002 03:08:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VB7hYK016404 for mobile-ip-dist; Thu, 31 Jan 2002 03:07: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 g0VAtk2Q016361 for ; Thu, 31 Jan 2002 02:55:46 -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 CAA09327 for ; Thu, 31 Jan 2002 02:55:47 -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 DAA10280 for ; Thu, 31 Jan 2002 03:55: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 g0VAti307766 for ; Thu, 31 Jan 2002 11:55:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA15345 for ; Thu, 31 Jan 2002 11:55: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 g0VAtig44057 for ; Thu, 31 Jan 2002 11:55:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201311055.g0VAtig44057@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RH and path MTU discovery In-reply-to: Your message of Thu, 31 Jan 2002 10:31:03 +0100. Date: Thu, 31 Jan 2002 11:55:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I was thinking about "RH works for MIPv6" - have implementors tested the interaction of MIPv6/RH with Path MTU discovery and figured out how to make sure it works? => note this is obviously an IPv6 WG item (:-). The mipv6 draft doesn't say anything about this but it seems like there are similar path MTU issues RH insertion by the IP stack as there are with IPsec tunnel insertion by the IP stack thus this is something that we presumably need to make sure is well documented. => basically there are two kind of issues with RH and path MTU discovery, one is about path MTU discovery real implementation (here) and the second is about stuff insertion (after). All path MTU discovery implementations I know (including mine) don't cache the MTU per path as they should do but per (final) destination. In the real world this doesn't harm. The second feature is the MTU of the interface to the first intermediate destination, in general this is checked very late but not too late, i.e. if the guessed MTU is too large the error is detected when the first packet has to be sent, fixed and a retry occurs (to optimize (to be politically correct :-) the path MTU guessing routine has to know RHs). The issues are: TCP when initiating a connection needs to know which MSS to use. => this is the path MTU guessing routine, with RFC 2461 words the MTU is cached in the destination cache and initialized if needed to the MTU of the outgoing interface (in RFC 2461 the destination cache is per interface but in general the interface is pointed by the neighbor cache entry, itself pointed by the destination cache aka routing table). The MSS will be different if the IP layer, e.g. based on a binding cache entry, inserts things in the packet. This is independent whether what is added is a RH, a HOA, or an extra IP header. It seems like some advise would be useful to point out this issue. => this kind of stuff should be cached per PCB (i.e. per connection). There are two ways: - the active way: when the BCE is created, all PCBs connected to the MN destination are notified they have to recompute the MTU/MSS (the routine already exists for ICMP packet too big arrival) - the reactive way: when the stuff is added the packet becomes too large, an error is returned and the sending routine recomputes the MTU/MSS and retries. In fact both are used because of unconnected PCBs, i.e. the reactive way is considered as the not optimized but always working way. If a TCP connection starts out without using RH and later route optimization has been setup (causing RH to be added by the IP layer) then a packet that previously fit in the MTU will no longer fit. Thus the IP layer needs to be able to notify the TCP layer that it is adding N bytes to the packets so that TCP can adjust its understanding of the effective path MTU. => I agree but if an ICMP packet too big is received the TCP layer has to adjust too. Finally, during the connection there could be changes in the routing path to the MN causing routers to send back ICMP packet too big messages. => exactly, this is the main source of MTU/MSS adjustments. Such packets would need to be recognized by TCP as effecting the MTU for the connection even though the destination field in the "packet in error" in the ICMP packet is the CoA instead of the HoA. => the packet in error has the RH too so the problem is only on the code which peels headers in order to do the proper action (this is easier than reception code because headers are dropped). Of course this works only if the packet in error was not too truncated. (PS: if headers are replaced by hard state this is still possible but can become a bit hairy). An explicit example: TCP generates a packet with src = CN dst = HoA (and TCP already knows that IP will add 24 bytes due to the RH so it doesn't send packets that are too big) This causes IP to send src = CN dst = CoA routing header with seg-left = 1, address = HoA If the packet is too big somewhere along the path an ICMP error will be sent back with src = some router dst = CN ICMP packet too big mtu = 1300 packet in error src = CN dst = CoA routing header with seg-left = 1, address = HoA => with this extended example you can see that header peeling is needed because the next-header field with TCP is the RH one. The actual processing of this can be split between IP and TCP but the effect must be the same as TCP having received a too big packet reporting a smaller MTU and where the dst was the HoA i.e. src = some router dst = CN ICMP packet too big mtu = 1276 <=== NOTE packet in error src = CN dst = HoA <=== NOTE One possible way to implement this is to have the IP layer convert the ICMP error before passing it to TCP. => usually the IP layer gives the essential informations to TCP, not the packet and manage by yourself (:-). These informations are addresses (HoA!), ports, the type of problem (too big). In my implementation I don't give the MTU because the MTU/MSS (re)guessing routine will find it at a know place. There is an implementation choice: to take into account or not the extra stuff in the cached MTU (I prefer "not" because the extra stuff is not in general per destination when the MTU is). Another possible way would be to have TCP be able to adjust the reported MTU and extract the destination address from the RH. => this should be in the IP layer because the code can be shared. Do implementations already solve this? => yes of course! Has it been widely tested? => each time FTP is used in a mobility demo (FTP has a nice "hash" option which shows progress. BTW FTP shows the impact of optimizations for interactive (control) or bulk transfer (data): the interactive restart after the handoff "hole" is far more aggressive, this is a good argument for TCP algorithm adjustments for mobility). RFC 2473 describes the solution to this in the more general case of IP-in-IPv6 tunneling, thus that might be useful as background reading. => RFC 2473 is about something a bit different (near purely transit stuff where this whole message is about end node stuff). Regards Francis.Dupont@enst-bretagne.fr PS: in conclusion, this is not easy but within the reach of a skilled programmer (so get a good implementation and learn/copy :-). PPS: my advantage here is mainly the time zone (Erik lives in France and sent the message when you are sleeping :-). From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 09:47: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 JAA28116 for ; Thu, 31 Jan 2002 09:47:08 -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 GAA21698; Thu, 31 Jan 2002 06:45: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 GAA15591; Thu, 31 Jan 2002 06:44: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 g0VEPF2W018206 for ; Thu, 31 Jan 2002 06:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VDZcer017884 for mobile-ip-dist; Thu, 31 Jan 2002 05:35: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 g0VDYd2Q017806 for ; Thu, 31 Jan 2002 05:34:39 -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 FAA06738 for ; Thu, 31 Jan 2002 05:27:13 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19962 for ; Thu, 31 Jan 2002 05:27:12 -0800 (PST) Received: from nomadiclab.com (ws181.nomadiclab.com [195.165.196.181]) by ws177.nomadiclab.com (Postfix) with ESMTP id 99C36A; Thu, 31 Jan 2002 15:28:25 +0200 (EET) Message-ID: <3C594609.4030508@nomadiclab.com> Date: Thu, 31 Jan 2002 15:26:33 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7+) Gecko/20011228 X-Accept-Language: en-us MIME-Version: 1.0 To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E01BF192C@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn, You wrote: > I am also interested in others' opinions (even the critical ones) on > these proposals. It was written to show what could be possible given a > set of choices and then asks for opinions on what choices make the best > sense to the group as a whole. > > Here is a link to the ID: > http://search.ietf.org/internet-drafts/draft-morrow-mipv6-zod-00.txt > > Comments would be appreciated. I am not fishing for a presentation slot > on this. The mail list and ID should be sufficient to convey the proposals. In general, I very much agree with the fundamental message of your I-D. However, I also simultaneously think that this is not the right time or place to start doing that big revisions to the Mobile IPv6 spec. As Basaravaj implied, I think that there is a good chance that we can actually get a working MIPv6 security solution, and also the other security problems *well* *enough* addressed, by Minneapolis. Thus, it seems like it may well be possible to get MIPv6 into a standards track RFC pretty soon. We shouldn't foil this possibility by trying to go too far. Considering your observations, I also think that there starts to be the time to considerably revise the internet architecture. Noel Chiappa's end-points note http://users.exis.net/~jnc/tech/endpoints.txt is an important document discussing most of the issues related. The HIP BoF seems to be the place at the IETF where _something_ is happening in this arena, though slowly. I think that your work falls beatifully within that approach. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 09:47: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 JAA28137 for ; Thu, 31 Jan 2002 09:47: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 GAA22064; Thu, 31 Jan 2002 06:45: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 GAA15623; Thu, 31 Jan 2002 06:44: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 g0VEPF2U018206 for ; Thu, 31 Jan 2002 06:33:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VDjqXF017949 for mobile-ip-dist; Thu, 31 Jan 2002 05:45: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VDfn2Q017742 for ; Thu, 31 Jan 2002 05:41:49 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0VDGlF04377 for ; Thu, 31 Jan 2002 14:16:47 +0100 (MET) Date: Thu, 31 Jan 2002 14:13:09 +0100 (CET) From: Erik Nordmark Subject: RE: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053802D4D0E6@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: > => This is getting into monet issues but I think > it needs to be addressed here. > I agree that it is relevant for route optimisation > of monet. But I don't see a reason for not > having the right tools to allow for route opt > anyway since it doesn't cost anything extra. > Both IPv6_NO_SRC and new type RH would allow > for the routability nature in the receiver. > So I think one of those 2 would be ideal. Hesham, I understand that this is a bit speculative but I'm trying to understand the details of the tradeoffs ... Do you think the other two possible encodings (destination option or a different extension header altogether) would not allow this behavior in the receiver? It seems to me that at least a different extension header would have close to identical properties to IPv6_NO_SRC. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 10:43: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 KAA00075 for ; Thu, 31 Jan 2002 10:43:54 -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 HAA17254; Thu, 31 Jan 2002 07:42: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 HAA13035; Thu, 31 Jan 2002 07:41: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 g0VFYx2Q018712 for ; Thu, 31 Jan 2002 07:34:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VFYxTl018711 for mobile-ip-dist; Thu, 31 Jan 2002 07:34:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VFYt2Q018704 for ; Thu, 31 Jan 2002 07:34:56 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0VFZ9F15696 for ; Thu, 31 Jan 2002 16:35:09 +0100 (MET) Date: Thu, 31 Jan 2002 16:31:31 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] RH and path MTU discovery To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201311055.g0VAtig44057@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => basically there are two kind of issues with RH and path MTU discovery, > one is about path MTU discovery real implementation (here) and > the second is about stuff insertion (after). > All path MTU discovery implementations I know (including mine) > don't cache the MTU per path as they should do but per (final) > destination. I thought this was what Solaris did as well, until I looked. Yes, I know of know implementations which associate the path mtu with the actual source routed path. But when there is a source route and the ICMP error arrives the Solaris implementation just looks at the destination field in the IP header in error. In fact it would need to see if there are "unconsumed" elements in the source route/routing header and find the last one in order to do this for the final destination. This might be a Solaris specific bug - haven't looked at other pmtu enabled OSs. But that doesn't cause problems as long as TCP is told of the right MTU to use. > => this kind of stuff should be cached per PCB (i.e. per connection). > There are two ways: > - the active way: when the BCE is created, all PCBs connected to the > MN destination are notified they have to recompute the MTU/MSS > (the routine already exists for ICMP packet too big arrival) > - the reactive way: when the stuff is added the packet becomes too > large, an error is returned and the sending routine recomputes > the MTU/MSS and retries. > In fact both are used because of unconnected PCBs, i.e. the reactive > way is considered as the not optimized but always working way. So existing MIPv6 implementations do this? > If a TCP connection starts out without using RH and later route > optimization > has been setup (causing RH to be added by the IP layer) then a packet > that previously fit in the MTU will no longer fit. Thus the IP layer needs > to be able to notify the TCP layer that it is adding N bytes to the > packets > so that TCP can adjust its understanding of the effective path MTU. > > => I agree but if an ICMP packet too big is received the TCP layer has > to adjust too. So existing MIPv6 implementations do this? > Finally, during the connection there could be changes in the routing path > to the MN causing routers to send back ICMP packet too big messages. > > => exactly, this is the main source of MTU/MSS adjustments. > > Such packets would need to be recognized by TCP as effecting the MTU > for the connection even though the destination field in the > "packet in error" in the ICMP packet is the CoA instead of the HoA. > > => the packet in error has the RH too so the problem is only on the > code which peels headers in order to do the proper action (this is > easier than reception code because headers are dropped). Of course > this works only if the packet in error was not too truncated. > (PS: if headers are replaced by hard state this is still possible > but can become a bit hairy). > => usually the IP layer gives the essential informations to TCP, > not the packet and manage by yourself (:-). These informations > are addresses (HoA!), ports, the type of problem (too big). > In my implementation I don't give the MTU because the MTU/MSS > (re)guessing routine will find it at a know place. If so you need to have the ICMP handling code in IP always find the final destination. I hope only Solaris has the bug I mentioned above. > Do implementations already solve this? > > => yes of course! > > Has it been widely tested? > > => each time FTP is used in a mobility demo (FTP has a nice "hash" option > which shows progress. BTW FTP shows the impact of optimizations for > interactive (control) or bulk transfer (data): the interactive restart > after the handoff "hole" is far more aggressive, this is a good > argument for TCP algorithm adjustments for mobility). Was there explicit tests where during such a connection a router in the path have its MTU lowered? Finally, how did the implementors figure this out and share the need for it amongst themselves given that the specification has zero mention of it? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 12:08:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03820 for ; Thu, 31 Jan 2002 12:08:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27396; Thu, 31 Jan 2002 10:08: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 JAA01040; Thu, 31 Jan 2002 09:08: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 g0VH6q2Q019208 for ; Thu, 31 Jan 2002 09:06:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VH6que019207 for mobile-ip-dist; Thu, 31 Jan 2002 09:06: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.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VH6m2Q019200 for ; Thu, 31 Jan 2002 09:06:48 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0VH71F27805; Thu, 31 Jan 2002 18:07:01 +0100 (MET) Date: Thu, 31 Jan 2002 18:03:23 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201261428.g0QES3g21893@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I'm trying to make sure I understand the points: > => another argument about a new Destination Option: > - if we don't specify where to put the DO we'll get a mess > - if we specify the DO must be before any IPsec header (same > case than current HAO) we have no difference with a new RH type, > only more complexity... If the ADA as well as the HAO are destination options before any IPsec header, why does this add complexity over just having the HAO before the IPsec header (and e.g. RH type 1 instead of ADA). If you point is about comparing the two approaches: - both addresses as destination options (HOA and ADA) - both addresses using Deering/Zill tunneling then I understand that the latter is simpler when it comes to IPsec interaction. But if HAO remains a destination option it seems like there would be less complexity if ADA is also a destination option. What am I missing? > - if we specify the DO must be after any IPsec header in order > to be able to protect it using ESP for instance, we'll mess > the SADB lookup which is done using the destination address. If we go the destination options path presumably we want HAO and ADA work the same way (they are really inverses of eachother - somebody suggested naming them Alternate Source Address and Alternate Destination Address respectively). > IMHO we should only conclude we'd like a new mechanism and let > the choice to the IPv6 WG (this will give us more time for other > points too). In the interest of time I'm concerned about getting the technical parts well specified so I'll ignore all comments that say that certain things should be done in other WGs :-) Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 12:33: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 MAA04716 for ; Thu, 31 Jan 2002 12:33:03 -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 JAA11741; Thu, 31 Jan 2002 09:32:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06796; Thu, 31 Jan 2002 09:31: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 g0VHU82Q019351 for ; Thu, 31 Jan 2002 09:30:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VHU7u7019350 for mobile-ip-dist; Thu, 31 Jan 2002 09:30:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHU32Q019343 for ; Thu, 31 Jan 2002 09:30:04 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0VHUGF01794; Thu, 31 Jan 2002 18:30:16 +0100 (MET) Date: Thu, 31 Jan 2002 18:26:39 +0100 (CET) From: Erik Nordmark Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200201271500.g0RF0Kg24637@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => in fact you'll force firewalls to scan DOs... I prefer to use > another RH type in order to make the decision easy (IMHO this > feature is a routing one so a RH has to be used). > I have some arguments in favour of the routing basis of this feature: > - the first one is the special case of a tunnel, i.e. this feature > is an optimization of a tunnel where the inner and the outer sources > are the same (so only destination addresses are needed). The fact that it is a special case of a tunnel clearly argues for IPv6_NO_SRC (but there might be other reasons for that being undesirable). But I don't see how this leads to RH as being a good alternative. A destination options header with either a HOA, ADA, or both options looks a lot more like Deering/Zill tunneling than HOA, RH, or both. The "symmetric" application of RH to the complete space of HOA and ADA would just use RH e.g. in this fashion: Packet sent from CN to MN src = CN dst = CoA rh segleft=1, addrs = HoA Packet sent from MN to CN src = HoA dst = CN rh segleft=0, addrs = CoA Thus conceptually this packet was sent by HoA source routed via CoA to CN. The source route was processed by the MN decrementing segleft to zero and swapping the addresses. Packet sent between MN1 and MN2 src = HoA1 dst = CoA2 rh segleft=1, addrs = CoA1, HoA2 Thus conceptually this packet was sent from HoA1 via CoA1, CoA2 to HoA2 with the sending MN1 advacing the source route by one. NOTE: The above doesn't work with ingress filtering at all hence it is completely academic. But it seems like it would be the conceptually clean way to apply RH in this space. On to more practical matters. Do people see strong arguments for/against handling the "source HoA" and the destination "HoA" using the same mechanism? For instance, using HAO/ADA destination options for both is using the same mechanism. Also using Deering/Zill tunneling for both is the same mechanism. But using destination options for HAO and RH for the other are different mechanisms. Does it make any difference e.g. in IPsec related complexity? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 12:33:57 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04738 for ; Thu, 31 Jan 2002 12:33: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 JAA07262; Thu, 31 Jan 2002 09:23: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 JAA03931; Thu, 31 Jan 2002 09:21: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 g0VHKB2Q019291 for ; Thu, 31 Jan 2002 09:20:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VHKBhJ019290 for mobile-ip-dist; Thu, 31 Jan 2002 09:20:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VHK72Q019283 for ; Thu, 31 Jan 2002 09:20:07 -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 JAA13494 for ; Thu, 31 Jan 2002 09:20:23 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07275 for ; Thu, 31 Jan 2002 10:20:23 -0700 (MST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g0VHKJe16975 for ; Thu, 31 Jan 2002 09:20:19 -0800 (PST) Message-ID: <009301c1aa7b$55123340$1b6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] RH and path MTU discovery Date: Thu, 31 Jan 2002 08:51:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, How is this different from the case where a router fails on the original path and the route changes so that the original path MTU is no longer valid? jak ----- Original Message ----- From: "Erik Nordmark" To: Sent: Thursday, January 31, 2002 1:31 AM Subject: [mobile-ip] RH and path MTU discovery > Question for the list: > > I was thinking about "RH works for MIPv6" - have implementors > tested the interaction of MIPv6/RH with Path MTU discovery > and figured out how to make sure it works? > > The mipv6 draft doesn't say anything about this but it seems like > there are similar path MTU issues RH insertion by the IP stack > as there are with IPsec tunnel insertion by the IP stack > thus this is something that we presumably need to make sure is > well documented. > > The issues are: > TCP when initiating a connection needs to know which MSS to use. > The MSS will be different if the IP layer, e.g. based on a binding cache > entry, inserts things in the packet. This is independent whether what is > added is a RH, a HOA, or an extra IP header. > It seems like some advise would be useful to point out this issue. > > If a TCP connection starts out without using RH and later route optimization > has been setup (causing RH to be added by the IP layer) then a packet > that previously fit in the MTU will no longer fit. Thus the IP layer needs > to be able to notify the TCP layer that it is adding N bytes to the packets > so that TCP can adjust its understanding of the effective path MTU. > > Finally, during the connection there could be changes in the routing path > to the MN causing routers to send back ICMP packet too big messages. > Such packets would need to be recognized by TCP as effecting the MTU > for the connection even though the destination field in the > "packet in error" in the ICMP packet is the CoA instead of the HoA. > An explicit example: > TCP generates a packet with > src = CN > dst = HoA > (and TCP already knows that IP will add 24 bytes due to the RH so > it doesn't send packets that are too big) > > This causes IP to send > src = CN > dst = CoA > routing header with seg-left = 1, address = HoA > > If the packet is too big somewhere along the path an ICMP > error will be sent back with > src = some router > dst = CN > ICMP packet too big > mtu = 1300 > packet in error > src = CN > dst = CoA > routing header with seg-left = 1, address = HoA > > The actual processing of this can be split between IP and TCP but > the effect must be the same as TCP having received a too big > packet reporting a smaller MTU and where the dst was the HoA i.e. > src = some router > dst = CN > ICMP packet too big > mtu = 1276 <=== NOTE > packet in error > src = CN > dst = HoA <=== NOTE > > One possible way to implement this is to have the IP layer convert > the ICMP error before passing it to TCP. Another possible way > would be to have TCP be able to adjust the reported MTU > and extract the destination address from the RH. > > > Do implementations already solve this? Has it been widely tested? > > RFC 2473 describes the solution to this in the more general case of > IP-in-IPv6 tunneling, thus that might be useful as background reading. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 13:04: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 NAA06065 for ; Thu, 31 Jan 2002 13:04:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13066; Thu, 31 Jan 2002 11:03: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 KAA28138; Thu, 31 Jan 2002 10:03: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 g0VI2e2Q019530 for ; Thu, 31 Jan 2002 10:02:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VI2ewg019529 for mobile-ip-dist; Thu, 31 Jan 2002 10:02:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VI2b2Q019522 for ; Thu, 31 Jan 2002 10:02:37 -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 KAA12623 for ; Thu, 31 Jan 2002 10:02: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 KAA11925 for ; Thu, 31 Jan 2002 10:02: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 g0VI2n306607 for ; Thu, 31 Jan 2002 19:02: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 TAA26745 for ; Thu, 31 Jan 2002 19:02:50 +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 g0VI2ng46239 for ; Thu, 31 Jan 2002 19:02:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201311802.g0VI2ng46239@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RH and path MTU discovery In-reply-to: Your message of Thu, 31 Jan 2002 16:31:31 +0100. Date: Thu, 31 Jan 2002 19:02: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: In your previous mail you wrote: So existing MIPv6 implementations do this? => my code is too old for the "existing" word but one has existed and I believe this can be copied or done again. Was there explicit tests where during such a connection a router in the path have its MTU lowered? => yes, this was tested with native IPv6 and IPv6 over IPv4 paths. But I agree we should verify if this is explicitely tested in test suites (I have some contacts with all testers at the last ETSI IPv6 plugtest, I can forward the message). Finally, how did the implementors figure this out and share the need for it amongst themselves given that the specification has zero mention of it? => should I answer? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 13:32: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 NAA07153 for ; Thu, 31 Jan 2002 13:32:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05831; Thu, 31 Jan 2002 11:32:45 -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 KAA08493; Thu, 31 Jan 2002 10:32: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 g0VIVZ2Q019844 for ; Thu, 31 Jan 2002 10:31:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VIVZgQ019843 for mobile-ip-dist; Thu, 31 Jan 2002 10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VIVV2Q019836 for ; Thu, 31 Jan 2002 10:31:31 -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 KAA07948 for ; Thu, 31 Jan 2002 10:31:48 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25598 for ; Thu, 31 Jan 2002 11:31: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 KAA08752 for ; Thu, 31 Jan 2002 10:31:46 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0VIVkJ28047 for ; Thu, 31 Jan 2002 10:31:46 -0800 X-mProtect: Thu, 31 Jan 2002 10:31:46 -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 smtpd41g6Ql; Thu, 31 Jan 2002 10:31:45 PST Message-ID: <3C598D91.ABC40EEC@iprg.nokia.com> Date: Thu, 31 Jan 2002 10:31:45 -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: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, Erik Nordmark wrote (to Hesham, but I'll offer my $0.02 anyway): > Do you think the other two possible encodings (destination option > or a different extension header altogether) would not allow > this behavior in the receiver? > It seems to me that at least a different extension header would have > close to identical properties to IPv6_NO_SRC. I think a new destination option would be workable. I think that a new RH type would be better, because it would be more like the existing routing header, which is known to work. Any solution should be aware of what is likely to happen when the mobile node is itself a router -- even though this matter has been declared out of scope. Let's say that a node is in the middle of a list of intermediate routing points, in a Routing Header. We don't get to say why this is. Then we have to make Mobile IPv6 work for the case where that node is mobile, or else prepare our apologies for future engineers who have to undo our mistake. The routing header solves this problem artfully, and my fear is that any other suffciently artful solution will take a long time to understand, specify, build, and test. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 13:39: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 NAA07346 for ; Thu, 31 Jan 2002 13:39:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11867; Thu, 31 Jan 2002 11:39:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23302; Thu, 31 Jan 2002 08:39:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VGE42Q018894 for ; Thu, 31 Jan 2002 08:14:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VGBi7o018884 for mobile-ip-dist; Thu, 31 Jan 2002 08:11: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 g0VG6Y2Q018840 for ; Thu, 31 Jan 2002 08:10: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 IAA17092 for ; Thu, 31 Jan 2002 08:06:10 -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 JAA09670 for ; Thu, 31 Jan 2002 09:06:10 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VG68c19612 for ; Thu, 31 Jan 2002 10:06:08 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 10:06:06 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01C4338B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Thu, 31 Jan 2002 10:06:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AA71.2D5276D0" Sender: owner-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_01C1AA71.2D5276D0 Content-Type: text/plain; charset="iso-8859-1" Pekka, Thanks for the encouragement. Actually, the data structures to do ZOD should already be in place from the existing implementations. This compared with a new DO seems to me to be a similar rework in terms of effort and it seems to solve the same problems yet with no overhead. It seems to me that there is already some significant boat-rocking going on with MIPv6 already for the same reasons. Why not just make it more optimal and completely transparent to interior nodes, as well? As Charlie pointed out earlier, the new DO will still not be transparent to firewalls. ZOD is completely transparent to firewalls i.e. NOTHING and I mean NOTHING could get in its way. As far as the slow argument goes I really can't accept this excuse as MIPv6 has already taken way way too long already and the "don't rock the boat now" reasoning is actually responsible for this slowness, IMO. The fact that "NOTHING could get in its way" is a very powerful argument for speeding the route optimization of MIPv6 up. The namespace stuff intrigues me, but I suppose my present thinking is that we don't need to send HI's in every packet. I.e. the same reasoning given by others on this issue is used in ZOD to not send the MIP home address in every packet. So from a fear of hypocrisy point of view, ZOD should make reasonable sense to those who do not think the HI should be sent on every packet. If not, perhaps this ID may serve to change peoples minds and expedite the resolution of the HI/Stack ID question. Thanks for the additional ID. I will take a look and give comments to the author. I was a bit undecided on which WG this belongs in. I also appreciate the opinion on the appropriate place; however it seems to me that MIP would benefit the most from it. Thanks again, Glenn > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] > Sent: Thursday, January 31, 2002 7:27 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Routing header Vs tunneling > > > Glenn, > > > You wrote: > > > I am also interested in others' opinions (even the critical > ones) on > > these proposals. It was written to show what could be > possible given a > > set of choices and then asks for opinions on what choices > make the best > > sense to the group as a whole. > > > > Here is a link to the ID: > > http://search.ietf.org/internet-drafts/draft-morrow-mipv6-zod-00.txt > > > > Comments would be appreciated. I am not fishing for a > presentation slot > > on this. The mail list and ID should be sufficient to > convey the proposals. > > > In general, I very much agree with the fundamental message of > your I-D. > However, I also simultaneously think that this is not the right time > or place to start doing that big revisions to the Mobile IPv6 spec. > As Basaravaj implied, I think that there is a good chance that we can > actually get a working MIPv6 security solution, and also the > other security > problems *well* *enough* addressed, by Minneapolis. Thus, it > seems like > it may well be possible to get MIPv6 into a standards track > RFC pretty soon. > We shouldn't foil this possibility by trying to go too far. > > Considering your observations, I also think that there starts > to be the time > to considerably revise the internet architecture. Noel > Chiappa's end-points > note http://users.exis.net/~jnc/tech/endpoints.txt is an > important document > discussing most of the issues related. The HIP BoF seems to > be the place > at the IETF where _something_ is happening in this arena, > though slowly. > I think that your work falls beatifully within that approach. > > --Pekka Nikander > > > > ------_=_NextPart_001_01C1AA71.2D5276D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Pekka,

Thanks for the encouragement. Actually, the data = structures to do ZOD should already be in place from the existing = implementations. This compared with a new DO seems to me to be a = similar rework in terms of effort and it seems to solve the same = problems yet with no overhead. It seems to me that there is already = some significant boat-rocking going on with MIPv6 already for the same = reasons. Why not just make it more optimal and completely transparent = to interior nodes, as well?

As Charlie pointed out earlier, the new DO will still = not be transparent to firewalls. ZOD is completely transparent to = firewalls i.e. NOTHING and I mean NOTHING could get in its way.  =

As far as the slow argument goes I really can't = accept this excuse as MIPv6 has already taken way way too long already = and the "don't rock the boat now" reasoning is actually = responsible for this slowness, IMO. The fact that "NOTHING could = get in its way" is a very powerful argument for speeding the route = optimization of MIPv6 up.

The namespace stuff intrigues me, but I suppose my = present thinking is that we don't need to send HI's in every packet. = I.e. the same reasoning given by others on this issue is used in ZOD to = not send the MIP home address in every packet. So from a fear of = hypocrisy point of view, ZOD should make reasonable sense to those who = do not think the HI should be sent on every packet. If not, perhaps = this ID may serve to change peoples minds and expedite the resolution = of the HI/Stack ID question.

Thanks for the additional ID. I will take a look and = give comments to the author. I was a bit undecided on which WG this = belongs in. I also appreciate the opinion on the appropriate place; = however it seems to me that MIP would benefit the most from = it.

Thanks again,

Glenn

> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander@noma= diclab.com]
> Sent: Thursday, January 31, 2002 7:27 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Routing header Vs = tunneling
>
>
> Glenn,
>
>
> You wrote:
>
> > I am also interested in others' opinions = (even the critical
> ones) on
> > these proposals. It was written to show = what could be
> possible given a
> > set of choices and then asks for opinions = on what choices
> make the best
> > sense to the group as a whole.
> >
> > Here is a link to the ID:
> > http://search.ietf.org/internet-drafts/draft-morrow-mi= pv6-zod-00.txt
> >
> > Comments would be appreciated. I am not = fishing for a
> presentation slot
> > on this. The mail list and ID should be = sufficient to
> convey the proposals.
>
>
> In general, I very much agree with the = fundamental message of
> your I-D.
> However, I also simultaneously think that this = is not the right time
> or place to start doing that big revisions to = the Mobile IPv6 spec.
> As Basaravaj implied, I think that there is a = good chance that we can
> actually get a working MIPv6 security solution, = and also the
> other security
> problems *well* *enough* addressed, by = Minneapolis.  Thus, it
> seems like
> it may well be possible to get MIPv6 into a = standards track
> RFC pretty soon.
> We shouldn't foil this possibility by trying to = go too far.
>
> Considering your observations, I also think = that there starts
> to be the time
> to considerably revise the internet = architecture.  Noel
> Chiappa's end-points
> note http://users.exis.net/~jnc/tech/endpoints.txt is = an
> important document
> discussing most of the issues related.  = The HIP BoF seems to
> be the place
> at the IETF where _something_ is happening in = this arena,
> though slowly.
> I think that your work falls beatifully within = that approach.
>
> --Pekka Nikander
>
>
>
>

------_=_NextPart_001_01C1AA71.2D5276D0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 13:39:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07365 for ; Thu, 31 Jan 2002 13:39:40 -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 LAA12078; Thu, 31 Jan 2002 11:39: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 KAA11405; Thu, 31 Jan 2002 10: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 g0VIcA2Q019921 for ; Thu, 31 Jan 2002 10:38:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VIcAef019920 for mobile-ip-dist; Thu, 31 Jan 2002 10:38: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 g0VIc72Q019913 for ; Thu, 31 Jan 2002 10:38:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10974 for ; Thu, 31 Jan 2002 10:38:23 -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 KAA07985 for ; Thu, 31 Jan 2002 10:38:22 -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 KAA09143; Thu, 31 Jan 2002 10:38:14 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0VIcEf05197; Thu, 31 Jan 2002 10:38:14 -0800 X-mProtect: Thu, 31 Jan 2002 10:38:14 -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 smtpd3XxcRk; Thu, 31 Jan 2002 10:38:12 PST Message-ID: <3C598F14.5E5E0980@iprg.nokia.com> Date: Thu, 31 Jan 2002 10:38:12 -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, Francis.Dupont@enst-bretagne.fr Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Do people see strong arguments for/against handling the "source HoA" and the > destination "HoA" using the same mechanism? Perhaps they are essentially different problems. The Home Address Option is not used for routing. It's used to identify the mobile node, when the default use of the routable IP address would lead to the "wrong answer". The Routing Header is used for routing. It provides an address (namely, the care-of address) that has to be used for routing, but that at the same time should be made invisible to any higher-level protocols. One shouldn't impose symmetry on the handling of addresses that are to be used for different purposes entirely. > Does it make any difference e.g. in IPsec related complexity? I think it will be better to entirely remove the authentication of the Binding Update from the domain of IPsec. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 13:53: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 NAA07831 for ; Thu, 31 Jan 2002 13:53:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22147; Thu, 31 Jan 2002 10:53:19 -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 KAA06191; Thu, 31 Jan 2002 10:26: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 g0VIPh2Q019774 for ; Thu, 31 Jan 2002 10:25:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VIPhLq019773 for mobile-ip-dist; Thu, 31 Jan 2002 10:25: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 g0VIPd2Q019766 for ; Thu, 31 Jan 2002 10:25:40 -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 KAA24011 for ; Thu, 31 Jan 2002 10:25:56 -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 LAA23720 for ; Thu, 31 Jan 2002 11:25:55 -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 g0VIPp309251; Thu, 31 Jan 2002 19:25: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 TAA27238; Thu, 31 Jan 2002 19:25:52 +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 g0VIPqg46398; Thu, 31 Jan 2002 19:25:52 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200201311825.g0VIPqg46398@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation In-reply-to: Your message of Thu, 31 Jan 2002 18:03:23 +0100. Date: Thu, 31 Jan 2002 19:25:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > - if we specify the DO must be before any IPsec header (same > case than current HAO) we have no difference with a new RH type, > only more complexity... If the ADA as well as the HAO are destination options before any IPsec header, why does this add complexity over just having the HAO before the IPsec header (and e.g. RH type 1 instead of ADA). => this is less complex to add 2 to the RH type than to specify a new DO. The argument was about ADA or RH with IPsec: there is no difference so IPsec cannot be used in order to decide between them. If you point is about comparing the two approaches: - both addresses as destination options (HOA and ADA) - both addresses using Deering/Zill tunneling then I understand that the latter is simpler when it comes to IPsec interaction. => if we go to a symmetric solution (which is not the case of new RH), I agree these will be the two alternatives. But I am far from to be convinced that Deering/Zill tunneling is simpler when it comes with IPsec, I am afraid we fall again into the "transport mode applied to a tunnel is *not* tunnel mode" (issue raised but not solved at the last IETF meeting, just wait a bit to get Mike Thomas' reaction :-). But if HAO remains a destination option it seems like there would be less complexity if ADA is also a destination option. => this is the symmetric argument: IMHO it is weak. What am I missing? => context: does IPsec consideration make a difference? > IMHO we should only conclude we'd like a new mechanism and let > the choice to the IPv6 WG (this will give us more time for other > points too). In the interest of time I'm concerned about getting the technical parts well specified so I'll ignore all comments that say that certain things should be done in other WGs :-) => you are free to waste your time how you like (:-). Regards Francis.Dupont@enst-bretagne.fr PS: the complexity argument is a real one: what is the time needed to add 2 to the type in the RH code? From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 14:05: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 OAA08272 for ; Thu, 31 Jan 2002 14:05: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 LAA26873; Thu, 31 Jan 2002 11:03:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18547; Thu, 31 Jan 2002 10: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 g0VIwV2Q020152 for ; Thu, 31 Jan 2002 10:58:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VIwVh0020151 for mobile-ip-dist; Thu, 31 Jan 2002 10:58:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VIwS2Q020144 for ; Thu, 31 Jan 2002 10:58:28 -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 KAA02421 for ; Thu, 31 Jan 2002 10:58:42 -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 LAA26809 for ; Thu, 31 Jan 2002 11:58:41 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Jan 2002 13:52:51 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RH some consensus Date: Thu, 31 Jan 2002 13:52:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: It looks like there is rough consensus to choose option #3 - replacing the routing header with something else. The DT suggested 4 possibilities here: new destination option, new extension header, new routing header type (just for MIP), or use of IPV6_NO_SRC (as in the Deering draft). There didn't seem to be any support for a new extension header. The DT should follow up with a list of pros and cons for the other options and a recommendation to choose one based on the tradeoffs. There has been some interest stated towards not precluding the use of mechanisms in MIPv6 to enable future support of mobile routers/networks. Given that the mobile router space is not well understood in the community, it seems unwise to spend a lot of time making sure the mechanisms we are defining now in order to get MIPv6 to PS, support mobile routers. From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 15:37: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 PAA11489 for ; Thu, 31 Jan 2002 15:37:01 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06978; Thu, 31 Jan 2002 13:36:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24687; Thu, 31 Jan 2002 12:36: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 g0VKZ72Q020400 for ; Thu, 31 Jan 2002 12:35:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VKZ73V020399 for mobile-ip-dist; Thu, 31 Jan 2002 12:35: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 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 g0VKZ52Q020392 for ; Thu, 31 Jan 2002 12:35:06 -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 PAA03654 for ; Thu, 31 Jan 2002 15:35:21 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA21350 for mobile-ip@sunroof.eng.sun.com; Thu, 31 Jan 2002 15:36:07 -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 g0VKJw2Q020358 for ; Thu, 31 Jan 2002 12:19: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 MAA02092 for ; Thu, 31 Jan 2002 12:20:14 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23740 for ; Thu, 31 Jan 2002 13:20:13 -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 89A685A64 for ; Thu, 31 Jan 2002 15:20:13 -0500 (EST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 46448190C for ; Thu, 31 Jan 2002 15:20:13 -0500 (EST) Received: from dogbert.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g0VKJo906149; Thu, 31 Jan 2002 15:19:50 -0500 (EST) Received: from localhost by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA09339; Thu, 31 Jan 2002 15:19:51 -0500 Message-Id: <200201312019.AA09339@dogbert.zk3.dec.com> From: Brian.Haley@compaq.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RH and path MTU discovery Date: Thu, 31 Jan 2002 15:19:51 -0500 X-Mts: smtp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Erik, I believe a lot of the questions you raised (and Francis answered) are design and implementation details which are solved differently by each vendor (eg Compaq). I think they're outside of the scope of the draft. Comments below. -Brian > > => this kind of stuff should be cached per PCB (i.e. per connection). > > There are two ways: > > - the active way: when the BCE is created, all PCBs connected to the > > MN destination are notified they have to recompute the MTU/MSS > > (the routine already exists for ICMP packet too big arrival) > > - the reactive way: when the stuff is added the packet becomes too > > large, an error is returned and the sending routine recomputes > > the MTU/MSS and retries. > > In fact both are used because of unconnected PCBs, i.e. the reactive > > way is considered as the not optimized but always working way. > > So existing MIPv6 implementations do this? Yes, we essentially do both active and reactive. > > If a TCP connection starts out without using RH and later route > > optimization > > has been setup (causing RH to be added by the IP layer) then a packet > > that previously fit in the MTU will no longer fit. Thus the IP layer needs > > to be able to notify the TCP layer that it is adding N bytes to the > > packets > > so that TCP can adjust its understanding of the effective path MTU. > > > > => I agree but if an ICMP packet too big is received the TCP layer has > > to adjust too. > > So existing MIPv6 implementations do this? Yes. First, since we are the end-node, we can fragment this packet and not drop it (usually) if adding the RH causes us to exceed the mtu. Second, like you said, the IP layer can notify TCP that it is adding N bytes of options into each packet, so it should adjust it's view of the mtu. This is an implementation detail of course - not every IP stack has this capability. > > Such packets would need to be recognized by TCP as effecting the MTU > > for the connection even though the destination field in the > > "packet in error" in the ICMP packet is the CoA instead of the HoA. > > > > => the packet in error has the RH too so the problem is only on the > > code which peels headers in order to do the proper action (this is > > easier than reception code because headers are dropped). Of course > > this works only if the packet in error was not too truncated. > > (PS: if headers are replaced by hard state this is still possible > > but can become a bit hairy). > > If so you need to have the ICMP handling code in IP always find the final > destination. I hope only Solaris has the bug I mentioned above. Seems like a general RH/ICMP/IP interaction problem to me, which is not specific to Mobile IPv6 since others can use RHs, like traceroute. > Was there explicit tests where during such a connection a router in the path > have its MTU lowered? I haven't seen it done at a test event, but then most of the conformance testing done is with you and a test generator on a private network, no routers. > Finally, how did the implementors figure this out and share the need for it > amongst themselves given that the specification has zero mention of it? I noticed it in hiccups with high bandwidth streams going from a CN to a MN. I don't see this as being any different than spending many days/months/years fine-tuning an IP stack to get that last bit of performance out of it. P.S. Sometimes sharing provides competitors inside information, I'd like to stay a step ahead of Solaris if I can... From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 17:13: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 RAA14128 for ; Thu, 31 Jan 2002 17:13: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 PAA07816; Thu, 31 Jan 2002 15:12: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 OAA16664; Thu, 31 Jan 2002 14:12:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VMBI2Q020976 for ; Thu, 31 Jan 2002 14:11:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VMBISx020975 for mobile-ip-dist; Thu, 31 Jan 2002 14:11: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0VMBE2Q020968 for ; Thu, 31 Jan 2002 14:11:14 -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 OAA04340 for ; Thu, 31 Jan 2002 14:11:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10508 for ; Thu, 31 Jan 2002 14:11:30 -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 OAA24763 for ; Thu, 31 Jan 2002 14:11:30 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g0VMBTl05178 for ; Thu, 31 Jan 2002 14:11:29 -0800 X-mProtect: Thu, 31 Jan 2002 14:11:29 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdbxLLNx; Thu, 31 Jan 2002 14:11:27 PST Message-ID: <3C59C10F.6AA35B82@iprg.nokia.com> Date: Thu, 31 Jan 2002 14:11:27 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: <3C598F14.5E5E0980@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 again folks, I made a totally irrelevant statement, which I would like to point out was irrelevant in context. Discussing the choices for replacing Routing Headers, Erik very reasonably asks: >> Does it make any difference e.g. in IPsec related complexity? I answered: > I think it will be better to entirely remove the authentication > of the Binding Update from the domain of IPsec. which has zero bearing on the discussion. Of course, any solution which is selected for inserting the care-of address as a routing point for packets destined for the mobile node has to also be compatible with IPsec solutions for protecting the payload. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 18:02: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 SAA15093 for ; Thu, 31 Jan 2002 18:02:01 -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 QAA09322; Thu, 31 Jan 2002 16:01: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 PAA03474; Thu, 31 Jan 2002 15:01: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 g0VN072Q021254 for ; Thu, 31 Jan 2002 15:00:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g0VN064l021253 for mobile-ip-dist; Thu, 31 Jan 2002 15:00: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 g0VN032Q021246 for ; Thu, 31 Jan 2002 15:00:03 -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 PAA27746 for ; Thu, 31 Jan 2002 15:00:18 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25873 for ; Thu, 31 Jan 2002 16:00:08 -0700 (MST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel10.hp.com (Postfix) with ESMTP id 3635BC004E0 for ; Thu, 31 Jan 2002 15:00:08 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA05202 for ; Thu, 31 Jan 2002 15:00:55 -0800 (PST) Date: Thu, 31 Jan 2002 15:00:54 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Mobile IP Working Group Subject: [mobile-ip] Re: [AAA-WG]: Connectathon Interest? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Thu, 20 Dec 2001, David Frascone wrote: > Ok, sorry again for the cross post, but I think this question is relevant to > both lists. > > Does *anyone* have a Diameter implementation that they would like to bring > to Connectathon (http://www.connectathon.org)? > > I'm trying to get a head count to see if anyone is planning on attending. If > there is no interest, there will not be any space/resources allocated for > Diameter testing. > > Please let me know as soon as possible! Hello, The Mobile IP team at Hewlett-Packard plans to bring a AAA Diameter Draft 8 compliant Mobility Agent. (Base and Mobile IP application, dated 12/19/2001). We would like to do IOP tests with other Mobility Agents, AAA Mobile IP servers, and/or Mobile Nodes. Also, we will be bringing a Diameter AAA server for Mobile IP testing if no-one else is bringing one. thanks, Siva From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 19:02: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 TAA15971 for ; Thu, 31 Jan 2002 19:02:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15498; Thu, 31 Jan 2002 17:02:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22085; Thu, 31 Jan 2002 16:01: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 g1100h2Q021387 for ; Thu, 31 Jan 2002 16:00:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g1100hZQ021386 for mobile-ip-dist; Thu, 31 Jan 2002 16:00:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1100d2Q021379 for ; Thu, 31 Jan 2002 16:00:39 -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 QAA21778 for ; Thu, 31 Jan 2002 16:00:50 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14596 for ; Thu, 31 Jan 2002 17:00:49 -0700 (MST) Received: from jariws1 ([62.248.145.240]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020201000048.MVEA24910.fep01-app.kolumbus.fi@jariws1>; Fri, 1 Feb 2002 02:00:48 +0200 Message-ID: <025e01c1aab3$87b15be0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Charles E. Perkins" Cc: "Erik Nordmark" , References: Subject: Re: [mobile-ip] Routing headers: design team recommendation (CONCLUSION) Date: Fri, 1 Feb 2002 02:00:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In fact, whatever solution you would pick, you have to make > it work exactly like source routing in all circumstances. Hmm.... I think not. The MIPv6 usage requires a specific forwarding to the nodes internal processing, when the address matches the home address of the node. RH in general offers a wider functionality, including forwarding the stuff somewhere else. So, in a sense you are right by saying that it's the same functionality. But Erik is also right in saying that it is not, because it is a subset. Since we have issues with the security of the non-MIPv6 part of the functionality, we fear RH might get dropped by firewalls. The MIPv6-specific mechanism, however, will not have the same dangers since we cut away the extra part, and hence it is not likely to be dropped. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 19:18:03 2002 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16204 for ; Thu, 31 Jan 2002 19:18:02 -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 QAA04568; Thu, 31 Jan 2002 16:17: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 QAA27105; Thu, 31 Jan 2002 16:17: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 g110Fk2Q021538 for ; Thu, 31 Jan 2002 16:15:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g110FkxI021537 for mobile-ip-dist; Thu, 31 Jan 2002 16:15:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g110Fg2Q021530 for ; Thu, 31 Jan 2002 16:15: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 QAA16157 for ; Thu, 31 Jan 2002 16:15:58 -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 RAA27099 for ; Thu, 31 Jan 2002 17:15: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 QAA03866; Thu, 31 Jan 2002 16:15:50 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g110FnW12454; Thu, 31 Jan 2002 16:15:49 -0800 X-mProtect: Thu, 31 Jan 2002 16:15:49 -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 smtpd7PTCxI; Thu, 31 Jan 2002 16:15:47 PST Message-ID: <3C59DE33.100B775@iprg.nokia.com> Date: Thu, 31 Jan 2002 16:15:47 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Francis.Dupont@enst-bretagne.fr Subject: Re: (CLARIFICATION) Re: [mobile-ip] Routing headers: design team recommendation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Does it make any difference e.g. in IPsec related complexity? as far as I know, no difference at all. Vijay > > Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Jan 31 22:20: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 WAA19485 for ; Thu, 31 Jan 2002 22:20:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12841; Thu, 31 Jan 2002 20:19: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 TAA12508; Thu, 31 Jan 2002 19:19: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 g113Ic2Q022116 for ; Thu, 31 Jan 2002 19:18:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g113IcoY022115 for mobile-ip-dist; Thu, 31 Jan 2002 19:18: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 g113IZ2Q022108 for ; Thu, 31 Jan 2002 19:18:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA22463 for ; Thu, 31 Jan 2002 19:18:51 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07362 for ; Thu, 31 Jan 2002 19:18:48 -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 LAA07473 for ; Fri, 1 Feb 2002 11:11:22 +0800 Received: (qmail 4812 invoked by uid 1187); 1 Feb 2002 03:11:29 -0000 Date: Fri, 1 Feb 2002 11:11:29 +0800 (CST) From: Wang Hui X-X-Sender: To: Subject: [mobile-ip] ROHC implementation ? 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: 'Head compression ' a very important feature for MIPv6 to apply to the real mobile world. ROHC is said to be future-proof framework to do head compression. But I am new to this field . I wonder if there is any rough implementation of ROHC ? I am about to startup a project to implement head compression on MIPv6 (under Linux OS ). If there is some previous work, it will save us a lot of time. And we might contribute to it as to enhance the implementation. Thanks in advance. Best regards, Wang Hui.